upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-04-12 12:26:15 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
haproxy/src/version.c

78 lines
1.9 KiB
C
Raw Permalink Normal View History

BUILD: add a new file "version.c" to carry version updates While testing fixes, it's sometimes confusing to rebuild only one C file (e.g. a mux) and not to have the correct commit ID reported in "haproxy -v" nor on the stats page. This patch adds a new "version.c" file which is always rebuilt. It's very small and contains only 3 variables derived from the various version strings. These variables are used instead of the macros at the few places showing the version. This way the output version of the running code is always correct for the parts that were rebuilt.
2019-01-04 12:20:32 -05:00
/*
* Version reporting : all user-visible version information should come from
* this file so that rebuilding only this one is enough to report the latest
* code version.
*/
BUILD: Fix build by including haproxy/global.h In srv/version.c, fix build by including haproxy/global.h, so that REGISTER_BUILD_OPTS is properly defined.
2020-06-16 17:35:00 -04:00
#include <haproxy/global.h>
REORG: include: move version.h to haproxy/ Few files were affected. The release scripts was updated.
2020-05-27 09:59:00 -04:00
#include <haproxy/version.h>
BUILD: add a new file "version.c" to carry version updates While testing fixes, it's sometimes confusing to rebuild only one C file (e.g. a mux) and not to have the correct commit ID reported in "haproxy -v" nor on the stats page. This patch adds a new "version.c" file which is always rebuilt. It's very small and contains only 3 variables derived from the various version strings. These variables are used instead of the macros at the few places showing the version. This way the output version of the running code is always correct for the parts that were rebuilt.
2019-01-04 12:20:32 -05:00
MINOR: version: make the version strings variables, not constants It currently is not possible to figure the exact haproxy version from a core file for the sole reason that the version is stored into a const string and as such ends up in the .text section that is not part of a core file. By turning them into variables we move them to the data section and they appear in core files. In order to help finding them, we just prepend an extra variable in front of them and we're able to immediately spot the version strings from a core file: $ strings core | fgrep -A2 'HAProxy version' HAProxy version follows 2.1-dev2-e0f48a-88 2019/10/15 (These are haproxy_version and haproxy_date respectively). This may be backported to 2.0 since this part is not support to impact anything but the developer's time spent debugging.
2019-10-16 03:44:55 -04:00
/* These ones are made variables and not constants so that they are stored into
* the data region and prominently appear in core files.
*/
char haproxy_version_here[] = "HAProxy version follows";
char haproxy_version[] = HAPROXY_VERSION;
char haproxy_date[] = HAPROXY_DATE;
char stats_version_string[] = STATS_VERSION_STRING;
MINOR: version: put the compiler version output into version.c not haproxy.c For an unknown reason in commit bb1b63c079 I placed the compiler version output in haproxy.c instead of version.c. Better have it in version.c which is more suitable to this sort of things.
2020-06-16 13:11:11 -04:00
REORG: version: move the remaining BUILD_* stuff from haproxy.c to version.c version.c tries to centralize all variables conveying version information, but there's still an issue with the BUILD_* variables which are only passed to haproxy.o and are only updated when that one is rebuilt. This is not very logical given that we can end up with values there which contradict info from version.c. Better move all of these to version.c which is systematically rebuilt. Most of these variables only end up as string concatenation at the moment. Some of them are even duplicated. In version.c we now have one variable (or constant) for each of them and haproxy.c references them in messages. This is much more logical and easier to maintain in a consistent state. The patch looks a bit large but it really only moves the ifdefed string assignment from one file to another, placing them into variables.
2025-01-20 11:49:55 -05:00
/* the build options string depending on known settings */
char build_opts_string[] = ""
#ifdef BUILD_TARGET
"\n TARGET = " BUILD_TARGET
#endif
#ifdef BUILD_CC
"\n CC = " BUILD_CC
#endif
#ifdef BUILD_CFLAGS
"\n CFLAGS = " BUILD_CFLAGS
#endif
#ifdef BUILD_OPTIONS
"\n OPTIONS = " BUILD_OPTIONS
#endif
#ifdef BUILD_DEBUG
"\n DEBUG = " BUILD_DEBUG
#endif
"";
/* compact string of toolchain options for post-mortem */
const char pm_toolchain_opts[] = ""
#ifdef BUILD_CC
BUILD_CC
#endif
#ifdef BUILD_CFLAGS
" " BUILD_CFLAGS
#endif
#ifdef BUILD_DEBUG
" " BUILD_DEBUG
#endif
"";
/* compact string of target options for post-mortem */
const char pm_target_opts[] = ""
#ifdef BUILD_TARGET
"TARGET='" BUILD_TARGET "'"
#endif
#ifdef BUILD_OPTIONS
" " BUILD_OPTIONS
#endif
"";
/* Build features may be passed by the makefile */
#ifdef BUILD_FEATURES
char *build_features = BUILD_FEATURES;
#else
char *build_features = "";
#endif
MINOR: version: report the presence of the compiler's address sanitizer Since we've seen clang emit bad code when the address sanitizer is enabled at -O2, better clearly report it in the version output. It is detected both for clang and gcc (both tested with and without).
2020-06-16 13:14:19 -04:00
#if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
#define SANITIZE_STRING " with address sanitizer"
#else
#define SANITIZE_STRING ""
#endif
MINOR: version: put the compiler version output into version.c not haproxy.c For an unknown reason in commit bb1b63c079 I placed the compiler version output in haproxy.c instead of version.c. Better have it in version.c which is more suitable to this sort of things.
2020-06-16 13:11:11 -04:00
#if defined(__clang_version__)
MINOR: version: report the presence of the compiler's address sanitizer Since we've seen clang emit bad code when the address sanitizer is enabled at -O2, better clearly report it in the version output. It is detected both for clang and gcc (both tested with and without).
2020-06-16 13:14:19 -04:00
REGISTER_BUILD_OPTS("Built with clang compiler version " __clang_version__ "" SANITIZE_STRING);
MINOR: version: put the compiler version output into version.c not haproxy.c For an unknown reason in commit bb1b63c079 I placed the compiler version output in haproxy.c instead of version.c. Better have it in version.c which is more suitable to this sort of things.
2020-06-16 13:11:11 -04:00
#elif defined(__VERSION__)
MINOR: version: report the presence of the compiler's address sanitizer Since we've seen clang emit bad code when the address sanitizer is enabled at -O2, better clearly report it in the version output. It is detected both for clang and gcc (both tested with and without).
2020-06-16 13:14:19 -04:00
REGISTER_BUILD_OPTS("Built with gcc compiler version " __VERSION__ "" SANITIZE_STRING);
MINOR: version: put the compiler version output into version.c not haproxy.c For an unknown reason in commit bb1b63c079 I placed the compiler version output in haproxy.c instead of version.c. Better have it in version.c which is more suitable to this sort of things.
2020-06-16 13:11:11 -04:00
#endif
Reference in a new issue Copy permalink