This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RF{C,T,H/darwin}: Toplevel libgcc
On Tue, Dec 06, 2005 at 02:12:03PM -0800, Geoffrey Keating wrote:
> > The Darwin bits are just too weird for me to fix without being able to test
> > them. "lipo" looks like it wants information about every multilib; that's
> > tricky outside of the gcc directory, because we build one at a time. We can
> > reshuffle the build order to make that happen if necessary, but I'd like
> > someone who understands what it's doing to take a look before I do (Geoff, I
> > have the feeling that means you).
>
> Yes, it really wants information about every multilib. You can think
> of 'lipo' as something like 'ar', but for executables of multiple
> architectures instead of .o files. The aim is that eventually you get:
>
> $ file /usr/lib/libgcc_s.10.4.dylib
> /usr/lib/libgcc_s.10.4.dylib: Mach-O fat file with 3 architectures
> /usr/lib/libgcc_s.10.4.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library stub ppc64
> /usr/lib/libgcc_s.10.4.dylib (for architecture ppc): Mach-O dynamically linked shared library stub ppc
> /usr/lib/libgcc_s.10.4.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386
>
> (although only two of those are built in this tree, ppc & ppc64).
Ah, I see. In that case, you can detect the top multilib directory and
build it there - I believe there's an appropriate check on one of the
MULTI* variables that will work, including with --disable-multilib, and
give you the list of subdirs. Then move the DO=all bit from all: to a
new phony rule, have all depend on that, and have the
libgcc_s.10.4.dylib target also depend on that.
> Could you put this on a branch so I can look at it, try to build it, etc.?
Sure. Now on branches/libgcc-toplevel. Should short-lived branches be
documented on the web pages?
--
Daniel Jacobowitz
CodeSourcery, LLC