[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140128122027.GR1685@port70.net>
Date: Tue, 28 Jan 2014 13:20:28 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Statically linking musl with lto optimizations
* Chris Anderson <cjanderson@...dex.com> [2014-01-28 01:52:46 +0000]:
> I just wanted to know if anyone has tried this and if so with what success?
i think it was tried before
my native toolchain cannot do lto but i tried musl-cross and it seems
to work without any tricks:
tar xJf crossx86-i486-linux-musl-0.9.15.tar.xz
git clone git://git.musl-libc.org/musl
cd musl
# usig `pwd` to make install a nop
# cross compilation disables the wrapper, but i want to use it
./configure CROSS_COMPILE=../i486-linux-musl/bin/i486-linux-musl- CFLAGS=-flto --syslibdir=`pwd`/lib --prefix=`pwd` --disable-shared --enable-gcc-wrapper
make
make install
cat >t.c <<EOF
#include <stdio.h>
int main() {printf("hello\n");}
EOF
# -static is not needed, we only built libc.a
REALGCC=../i486-linux-musl/bin/i486-linux-musl-gcc tools/musl-gcc -static -flto t.c
./a.out
> I have tried adding the -flto and -fuse-linker-plugin to my CFLAGS but when I go and link against the static lib/libc.a archive I get a lot of unresolved symbols. I fixed this by changing the makefile thus:
>
> 38 AR = $(CROSS_COMPILE)gcc-ar
> 39 RANLIB = $(CROSS_COMPILE)gcc-ranlib
>
> which is described in this thread http://permalink.gmane.org/gmane.comp.gcc.patches/221033
i think you only need this if binutils was built without plugin support
> This meant that the archive was being created correctly.
>
> The problem that I now have is that if I use
> If I use ./bin/musl-gcc -flto=5 -fuse-linker-plugin -o test test.c I get a whole lot of unresolved symbols being spewed out by the linker.
>
> If I try and link using gcc without gcc libs and but without the musl spec file, ie gcc -flto=5 -fuse-linker-plugin -static -nostdlib all is good apart from an undefined reference to __dynlink.
>
if you use -nostdlib you need to do more work
(provide the musl crt*.o and libgcc the way the spec file describes)
(you are linking the _start symbol of the loader now, libc.so has
its own _start so you can execute it as a loader, if you correctly
specify the crt*o files then your app gets the right _start that
does not reference __dynlink)
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.
