Re: tweak for documentation of how to create universal binaries

2009-04-19 Thread Bruno Haible
Ralf Wildenhues wrote: > In the > patch that I sent, there is an "icc" case match. If you omit that match > from the patch, does not specifying --enable-dependency-tracking still > cause depmode=none for gcc in universal mode? Yes. Without --enable-dependency-tracking: depmode=none. With --enable

Re: tweak for documentation of how to create universal binaries

2009-04-19 Thread Ralf Wildenhues
Hi Bruno, * Bruno Haible wrote on Sun, Apr 19, 2009 at 05:15:19PM CEST: > Ralf Wildenhues wrote: > > The patch below (against Automake) should do the trick. > > Can you try it out, and report back the depmode chosen with and without > > --enable-dependency-tracking and whether the depmode works (i

Re: tweak for documentation of how to create universal binaries

2009-04-19 Thread Bruno Haible
ee if the "icc" depmode bit can be omitted from the > patch? At this point in time, "icc" for MacOS X does not support the "-arch" option that Apple's gcc supports. The icc documentation [1] states that in order to create universal binaries on MacOS X, one should

Re: document how to create universal binaries

2008-08-19 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter O'Gorman on 8/17/2008 4:31 PM: > In the majority of cases there are no problems building universal > binaries in this manner. But there are enough cases where it does not > build, or where it builds but has pro

Re: document how to create universal binaries

2008-08-17 Thread Peter O'Gorman
. I would, however, remove the -arch ppc from the CPP and CXXCPP, i.e. just CPP='gcc -E' CXXCPP='g++ -E' to get the native preprocessor, whatever that may be. In the majority of cases there are no problems building universal binaries in this manner. But there are enough cases w

Re: document how to create universal binaries

2008-08-17 Thread Bruno Haible
Peter O'Gorman wrote: > > +On MacOS X systems, you can create libraries and executables that work > > For 10.4.x ppc you had to install an SDK and add -isysroot flags. ok, please change to doc patch to say "On MacOS X systems, version 10.5 or newer". > For automake using projects --disable-depen

Re: document how to create universal binaries

2008-08-17 Thread Peter O'Gorman
-- known as "fat" or "universal" binaries -- > +by specifying multiple @option{-arch} options to the compiler but only > +a single @option{-arch} option to the preprocessor. Like this: > + > [EMAIL PROTECTED] > +./configure CC="gcc -arch i386 -arch x86_

Re: document how to create universal binaries

2008-08-17 Thread Bruno Haible
Andreas Schwab wrote: > It is preferred to pass variable settings as arguments ... You're right, of course. Here is a revised patch. 2008-08-17 Bruno Haible <[EMAIL PROTECTED]> * doc/install.texi (Compiling For Multiple Architectures): Explain how to create univ

Re: document how to create universal binaries

2008-08-17 Thread Andreas Schwab
Bruno Haible <[EMAIL PROTECTED]> writes: >env CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ >CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ >CPP="gcc -arch ppc -E" \ >CXXCPP="g++ -arch ppc -E" \ >./configure It is prefe

Re: document how to create universal binaries

2008-08-17 Thread Erik de Castro Lopo
piling For Multiple Architectures" from the INSTALL > file of so many GNU packages, I was under the impression that it was hard > to build universal binaries for packages that use autoconf. But this is > actually not the case. Among the 4 packages I tested (libiconv, libsigsegv, >

document how to create universal binaries

2008-08-17 Thread Bruno Haible
der the impression that it was hard to build universal binaries for packages that use autoconf. But this is actually not the case. Among the 4 packages I tested (libiconv, libsigsegv, gettext, gperf), all but one can be built as universal binaries out of the box, given the appropriate instructions,

Re: Darwin universal binaries and LDFLAGS conundrum

2007-05-24 Thread Martin-Gilles Lavoie
On 24 mai 2007, at 14:54, Peter O'Gorman wrote: I've learned a few things in the past few days as far as this thing is concerned. I can not discuss features of Leopard on this list, you should not either. Yeah. So was the extend of the discussed XCode/Leopard features I mentioned, straig

Re: Darwin universal binaries and LDFLAGS conundrum

2007-05-24 Thread Peter O'Gorman
On Thu, 2007-05-24 at 14:16 -0400, Martin-Gilles Lavoie wrote: > On 23 mai 2007, at 10:03, Martin-Gilles Lavoie wrote: > This is just an update on the status of my problem for you guys to be > curious at. At this moment, I'm waiting for some info from the > BerkeleyDB guys (their autoconf envi

Re: Darwin universal binaries and LDFLAGS conundrum

2007-05-24 Thread Martin-Gilles Lavoie
On 23 mai 2007, at 10:03, Martin-Gilles Lavoie wrote: [snip] To resume the problem, I need to build a Universal Binary (aka, PPC + i386) library of BerkeleyDB. Now, normally, this is a simple task but it seems Autoconfig is working against me. At the strict minimum, I need to have the fol

Re: Darwin universal binaries and LDFLAGS conundrum

2007-05-24 Thread Peter O'Gorman
On Thu, 2007-05-24 at 09:56 +1000, Bill Northcott wrote: > On 24/05/2007, at 2:00 AM, Martin-Gilles Lavoie wrote: > > To resume the problem, I need to build a Universal Binary (aka, PPC + > > i386) library of BerkeleyDB. Now, normally, this is a simple task but > > it seems Autoconfig is working ag

Re: Darwin universal binaries and LDFLAGS conundrum

2007-05-23 Thread Bill Northcott
On 24/05/2007, at 2:00 AM, Martin-Gilles Lavoie wrote: To resume the problem, I need to build a Universal Binary (aka, PPC + i386) library of BerkeleyDB. Now, normally, this is a simple task but it seems Autoconfig is working against me. At the strict minimum, I need to have the following flags

Re: Darwin universal binaries and LDFLAGS conundrum

2007-05-23 Thread Peter O'Gorman
On Wed, 2007-05-23 at 10:03 -0400, Martin-Gilles Lavoie wrote: > Greetings > > First, I'd like to apologize upfront for the sheer autoconf noob-ness > this post might impose on vets possibly on this list. But as luck > would have it, I seem to be stuck with the job of dealing with an > autoc

Re: Darwin universal binaries and LDFLAGS conundrum

2007-05-23 Thread Keith MARSHALL
Martin-Gilles Lavoie wrote: > At the strict minimum, I need to have the following flags set > in the generated makefile: > > CFLAGS = -c $(CPPFLAGS) -O3 -isysroot \ > /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc > LDFLAGS = -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk > >

Darwin universal binaries and LDFLAGS conundrum

2007-05-23 Thread Martin-Gilles Lavoie
Greetings First, I'd like to apologize upfront for the sheer autoconf noob-ness this post might impose on vets possibly on this list. But as luck would have it, I seem to be stuck with the job of dealing with an autoconf.ac script of ours wich doesn't seem to want to play nice with the t

Re: "Universal Binaries"

2006-02-17 Thread Paul Eggert
Bob Friesenhahn <[EMAIL PROTECTED]> writes: > Does anyone else see that this defeats the purpose of autoconf Well, Apple doesn't think it's quite that bad. There are admittedly some gotchas and workarounds. See Apple Technical Note TN2137, Building Universal Binaries fro

Re: "Universal Binaries"

2006-02-17 Thread Bob Friesenhahn
On Thu, 16 Feb 2006, David Fang wrote: For discussion reference, the recipe(s) for manually configuring a universal binary can be found here: http://developer.apple.com/technotes/tn2005/tn2137.html There you can see a few ways of achieving the same result. To get around the pro

Re: "Universal Binaries"

2006-02-17 Thread David Fang
> It seems that Apple's OSX has introduced something known as a > "Universal Binary" in which the compiler conveniently compiles for > both PowerPC and Intel in one whack. Libraries and executables then > automatically "work" for both architectures. > > Does anyone else see that this defeats the p

"Universal Binaries"

2006-02-16 Thread Bob Friesenhahn
It seems that Apple's OSX has introduced something known as a "Universal Binary" in which the compiler conveniently compiles for both PowerPC and Intel in one whack. Libraries and executables then automatically "work" for both architectures. Does anyone else see that this defeats the purpose