On 2/25/07, Ryan Schmidt <ryandesign@macports.org> wrote:

http://trac.macports.org/projects/macports/changeset/22269

Why are -O and -g being used in the universal variant?

Probably because the author copy-pasted the Technical Note TN2137 <http://developer.apple.com/technotes/tn2005/tn2137.html> example ;-) By the way, this technical note also says: "Note: On an Intel-based Macintosh system the libraries are already universal, and support the Intel and PowerPC architectures, and you may specify only the -arch i386 -arch ppc options for CFLAGS; on a PowerPC-based Macintosh, you must use the MacOSX10.4u SDK" If I remember correctly from the tests I did some time ago, "you may specify only" should read "you must specify only". Specifying the isysroot on Intel Macs would fail the compilation! So this command: env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc" ./configure ... would work on PPC Macs but would fail on Intel Macs. As I'm not on an Intel Mac right now, I can't test. Can anyone confirm this ?

On 2/25/07, Ryan Schmidt <ryandesign@macports.org> wrote:

My understanding is that -g turns on some kind of debugging code, and -O is an optimization level.

Absolutely.

Neither of those seem to me to have any bearing on a universal binary. That is: if -g or -O are useful, then they would be useful for all ports at all times, and not just in the +universal variants of some ports.

You are absolutely right about the whole thing. I don't understand why "-g -O" are used in the example. They could as well have added "-funroll-loop -fanother-option etc." and hundreds other gcc flags that are irrelevant to a universal build to confuse readers even more.

I don't see why that would be so. The universal 10.4 SDK is there to provide you with universal versions of system libraries regardless of what platform you're building on. It should always be safe and correct to use the universal SDK.

I don't see why either. I just said that if I remember correclty, specifying isysroot on Intel Mac would lead the build to fail. I may be wrong however, I tested this several months ago and I don't remember the details.

I do not believe your assessment is correct here either. I believe using...

env CFLAGS="-arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc" ./ configure

...would produce a universal binary on an Intel Mac,

That's what I was trying to say also. I said using isysroot on Intel would fail, I did not say not using it would fail. I try once again: env CFLAGS="-arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc" ./configure ... on ppc: fail because system libs are not universal on i386: ok because system libs are universal env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc" ./configure ... on ppc: ok because univeral libs must be used on i386: fail because of an unknown reason. I may be wrong on this point, I may have tested with an older version of gcc. I will test again as soon as I'm on my Intel Mac. I hope this is clearer this time ;-)

o > Neither of those seem to me to have any o > bearing on a universal binary. That is: if -g or -O are useful, then o > they would be useful for all ports at all times, and not just in the o > +universal variants of some ports. o o You are absolutely right about the whole thing. I don't understand why o "-g -O" are used in the example. They could as well have added o "-funroll-loop -fanother-option etc." and hundreds other gcc flags o that are irrelevant to a universal build to confuse readers even more. Peering into the minds of Apple's documentation writers (I know, my eyes will be burned), there may be a reason for this. -O turns on optimization. The default is -O0 (no optimization), and there are libraries that actually fail when built that way. The compiler is designed and tested mostly at -O1, so Apple may know something we don't. As for -g, Tiger has debugging facilities that send information to Apple, and I could see this as providing hooks for Apple fetching that information. I am just speculating, but I would follow the TN unless given a reason to do otherwise. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University

On 2007-02-25 11:12:48 -0500, Salvatore Domenick Desiano wrote:

Peering into the minds of Apple's documentation writers (I know, my eyes will be burned), there may be a reason for this. -O turns on optimization. The default is -O0 (no optimization), and there are libraries that actually fail when built that way. The compiler is designed and tested mostly at -O1, so Apple may know something we don't.

Do you mean that -O2 (which normally produces faster and smaller code) should not be used?

As for -g, Tiger has debugging facilities that send information to Apple, and I could see this as providing hooks for Apple fetching that information.

This is not specific to Apple. -g allows the compiler to produce debugging information. Such information is useful in bug reports when a program crashes and a backtrace is included in the report. But it takes more disk space. Similarly, one may choose to strip binaries or not. IMHO, the choice to do that or not should be a global option. Therefore those who have plenty of disk space could choose to keep debugging information (in case a program crashes), and those who are short of disk space could choose to remove them. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

On Feb 25, 2007, at 8:44 PM, Salvatore Domenick Desiano wrote:

I've seen programs that have trouble with -O2 and -O3, but only a small number and typically data-intensive programs like image manipulation. No reason you couldn't use it, but stability is very important to Apple, so I would follow their reccomendation for the default.

Apple's normal recommendation is -Os, I'm fairly certain that -O -g aren't meant to be instructive in that article.

o But it takes more disk space. Similarly, one may choose to strip o binaries or not. IMHO, the choice to do that or not should be a global o option. Therefore those who have plenty of disk space could choose to o keep debugging information (in case a program crashes), and those who o are short of disk space could choose to remove them.

Maybe a global MP option to disable debugging info for people who are short on disk space and know what they're doing.

It's probably better to have it disabled by default. The debug information is a not-insignificant amount of space. (here's a non-macports example of one library I have installed: -rwxr-xr-x 1 root wheel 3M Jan 18 08:20 QtCore* -rwxr-xr-x 1 root wheel 43M Jan 18 08:20 QtCore_debug*) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+