Frank Heckenbach wrote:
Glenn Howes wrote:
Also, if I build my environment/library on a PowerPC using the build-on- powerPC-10.3.command, I end up with a different set of link problems involving the long double version of pow().
What's the problem here, does it only exist on 10.3, not 10.4?
Yes. __powidf2 was removed from the 10.4 SDK, I guess because there is no native long double pow operation on the x86.
AFAICS, this function is part of libgcc2 which is built and installed with GPC, and then its details (such as which functions are included) should match. So, problems here could happen if you install the GPC frontend (only) over an existing GCC installation (which is otherwise normally harmless). In this case, it might help to do a full install of GPC with corresponding GCC.
Or some such reason. So if I create my library against the 10.3 SDK I get an application which cannot run on 10.4 for PPC. I'm not even directly calling it, as far as I can tell.
The functions in libgcc2 are internally called by the backend (not even the frontend) for operations that are too large or complicated to be done inline (might depend on optimization options).
Just to be clear, I link in two static libraries: a universal version of the libgpc.a for the runtime, and a universal version of the library I've created. Neither of them contain the symbol _statvfs (at least I can't find that text in them).
Did you look with a binary search program (just to be sure), and perhaps also just for statvfs? (I don't know where the underscore comes from and which part adds it; I know it's added on Dos systems for link-compatibility with other compilers which in turn did it to work-around the silly Intel assembler syntax. I suppose such historical reasons don't apply on Mac OS.)
I just looked with my text editor, and I didn't look for the underscores, just the statvfs.
Text editors may not find everything in binary files for various reasons, including automatic line wraps, word-only searches, etc. To be sure, you can try "grep -l statvfs filename".
Om Mac OS X, the command nm -f object_file will give you a list of symbols in a library or executable.
As for the 10.4 built PPC GPC, _statvfs is in the linked executable for even the most trival Hello world program. You can get rid of some libgcc symbols by telling the linker to dead strip out unused symbols but not _statvfs.
As for __powidf2, I don't presently have a runnable Mac OS X 10.3 so I haven't been able to investigate that one in much detail.
As to the underscore prefix, perhaps it is historical reasons similar to what you say about Dos systems. Most of Apple's build tools and Mach-O object file format derives from NeXT which did have the capability of building for and running on some x86 based systems.
Frank, for your information, the *.command files Glenn has referred to are really just plain text shell scripts. They are a user convenience feature Adriaan added to his Mac OS X GPC "compiler sources" download package. They capture everything Adriaan knew at the time he put them together on what it took to get a successful GPC build on Mac OS X version identified in the name of the .command file. In looking at the shell commands in the files, all three of the .command precanned builds do a full install from a FSF gcc sources base. The powerPC-10.4 and intel scripts build both native and cross compilers. The powerPC-10.3 just builds a native PPC compiler (and I presume the script assumes the compiler is being built on a Msac OS X 10.3 PPC Mac).
Adriaan is the Mac OS X GPC build guru, but he is super tied up now and for some time in the future with a "pays the bills" project so he doesn't have much if any free time available to respond to Mac OS X GPC configuration and building questions.
Gale Paeper gpaeper@empirenet.com