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