This is the mail archive of the
mailing list for the GCC project.
Re: What's the right way to do host libraries required for gcc
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Nathanael Nerode <neroden at twcny dot rr dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 Nov 2002 14:51:52 -0500
- Subject: Re: What's the right way to do host libraries required for gcc
On Wednesday, November 13, 2002, at 02:13 PM, Nathanael Nerode wrote:
System libbanshee can't work right now, for two reasons (one obscure,
The "right way" is as follows...
Add an "--with-libbanshee=" argument to gcc's configure.in (using the
usual autoconf methods).
--without-libbanshee makes sure libbanshee is not used
--with-libbanshee=/foo/bar looks for libbanshee in /foo/bar
The obscure problem is the following:
libbanshee is only built as a static library (i didn't want to deal
with possible fun libtool issues right now), and one file uses setjmp
and longjmp. At least on darwin, the system compiler optimizes saving
and restoring of >2 fp registers in some cases using two assembly
functions that are in some library their gcc automatically adds. Since
the stage1 compiler isn't quite the same (the patch in question is
local to Apple's tree), and it doesn't auto-add this library and
doesn't have these functions, linking a system compiled libbanshee with
the stage1 compiled compiler will fail with unresolved symbols.
Less obscurely, I also had to rename two functions to avoid name
conflicts with public functions gcc has, so a system built libbanshee
wouldn't have the right names unless it was built from the gcc source
(I have libbanshee marked as no_install=true, to avoid screwing
anyone's installed libbanshee)
As one would imagine, to solve the first problem, i have it rebuild
libbanshee with the stage1 compiler before continuing on to stage2.
Unless shared libraries are allowed on all platforms (shared libraries
solve it by having the .so require whatever library actually contains
those symbols), i probably can't solve the obscure problem without
I should note that this problem isn't specific to libbanshee, as
libiberty would have the same problem on darwin if it met the trigger
requirements for this optimization to happen.
--with-libbanshee looks for libbanshee in ../libbanshee (as you have
it now)I've done this (i'd have to had done it, or else i wouldn't be able to
test the current method. :P)
(no argument) doesn't use libbanshee
Then change the top level to
1. Recognizelibbanshee as a directory to build; this is done in
2. Put in dependencies so that libbanshee is built before
gcc; this is done in Makefile.tpl right now, with a line like:
all-gcc bootstrap-gcc: all-libbanshee
I've done this too.
I'm going to change this method after a while, so watch out.
3. Automatically add --with-libbanshee to the arguments whenAhh, This is the key. I didn't think they were automatically passed
down, but i guess they'd have to be, since i remember you used to be
able to --enable-haifa and --enable-dwarf2 at the toplevel.
configuring the gcc subdirectory, if and only if nothing was specified
on the command line and libbanshee is in configdirs. This is done in
some abstruse mix of configure and configure.in at the moment and the
method will change when I finish making subdirectories configure from
Personally, I suggest skipping step 3 for the time being, since it
should be significantly easier after I'm further along in
autoconfiscation. This would just mean that people would have to use
--with-libbanshee to use Andersen's points-to analysis for now. (All
--with-foo arguments are passed down from the top level to
That's the "right way" to do it. You may not want to do it the "right
way", but I encourage you to.
If i didn't want to do it right, i wouldn't have asked.