Re: [Buildroot] [autobuild.buildroot.net] Daily results for 2022-09-22

[Stafford Horne <shorne@gmail.com>]

On Fri, Sep 23, 2022 at 05:23:11PM +0200, Waldemar Brodkorb wrote:
> Hi Yann,
> yann.morin@orange.com wrote,
> 
> > Waldemar, All,
> > 
> > On 2022-09-23 14:13 +0200, MORIN Yann INNOV/IT-S spake thusly:
> > > On 2022-09-23 05:30 +0000, Thomas Petazzoni via buildroot spake thusly:
> > > >     or1k     |           gpsd-3.24            | NOK | http://autobuild.buildroot.net/results/7adc125e843b21b559f1e8813059d65af58feb8d |     
> > > 
> > > This is an or1k, shared-only, uClibc-ng, LT (not NPTL) so no TLS, build.
> > > 
> > > So, I'm not sure to make of this issue:
> > > 
> > >     ..../or1k-buildroot-linux-uclibc-gcc -o gpsd-3.24/gpsctl .... -lusb-1.0 -lm -lrt -lnsl
> > >     ..../ld: ..../sysroot/usr/lib/libusb-1.0.so: undefined reference to `__tls_get_addr'
> > 
> > So, here are a few other tests I did (each independtly):
> > 
> >   - revert uclibc-ng from 1.0.42 back to 1.0.41 -> still fails
> >   - revert libusb from 1.0.26 back to 1.0.25 -> still fails
> >   - revert gpsd from 3.24 back to 3.23.1 -> still fails
> > 
> > So, from the look of it, the __tls_get_addr has alwaus been injected in
> > libusb [0] on or1k with uclibc-ng and linuxthreeads.
> > 
> > Now, is that a valid combo?
> 
> Normally I would say it is. May be this is an gcc/binutils issue?
> Maybe the uClibc-ng or1k maintainer knows more? Stafford do you have
> a plausible explanation for this phenomenon?

I don't, I haven't looked at __tls_get_addr for a year or more so I forget the
details.  I will have to dic in.  As I remember the symbol is provided by libc.
So perhaps the way libusb linker flags are getting set with uClibc-ng is cauing
an issue.

>  
> > Do we want to keep LT even for those arch where NPTL exists? I.e. when
> > uclibc is configured with threads, use NPTL is there is an NPTL
> > implementation for the arch, otherwise use LT. Thoughts?
> 
> It might be a solution, yes. But do not forget it is not that
> simple, as it also depends on the binary format used, as for ARM
> where pending patches for FDPIC will use NPTL and FLAT is
> Linuxthreads only. Sometimes it might be useful to use Linuxthreads
> to see if it is a NPTL bug or not. May be Stafford have an idea.

I am pretty sure uClibc-ng with NPTL enabled alone should "just work" and
provide the __tls_get_addr symbol, the gcc version might have something to do
with it, but it should be working since or1k was ported to gcc.  But again I
will have to play with the build to see where it is going wrong.

I will have a look at this over the weekend.

-Stafford
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot