* Statically linking musl with lto optimizations
@ 2014-01-28 1:52 Chris Anderson
2014-01-28 12:20 ` Szabolcs Nagy
0 siblings, 1 reply; 2+ messages in thread
From: Chris Anderson @ 2014-01-28 1:52 UTC (permalink / raw)
To: musl
Hi
I just wanted to know if anyone has tried this and if so with what success?
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
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 I add a dummy __dynlink then the whole program links of course it wont execute because the .bss and other segments are not configured.
What is the correct way to do this?
Cheers
Chris
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Statically linking musl with lto optimizations
2014-01-28 1:52 Statically linking musl with lto optimizations Chris Anderson
@ 2014-01-28 12:20 ` Szabolcs Nagy
0 siblings, 0 replies; 2+ messages in thread
From: Szabolcs Nagy @ 2014-01-28 12:20 UTC (permalink / raw)
To: musl
* Chris Anderson <cjanderson@yandex.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)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-01-28 12:20 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-28 1:52 Statically linking musl with lto optimizations Chris Anderson
2014-01-28 12:20 ` Szabolcs Nagy
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).