Re: What's the right way to do host libraries required for gcc

[Daniel Berlin <dberlin at dberlin dot org>]

On Wednesday, November 13, 2002, at 02:13  PM, Nathanael Nerode wrote:

> 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
System libbanshee can't work right now, for two reasons (one obscure, 
one not).
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 
tree.

(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 
doing this.

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)
> (no argument) doesn't use libbanshee
>
> Then change the top level to
> 1. Recognizelibbanshee as a directory to build; this is done in
> Makefile.def
I've done this (i'd have to had done it, or else i wouldn't be able to 
test the current method. :P)
> 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.
Whee!

> 3. Automatically add --with-libbanshee to the arguments when
> 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
> the Makefile.
>
> 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 
> subdirectories.)
Ahh, 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.

> That's the "right way" to do it.  You may not want to do it the "right
> way", but I encourage you to.
I will.
If i didn't want to do it right, i wouldn't have asked.
:)
> --Nathanael