GLIBC version linking

[valeriy-sokoloff]

This change causes GLIBC_2.38 to be linked when compiling supernovas on a system with glibc 2.39 installed. As a result, using the precompiled library in default debian-based docker images becomes impossible (bookworm has glibc 2.36, and bullseye has 2.31).

With _DEFAULT_SOURCE supernovas compiles with GLIBC_2.29 linked ✅

[attipaci]

Interesting and weird...

According to the documentation of the feature test macros:

      _GNU_SOURCE
              Defining this macro (with any value) implicitly defines
              _ATFILE_SOURCE, _LARGEFILE64_SOURCE, _ISOC99_SOURCE,
              _XOPEN_SOURCE_EXTENDED, _POSIX_SOURCE, _POSIX_C_SOURCE with
              the value 200809L (200112L before glibc 2.10; 199506L
              before glibc 2.5; 199309L before glibc 2.1) and
              _XOPEN_SOURCE with the value 700 (600 before glibc 2.10;
              500 before glibc 2.2).  In addition, various GNU-specific
              extensions are also exposed.

              Since glibc 2.19, defining _GNU_SOURCE also has the effect
              of implicitly defining _DEFAULT_SOURCE.  Before glibc 2.20,
              defining _GNU_SOURCE also had the effect of implicitly
              defining _BSD_SOURCE and _SVID_SOURCE.

None of that seems to imply what version of GLIBC gets linked. But, using _GNU_SOURCE does get rid of the ugly fudging of whether to use _DEFAULT_SOURCE or _BSD_SOURCE based on the GCC version as a crude proxy for the assumed GLIBC version. It would be good to find out what is going on here exactly...

It's also not clear to me how gcc would ever guarantee to link with a different version of GLIBC (such as GLIBC_2.29) than what is installed (in your case GLIBC_2.39), regardless of the feature test macros used.

I'm happy to revert that change, if it is fundamentally a solution to the problem...

[attipaci]

I think what you describe is the main reason why Linux binaries are not back portable, in general. Each OS release comes with its own binary packages for a reason. I'm actually a little surprised that you managed to run anything compiled with a newer glibc on an older platform. This may have just been a lucky coincidence... I.e., it just so happened that the linking did not use any symbols beyond those available in GLIBC 2.29 when the _DEFAULT_SOURCE macro was used. Even so, there is no guarantee that the next GLIBC will not use some newer symbol with either macro. So, I don't think switching back to _DEFAULT_SOURCE is a fool-proof long-term solution to your issue. It just happens to work right now.

But porting forward should work always. So, if you compile on bullseye, then that binary should run on bullseye, bookworm, and anything after...

[attipaci]

So, perhaps the question is: Should a program or library compiled with a specific version of GLIBC installed be expected to run on a system with an older version of GLIBC? I think the answer is no...

[attipaci]

Static linking could solve the issue, but I don't think static linking is really an option for Linux and GLIBC these days...

[valeriy-sokoloff]

It's also not clear to me how gcc would ever link with a different version of GLIBC (such as GLIBC_2.29) than what is installed (in your case GLIBC_2.39).

Probably an ubuntu-specific glibc, idk. I don't have any other glibc on the system except 2.39

$ /lib/x86_64-linux-gnu/libc.so.6 
GNU C Library (Ubuntu GLIBC 2.39-0ubuntu8.4) stable release version 2.39.

But with _DEFAULT_SOURCE:

$ strings libsupernovas.so.1 | grep GLIBC_
GLIBC_2.3
GLIBC_2.29
GLIBC_2.2.5
GLIBC_2.4
GLIBC_2.7
GLIBC_2.3.4
__ctype_toupper_loc@GLIBC_2.3
strcasecmp@GLIBC_2.2.5
__vfprintf_chk@GLIBC_2.3.4
__errno_location@GLIBC_2.2.5
strncpy@GLIBC_2.2.5
strcpy@GLIBC_2.2.5
__isoc99_fscanf@GLIBC_2.7
strtod@GLIBC_2.2.5
remainder@GLIBC_2.2.5
fclose@GLIBC_2.2.5
strlen@GLIBC_2.2.5
__stack_chk_fail@GLIBC_2.4
sincos@GLIBC_2.2.5
fputc@GLIBC_2.2.5
acos@GLIBC_2.2.5
fgets@GLIBC_2.2.5
__tls_get_addr@GLIBC_2.3
strcmp@GLIBC_2.2.5
ftell@GLIBC_2.2.5
strncasecmp@GLIBC_2.2.5
tan@GLIBC_2.2.5
__isoc99_sscanf@GLIBC_2.7
atan2@GLIBC_2.2.5
fseek@GLIBC_2.2.5
__fread_chk@GLIBC_2.7
fopen@GLIBC_2.2.5
strtok@GLIBC_2.2.5
floor@GLIBC_2.2.5
asin@GLIBC_2.2.5
__fprintf_chk@GLIBC_2.3.4
sqrt@GLIBC_2.2.5
strdup@GLIBC_2.2.5
strerror@GLIBC_2.2.5
__cxa_finalize@GLIBC_2.2.5
exp@GLIBC_2.29
__ctype_b_loc@GLIBC_2.3
stderr@GLIBC_2.2.5
__sprintf_chk@GLIBC_2.3.4

And with _GNU_SOURCE macro:

$ strings libsupernovas.so.1 | grep GLIBC_
GLIBC_2.3
GLIBC_2.29
GLIBC_2.2.5
GLIBC_2.4
GLIBC_2.38
GLIBC_2.7
GLIBC_2.3.4
__ctype_toupper_loc@GLIBC_2.3
strcasecmp@GLIBC_2.2.5
__vfprintf_chk@GLIBC_2.3.4
__errno_location@GLIBC_2.2.5
strncpy@GLIBC_2.2.5
strcpy@GLIBC_2.2.5
__isoc99_fscanf@GLIBC_2.7
__isoc23_sscanf@GLIBC_2.38
strtod@GLIBC_2.2.5
remainder@GLIBC_2.2.5
fclose@GLIBC_2.2.5
strlen@GLIBC_2.2.5
__stack_chk_fail@GLIBC_2.4
sincos@GLIBC_2.2.5
fputc@GLIBC_2.2.5
acos@GLIBC_2.2.5
fgets@GLIBC_2.2.5
__tls_get_addr@GLIBC_2.3
strcmp@GLIBC_2.2.5
ftell@GLIBC_2.2.5
strncasecmp@GLIBC_2.2.5
tan@GLIBC_2.2.5
__isoc99_sscanf@GLIBC_2.7
atan2@GLIBC_2.2.5
fseek@GLIBC_2.2.5
__fread_chk@GLIBC_2.7
fopen@GLIBC_2.2.5
strtok@GLIBC_2.2.5
floor@GLIBC_2.2.5
asin@GLIBC_2.2.5
__fprintf_chk@GLIBC_2.3.4
sqrt@GLIBC_2.2.5
strdup@GLIBC_2.2.5
strerror@GLIBC_2.2.5
__cxa_finalize@GLIBC_2.2.5
exp@GLIBC_2.29
__ctype_b_loc@GLIBC_2.3
stderr@GLIBC_2.2.5
__sprintf_chk@GLIBC_2.3.4

Looks like the difference is in the new reference __isoc23_sscanf@GLIBC_2.38

Should a program or library compiled with a specific version of GLIBC (installed along with GCC) be expected to run on a system with an older version of GLIBC? I think the answer is no...

Well, as you can see, the answer is actually 'it depends' - if the output binary has only linked functions from glibc_2.2*, then why not? 😆

[valeriy-sokoloff]

it just so happened that the linking did not use any symbols beyond those available in GLIBC 2.29 when the _DEFAULT_SOURCE macro was used. Even so, there is no guarantee that the next GLIBC will not use some newer symbol with either macro. So, I don't think switching back to _DEFAULT_SOURCE is a fool-proof long-term solution to your issue. It just happens to work right now.

yes, you're right

[attipaci]

OK, if you agree, I'll convert this to a discussion item, since I don't think there is anything really SuperNOVAS specific about it. But I'm also curious what happens if you build supernovas with the bullseye docker image, and then try use that in bookworm, or your host system. So, let me know if that provides a workable solution of sorts...

[valeriy-sokoloff]

Compiled in a bullseye container with libc 2.31, the highest mentioned version is GLIBC_2.29 - the same as in a bookworm container with libc 2.36.

Compiled on trixie with libc 2.41, it matches my host machine with libc 2.39, has __isoc23_sscanf@GLIBC_2.38

And yes, supernovas compiled on bookworm also works on bullseye (with the older libc) :)

P.S. All tested with the _GNU_SOURCE macro.

The problem is solved - turns out the issue wasn't an issue at all.

I think it might also help to try compiling it with the -std=c17 flag, but I'm already satisfied with the results I have 😆