GCC10 in sysroot: libstdc++ symbols

GCC10 in sysroot: libstdc++ symbols

[Oleg Smolsky]

Hello! I'm testing a Linux/Linux GCC10 cross-compiler (configured with a 
sysroot + glibc 2.33) and hitting a linking issue. One of the OSS 
packages I had built before with a simple bootstrapped GCC10 is looking 
for this symbol:

     undefined symbol: _ZSt15__once_callable, version GLIBCXX_3.4.11

This symbol does not exist in the new libstdc++, and yet I see it in the 
old one:

$ nm /opt/gcc-10/lib64/libstdc++.so.6 | grep callable
0000000000000018 B _ZSt15__once_callable

Clearly the new build is not quite the same as the old one... but which 
one is correct for Linux/x86-64? And what controls this variance? It 
looks like glibc does not have a flag to control TLS any more...

I would appreciate any hints!

Thanks in advance,
Oleg.

Re: GCC10 in sysroot: libstdc++ symbols

[Florian Weimer]

* Oleg Smolsky via Gcc-help:

> Clearly the new build is not quite the same as the old one... but
> which one is correct for Linux/x86-64? And what controls this
> variance? It looks like glibc does not have a flag to control TLS any
> more...

You need to figure out why _GLIBCXX_HAVE_TLS was not detected at
configure time.  See config/tls.m4.  There is likely something in
config.log.

Thanks,
Florian

Re: GCC10 in sysroot: libstdc++ symbols

[Jonathan Wakely]

On Thu, 11 Mar 2021, 18:40 Oleg Smolsky via Gcc-help, <gcc-help@gcc.gnu.org>
wrote:

> Hello! I'm testing a Linux/Linux GCC10 cross-compiler (configured with a
> sysroot + glibc 2.33) and hitting a linking issue. One of the OSS
> packages I had built before with a simple bootstrapped GCC10 is looking
> for this symbol:
>
>      undefined symbol: _ZSt15__once_callable, version GLIBCXX_3.4.11
>
> This symbol does not exist in the new libstdc++, and yet I see it in the
> old one:
>
> $ nm /opt/gcc-10/lib64/libstdc++.so.6 | grep callable
> 0000000000000018 B _ZSt15__once_callable
>
> Clearly the new build is not quite the same as the old one... but which
> one is correct for Linux/x86-64? And what controls this variance? It
> looks like glibc does not have a flag to control TLS any more...
>

This depends on whether GCC detects TLS support for the target. I would
expect TLS to be supported for x86_64-*-linux-gnu, i.e. the old build
matches the expected configuration. It's not "wrong" to have a build
without TLS (there might be valid reasons to configure things that way) but
it's not typical.

You should look at why the new GCC thinks your target can't support TLS.

Re: [EXTERNAL] Re: GCC10 in sysroot: libstdc++ symbols

[Oleg Smolsky]

On 2021-03-11 10:01, Florian Weimer wrote:
> * Oleg Smolsky via Gcc-help:
>
>> Clearly the new build is not quite the same as the old one... but
>> which one is correct for Linux/x86-64? And what controls this
>> variance? It looks like glibc does not have a flag to control TLS any
>> more...
> You need to figure out why _GLIBCXX_HAVE_TLS was not detected at
> configure time.  See config/tls.m4.  There is likely something in
> config.log.

Thank you for the pointers, Florian and Jonathan!

I'm trying to figure out where the new build went awry. So far I have 
these crumbs:

$ find . -name config.log | xargs grep _TLS
./gcc-build/x86_64-pc-linux-gnu/libgcc/config.log:set_have_cc_tls='-DHAVE_CC_TLS'
./gcc-build/gcc/config.log:configure:26862: checking assembler for 
R_386_TLS_GD_PLT reloc
./gcc-build/gcc/config.log:configure:26904: checking assembler for 
R_386_TLS_LDM_PLT reloc
./gcc-build/gcc/config.log:configure:26952: checking assembler for 
R_386_TLS_LDM reloc
./gcc-build/gcc/config.log:| #define HAVE_AS_TLS 1
./gcc-build/gcc/config.log:| #define HAVE_AS_IX86_TLSLDMPLT 0
./gcc-build/gcc/config.log:| #define HAVE_AS_IX86_TLSLDM 0
./gcc-build/gcc/config.log:| #define HAVE_AS_IX86_TLS_GET_ADDR_GOT 0
./gcc-build/gcc/config.log:| #define HAVE_AS_TLS 1
./gcc-build/gcc/config.log:| #define HAVE_AS_IX86_TLSLDMPLT 0
./gcc-build/gcc/config.log:| #define HAVE_AS_IX86_TLSLDM 0
./gcc-build/gcc/config.log:| #define HAVE_AS_IX86_TLS_GET_ADDR_GOT 0
./gcc-build/gcc/config.log:#define HAVE_AS_TLS 1
./gcc-build/gcc/config.log:#define HAVE_AS_IX86_TLSLDMPLT 0
./gcc-build/gcc/config.log:#define HAVE_AS_IX86_TLSLDM 0
./gcc-build/gcc/config.log:#define HAVE_AS_IX86_TLS_GET_ADDR_GOT 0

and

$ find . -name config.log | xargs grep tls
./gcc-build/x86_64-pc-linux-gnu/libgomp/config.log:configure:16001: 
checking whether the thread-local storage support is from emutls
./gcc-build/x86_64-pc-linux-gnu/libgomp/config.log:gcc_cv_have_tls=no
./gcc-build/x86_64-pc-linux-gnu/libgomp/config.log:gcc_cv_use_emutls=no
./gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/config.log:gcc_cv_have_tls=no
./gcc-build/x86_64-pc-linux-gnu/libgcc/config.log:configure:5460: 
checking whether the thread-local storage support is from emutls
./gcc-build/x86_64-pc-linux-gnu/libgcc/config.log:gcc_cv_have_cc_tls=yes
./gcc-build/x86_64-pc-linux-gnu/libgcc/config.log:gcc_cv_use_emutls=no
./gcc-build/x86_64-pc-linux-gnu/libgcc/config.log:set_have_cc_tls='-DHAVE_CC_TLS'
./gcc-build/x86_64-pc-linux-gnu/libgcc/config.log:set_use_emutls=''
./gcc-build/x86_64-pc-linux-gnu/libgcc/config.log:tmake_file=' 
$(srcdir)/config/t-crtstuff-pic $(srcdir)/config/t-libgcc-pic 
$(srcdir)/config/t-eh-dw2-dip $(srcdir)/config/t-slibgcc 
$(srcdir)/config/t-slibgcc-gld $(srcdir)/config/t-slibgcc-elf-ver 
$(srcdir)/config/t-linux $(srcdir)/config/i386/t-crtpc 
$(srcdir)/config/t-crtfm $(srcdir)/config/i386/t-crtstuff 
$(srcdir)/config/t-dfprules $(srcdir)/config/i386/t-cpuinfo 
$(srcdir)/config/t-tls $(srcdir)/config/i386/t-linux 
$(srcdir)/config/i386/t-msabi $(srcdir)/config/t-slibgcc-libgcc 
$(srcdir)/config/t-stack $(srcdir)/config/i386/t-stack-i386 
$(srcdir)/config/t-softfp-tf $(srcdir)/config/i386/t-softfp 
$(srcdir)/config/t-softfp $(srcdir)/config/i386/64/t-softfp-compat'
./gcc-build/x86_64-pc-linux-gnu/libitm/config.log:gcc_cv_have_tls=no

./gcc-build/gcc/config.log:configure:27105: checking assembler for 
calling ___tls_get_addr via GOT
./gcc-build/gcc/config.log:gcc_cv_as_ix86_tls_get_addr_via_got=no

That last one does an "as" check... Is that the trigger?

Thanks!
Oleg.

Re: [EXTERNAL] Re: GCC10 in sysroot: libstdc++ symbols

[Oleg Smolsky]

On 2021-03-11 12:12, Oleg Smolsky wrote:
> On 2021-03-11 10:01, Florian Weimer wrote:
>> * Oleg Smolsky via Gcc-help:
>>
>>> Clearly the new build is not quite the same as the old one... but
>>> which one is correct for Linux/x86-64? And what controls this
>>> variance? It looks like glibc does not have a flag to control TLS any
>>> more...
>> You need to figure out why _GLIBCXX_HAVE_TLS was not detected at
>> configure time.  See config/tls.m4.  There is likely something in
>> config.log.
>
> Thank you for the pointers, Florian and Jonathan!
>
> I'm trying to figure out where the new build went awry. So far I have 
> these crumbs:
> ....
>
I have another data point - I am able to build GCC fully and correctly 
(with TLS) on another VM using the same recipe. The difference between 
these VMs is the kernel package. The working case uses the stock Ubuntu 
kernel and the broken case uses a newer package (seemingly official).

The working case: linux-image-4.4.0-83-generic and the corresponding 
"headers" package.
The broken case: linux-image-4.15.0-99-generic and no kernel headers (I 
install them into the sysroot anyway).

Is there a way to figure out whether it's GCC that thinks there is no 
TLS support or GLibc?

Thanks!
Oleg.