This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

The "right way" is as follows...

Add an "--with-libbanshee=" argument to gcc's (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
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.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]