[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SNT146-W57DA20C05E7DE2C6A6AE3DA8490@phx.gbl>
Date: Thu, 8 May 2014 03:08:41 +0100
From: Stephen Thomas <scjthm@...e.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: RE: Linking musl with ld.gold
> On Wed, May 07, 2014 at 01:04:43PM +0300, Timo Teras wrote:
> > On Wed, 7 May 2014 10:04:24 +0100
> > Stephen Thomas <scjthm@...e.com> wrote:
> >
> > > > only the object files with referenced symbols are linked from an
> > > > archive
> > > >
> > > > so only a.o with the given main.o because of the symbol f
> > > >
> > > > now if you make some reference in main.c such that b.o should
> > > > be included but main still returns 0 that would be a bug
> > > >
> > > > eg. add a void g(void){} to b.c and call it from main.c
> > >
> > > Ok, thanks for that info. It appears that there is a problem in gcc
> > > 4.9 and not 4.8.3.
> >
> > Is perhaps -ffunction-sections and/or -fdata-sections added
> > automatically? Those would break musl like experienced.
>
> They should not break musl; if they do, it's a compiler bug. The
> strong symbol that overrides the weak symbol elsewhere is not unused
> and available for garbage collection because it's referenced.
>
> I suspect your claim is just wrong, since IIRC people have
> successfully used these options with musl.
I will raise an issue with the gcc team (but I don't really want to build from git, as it takes too long). I am not saying that the library doesn't work, I am merely saying that there was a bug where stdout was not being flushed, and this in my opinion was due to the weak symbol in fflush not being overridden. I did run that single test case on the two different builds and the result was different. This was on two clean buildroot branches based on uclibc.
I don't understand what you mean by garbage collection. Basically, if I understand this correctly, there is a weak symbol defined in fflush.c for the purpose of allowing this file to run without the an implementation that initialises the real symbol with the internal implementation of stdout (which is just basically a manufactured wrapper around file descriptor number 1). This is good as far as unit testing goes, doesn't use #defines but the linker -- good stuff. However, when I noticed was that the prompt on busybox using musl was not appearing until after a new line was entered, I added a discovered that the value of the pointer was 0 (NULL). If you still suspect that my claim is wrong, then I believe you are saying that this is not the case. It would be nice if someone who has gcc 4.9 installed could run either run the test or check that busybox is working.
Thomo
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
