[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 27 Feb 2012 21:34:40 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: ideas for new gcc wrapper, purely specfile based
Hi all,
I've been working on the gcc wrapper script (which I'm still not happy
with), and I think I can get much cleaner behavior by removing most of
the linking-related logic from the wrapper script itself and instead
just using a custom specfile that looks roughly like the following:
*link_libgcc:
-L/path/to/musl/lib
*libgcc:
libgcc.a%s %:if-exists(libgcc_eh.a%s)
*cc1:
%(cc1_cpu)
*startfile:
/path/to/musl/lib/crt1.o /path/to/musl/lib/crti.o crtbegin.o%s
*endfile:
crtend.o%s /path/to/musl/lib/crtn.o
Note that the %s suffix on some filenames causes the gcc "compiler
driver" (the gcc binary itself which calls cc1, ld, etc.) to resolve
the filename from its builtin library path, but then the custom
link_libgcc directive omits this builtin path and just hard-codes the
musl path when passing -L options to the linker. This makes it so only
the gcc start files and libgcc files get pulled from the builtin path.
The cc1 directive is there to remove stack protector, PIE, etc.
defaults that hackish distros may have added to the system-wide
specfile.
With this aproach, the musl-gcc wrapper script basically becomes just:
gcc -specs /path/to/musl/specfile \
-nostdinc \
-isystem /path/to/musl/include \
-isystem /path/to/gcc/include \
"$@" \
-Wl,-dynamic-linker,/path/to/musl/ld-musl-$ARCH.so.1 -Wl,-nostdlib
Anyone using the wrapper willing to play around with this setup a
little bit and see if it behaves as expected or if there are any
undesirable corner case issues?
By the way, the -v (verbose) option to gcc is really helpful for
testing things like this. It lets you see the command lines passed to
cc1, the linker, etc.
Rich
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.
