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

[Nathanael Nerode <neroden at twcny dot rr dot com>]

> Daniel Berlin quoth:
>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).
So for now don't make that an option.  But in the long run do. :-)

> 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.
Ah yes, *this* problem.

>
> 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.
Ah.  :-)  Maybe you can get someone to rename their 
functions in the long run?

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

We're going to get libiberty staged eventually.  Currently I hope
this will come out naturally (!) from my Makefile rewrite work, by 
creating a generalized scheme which applies to native and cross builds 
in about the same way.

(For example, in the cross scheme, build-libiberty and host libiberty 
are built separately with different dependencies; the concept is to 
handle stage1-libiberty and stage2-libiberty using exactly the same 
method, and in fact preferably using the same code in the Makefile.tpl.  
It's tricky to get exactly right but I think I can.)

Just FYI.