[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120420120541.3616f66f@newbook>
Date: Fri, 20 Apr 2012 12:05:41 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: musl vs wireless-tools
On Fri, 20 Apr 2012 12:41:06 -0400
Rich Felker <dalias@...ifal.cx> wrote:
> On Fri, Apr 20, 2012 at 09:23:11AM -0700, Isaac Dunham wrote:
> > Getting farther...
> > But still not working.
..
> Not sure what's happening here; why not add -v to the command line so
> gcc shows you the actual commands it's passing to the compiler (cc1)
> and linker (collect2/ld)?
Attaching the logs--I'm sure there's something hiding in there.
> There's one other line that looks odd; I'll repeat it here:
> > musl-gcc -shared -o libiw.so.30 -Wl,-soname,libiw.so.30 -lm -lc
> > iwlib.so
>
> Having only libraries (-lm -lc iwlib.so) as input for the linker makes
> no sense. Can you tell what they're trying to do? I'm doubtful that
> even the package authors knew what they were trying to do here. If
> it's possible to build this package static-linked (or at least with
> none of its own .so files) that would be a much smarter approach).
Apparently, iwlib.c gets compiled as iwlib.so rather than iwlib.o; this
gets linked into libiw.so.30 (and is used in archiving libiw.a).
Also fails with STATIC...in fact, it's even more spectacular
All libraries (lib*.a, libc.so) present, however.
For whatever reason, this DOES build when real gcc is used on glibc.
Isaac Dunham
Download attachment "make.err.gcc" of type "application/octet-stream" (44703 bytes)
Download attachment "make.errs" of type "application/octet-stream" (38006 bytes)
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.
