[Buildroot] [PATCH] autossh: honour LDFLAGS

[Waldemar Brodkorb]

Hi,
Waldemar Brodkorb wrote,

> Hi Max,
> Max Filippov wrote,
> 
> > On Tue, Nov 29, 2016 at 12:43 AM, Thomas Petazzoni
> > <thomas.petazzoni at free-electrons.com> wrote:
> > > On Tue, 29 Nov 2016 05:16:55 +0100, Waldemar Brodkorb wrote:
> > >> > The --start-group/--end-group ask the linker to loop between -lgcc and
> > >> > -lc until all unresolved symbols have been resolved. So
> > >> > dl_iterate_phdr() being defined in the C library, but used in libgcc, I
> > >> > guess the dynamic way (-lgcc -lc -lgcc) doesn't work.
> > >>
> > >> But why gcc behaves different?
> > >> BR+gcc5+uClibc-ng-1.0.17 - no extra -static in LDFLAGS required
> > >> BR+gcc5+musl+static - no extra -static in LDFLAGS required
> > >> BR+gcc5+uClibc-ng-1.0.19 - extra -static required!
> > >
> > > I would suspect it's a fallout of the "merge everything in libc"
> > > change, but I really can't figure out why that would make a difference.
> > >
> > > Could it be that with older uClibc versions, gcc was not finding the
> > > dl_iterate_phdr symbol in uClibc, and therefore disabling the unwind
> > > code, and now, due to a change in uClibc, gcc sees the dl_iterate_phdr
> > > symbol, enables unwinding support, which cause this extra reference
> > > from libgcc to libc?
> > 
> > No. The difference is in the __pthread_initialize_minimal function.
> > Prior to uclibc-1.0.18 release it used to work because a call to
> > __pthread_initialize_minimal from __uClibc_init was resolved to
> > a function defined in libpthread/nptl/sysdeps/generic/libc-tls.c
> > which didn't reference pthread_unwind.
> > Now it is resolved to a function from
> > libpthread/linuxthreads/pthread.c, and that file pulls in other
> > unused functions, which reference __GI___pthread_unwind,
> > and all the way down to the dl_iterate_phdr.
> > 
> > More details:
> >  http://lists.busybox.net/pipermail/buildroot/2016-November/177477.html
> 
> Sorry that I didn't looked into your report in more detail last time.
> May be I was too confused ;)
> 
> I really can't imagine that any code from libpthread/linuxthreads
> can be involved when we compile Xtensa with NPTL support.
> 
> I believe there is a bug or a change in behavior regarding static
> linking prior to 1.0.18.
> 
> See:
> wbx at helium:~/buildroot/output/build/uclibc-1.0.19 $ grep -r __pthread_initialize_minimal *                                                                          
> Binary file lib/libc.a matches
> Binary file libc/misc/internals/__uClibc_main.os matches
> libc/misc/internals/__uClibc_main.c:extern void weak_function __pthread_initialize_minimal(void);
> libc/misc/internals/__uClibc_main.c:extern void __pthread_initialize_minimal(void);
> libc/misc/internals/__uClibc_main.c:     * __pthread_initialize_minimal so we can use pthread_locks
> libc/misc/internals/__uClibc_main.c:    if (likely(__pthread_initialize_minimal!=NULL))
> libc/misc/internals/__uClibc_main.c: __pthread_initialize_minimal();
> libpthread/nptl_db/td_ta_thr_iter.c:      /* __pthread_initialize_minimal has not run.  There is just the main
> libpthread/nptl_db/td_ta_map_lwp2thr.c:     before __pthread_initialize_minimal has gotten far enough.  They
> libpthread/nptl_db/td_thr_validate.c:   /* __pthread_initialize_minimal has not run yet.
> libpthread/linuxthreads/internals.h:void __pthread_initialize_minimal (void);
> libpthread/linuxthreads/pthread.c:void __pthread_initialize_minimal(void)
> libpthread/nptl/init.c:void __pthread_initialize_minimal_internal (void) attribute_hidden;
> libpthread/nptl/init.c:__pthread_initialize_minimal_internal (void) 
> libpthread/nptl/init.c:strong_alias (__pthread_initialize_minimal_internal, 
> libpthread/nptl/init.c:       __pthread_initialize_minimal)
> libpthread/nptl/allocatestack.c:   initialize this, since it's done in __pthread_initialize_minimal.  */
> libpthread/nptl/sysdeps/generic/libc-tls.c:extern void __pthread_initialize_minimal(void) __attribute__((weak));
> libpthread/nptl/sysdeps/generic/libc-tls.c:__pthread_initialize_minimal (void)
> libpthread/nptl/sysdeps/generic/libc-tls.c:__pthread_initialize_minimal (void)
> libpthread/nptl/sysdeps/alpha/elf/pt-initfini.c:        bsr     $26, __pthread_initialize_minimal_internal !samegp \n\
> Binary file libpthread/nptl/sysdeps/xtensa/libc-tls.os matches
> Binary file libpthread/nptl/init.os matches
> Binary file utils/getconf matches
> 
> libpthread/nptl/sysdeps/xtensa/libc-tls.c includes
> libpthread/nptl/sysdeps/generic/libc-tls.c.
> 
> Prior to 1.0.18 libpthread.so was linked with special LDFLAGS:
> LDFLAGS-libpthread.so +=
> $(top_builddir)lib/$(UCLIBC_LDSO_NAME)-$(VERSION).so
> $(top_builddir)lib/libdl-$(VERSION).so \
>        -Wl,-z,nodelete,-z,initfirst,-init=$(SYMBOL_PREFIX)__pthread_initialize_minimal_internal
> 
> May be this might be a reason we see different behavior.

I think it is not the reason. I think it is just how pthread_cancel
and some other code in NPTL is implemented. There is some circular
dependency we can't change after we have integrated all the code in
libc.a. Musl does not use any functionality from libgcc, so it has
not the problem with the static linking issues we are seeing.

So as long as we have the pthread_cancel code which use libgcc
internally, we can't avoid any breakage from packages not correctly
passing -static while linking.

If anyone thinks the analysis is wrong, please speak up.

best regards
 Waldemar