All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waldemar Brodkorb <wbx@openadk.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] autossh: honour LDFLAGS
Date: Wed, 30 Nov 2016 06:00:04 +0100	[thread overview]
Message-ID: <20161130050003.GS14207@waldemar-brodkorb.de> (raw)
In-Reply-To: <CAMo8BfJAGT8cdvQ2xMx33HKDwW34XP6wVxHd1yn-UxAyQEYpRA@mail.gmail.com>

Hi Max,
Max Filippov wrote,

> On Tue, Nov 29, 2016 at 12:43 AM, Thomas Petazzoni
> <thomas.petazzoni@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.

best regards
 Waldemar

  reply	other threads:[~2016-11-30  5:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-25 18:00 [Buildroot] [PATCH] autossh: honour LDFLAGS Waldemar Brodkorb
2016-11-28 21:28 ` Thomas Petazzoni
2016-11-28 23:22   ` Max Filippov
2016-11-29  4:16   ` Waldemar Brodkorb
2016-11-29  8:43     ` Thomas Petazzoni
2016-11-29 22:50       ` Max Filippov
2016-11-30  5:00         ` Waldemar Brodkorb [this message]
2016-12-01 18:20           ` Waldemar Brodkorb
2016-12-02  5:12           ` Max Filippov
2016-12-02  5:25             ` Waldemar Brodkorb
2016-12-03  2:12               ` Max Filippov
2016-12-04 12:06                 ` Waldemar Brodkorb
2016-12-05  3:24                   ` Max Filippov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161130050003.GS14207@waldemar-brodkorb.de \
    --to=wbx@openadk.org \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.