Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 27 Feb 2012 21:34:40 -0500
From: Rich Felker <>
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:


libgcc.a%s %:if-exists(libgcc_eh.a%s)


/path/to/musl/lib/crt1.o /path/to/musl/lib/crti.o crtbegin.o%s

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

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-$ -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.


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.