Hello, After months of being distracted by another portion of my application, I'm back to creating a universal binary version of the Pascal based library we are linking into our C++ based application. The problem is the application will not launch under PPC on Mac OS X 10.3 (Panther). The console registers an undefined symbol: _statvfs expected to be defined in /usr/lib/libSystem.B.dylib
After some research, I found this call is being used by the StatFS routine implemented in rts.c (line 1510) /** Get information about a file system. */ GLOBAL (Boolean _p_StatFS (char *Path UNUSED, StatFSBuffer *Buf)) { int Result; #ifdef HAVE_STATVFS struct statvfs b; errno = 0; Result = statvfs (Path, &b); Buf->BlockSize = (long long int) b.f_frsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_favail; #elif defined (HAVE_STATFS) struct statfs b; errno = 0; Result = statfs (Path, &b); Buf->BlockSize = (long long int) b.f_bsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_ffree; #else Result = -1; errno = ENOSYS; #endif if (Result == 0) return True; Buf->BlockSize = 0; Buf->BlocksTotal = 0; Buf->BlocksFree = 0; Buf->FilesTotal = 0; Buf->FilesFree = 0; return False; }
It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files, which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library). 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(). Besides which, I'd prefer to do my development on OS X for Intel going forward.
I have tried hand editing the above routine and rebuilding my Pascal development environment, and pulling the statvfs.h file from my OS X SDK, and yet when my application links, it still has an unresolved reference to _statvfs. I'm not a build engineer, as my previous missives to this mailing list make clear, and I'm at a loss as to how to proceed.
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). I link that with my application. The application now references _statvfs (I can now see the text in it's executable). I can't launch on 10.3. I comment out the calls to the Pascal library and recompile+relink, and the application no longer has the symbol and I can launch under 10.3. So something in either of the gpc associated libraries must be calling something which calls statvfs, making the linker (ld) mark statvfs as an unresolved symbol to be loaded in at runtime. At least that is my impression.
So, I'd appreciate some suggestions.
--glenn
Glenn Howes wrote:
It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files,
More precisely, if the statvfs function exists in the library. The RTS configure script tries to compile and link a dummy program containing a reference to this function, and checks whether that works. Likewise for statfs and HAVE_STATFS. The header is also checked, that's HAVE_SYS_STATVFS_H.
which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library).
Normally, configuration should always be done on the "weakest" system, so better systems will work due to backward-compatibility. If that's not possible (as I understand, though I don't know much about Mac OS libs), one could hand-edit the generated file gcc/p/rts/rts-config.h, then rebuild the RTS (remove gcc/p/rts/rts.o and do make again).
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?
Besides which, I'd prefer to do my development on OS X for Intel going forward.
I can't follow you here (as I said, I don't know much about Mac), is this about system versions or platforms? If 10.3 doesn't work on Intel (if that's the problem), can't you use 10.3 for PPC and 10.4 for Intel?
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.)
Otherwise, I don't really understand what's going on here.
Frank
Frank, Thanks for getting back to me. I will try this before the week is out and get back to you.
On Oct 3, 2006, at 4:37 PM, Frank Heckenbach wrote:
Glenn Howes wrote:
It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files,
More precisely, if the statvfs function exists in the library. The RTS configure script tries to compile and link a dummy program containing a reference to this function, and checks whether that works. Likewise for statfs and HAVE_STATFS. The header is also checked, that's HAVE_SYS_STATVFS_H.
which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library).
Normally, configuration should always be done on the "weakest" system, so better systems will work due to backward-compatibility. If that's not possible (as I understand, though I don't know much about Mac OS libs), one could hand-edit the generated file gcc/p/rts/rts-config.h, then rebuild the RTS (remove gcc/p/rts/rts.o and do make again).
I had thought I'd done the equivalent of that, but perhaps I missed something.
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. 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.
Besides which, I'd prefer to do my development on OS X for Intel going forward.
I can't follow you here (as I said, I don't know much about Mac), is this about system versions or platforms? If 10.3 doesn't work on Intel (if that's the problem), can't you use 10.3 for PPC and 10.4 for Intel?
Yes. 10.3 does not run on Intel.
I could, but either way I'm getting a runtime resolution error for a missing symbol. __powidf2 or statvfs.
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.
Otherwise, I don't really understand what's going on here.
Neither do I.
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
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
Gale Paeper wrote:
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.
Yes, I know, because the RTS isn't "smart-linkable".
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.
I don't know details about those, but the historical reasons I mentioned refer specifically to Dos, not to x86. In fact, Linux on x86 doesn't have the underscore.
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.
Do they do a make install (everything), pascal.install (GPC only), or pascal.install-with-gcc (GPC plus required GCC parts)? In the first and last case, such a mismatch shouldn't happen, if paths are correct and everything, of course.
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.
Actually me too, as can be seen from the sparseness of my postings here ...
Frank
Frank Heckenbach wrote:
Gale Paeper wrote:
[snip]
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.
Do they do a make install (everything), pascal.install (GPC only), or pascal.install-with-gcc (GPC plus required GCC parts)? In the first and last case, such a mismatch shouldn't happen, if paths are correct and everything, of course.
All the native compilers built are built with "sudo make install". The cross compilers have more elaborate make commands.
The relevant lines from the build-on-powerpc-10-4.command script are (watch out for line wrapping):
A) native host PPC compilers:
sudo rm -R -f build mkdir -p build cd build ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 make STAGE1_CFLAGS="-g -DHAVE_DESIGNATED_INITIALIZERS=0" bootstrap sudo make install
B) 10.4 PPC hosted Intel cross compiler:
sudo rm -R -f build-cross mkdir -p build-cross cd build-cross ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=i386-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 --with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk/ --with-arch=pentium-m --with-tune=prescott make RANLIB_FOR_TARGET=ranlib AR_FOR_TARGET=ar NM_FOR_TARGET=nm CC=/Developer/Pascal/gpc345u2/bin/gcc sudo make RANLIB_FOR_TARGET=ranlib AR_FOR_TARGET=ar NM_FOR_TARGET=nm install
There is quite a bit more in the scripts, but I think those are the lines that are relevant to your question. (The B part appears after the A part in the script.)
Before those lines the script does quite a few other things getting everything done that needs to be done to successfully and correctly execute those particular lines.
Each of the three .command script files is on the order of 170 line each which is a litte bit too much to post in full. If you want copies to see the full context to help in providing help with Glenn's problem, let me know and I can send you copies direct to you by e-mail.
Gale Paeper gpaeper@empirenet.com
The anti-climatic result for this problem was I downloaded the pre- compiled binary versions of GPC and used them to compile the halves of the universal version of the library which will be distributed as linked into the application. I then used lipo to form the universal library.
The problem was with the version compiled via the "make on 10.4" and "make on 10.3" scripts. Of course, this means I will have to use the version compiled on my machine while debugging, and a separate version for release, but I hope that will not lead to any problems.
On Oct 4, 2006, at 11:59 AM, Gale Paeper wrote:
Frank Heckenbach wrote:
Gale Paeper wrote:
[snip]
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.
Do they do a make install (everything), pascal.install (GPC only), or pascal.install-with-gcc (GPC plus required GCC parts)? In the first and last case, such a mismatch shouldn't happen, if paths are correct and everything, of course.
All the native compilers built are built with "sudo make install". The cross compilers have more elaborate make commands.
The relevant lines from the build-on-powerpc-10-4.command script are (watch out for line wrapping):
A) native host PPC compilers:
sudo rm -R -f build mkdir -p build cd build ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 -- prefix=/Developer/Pascal/gpc345u2 make STAGE1_CFLAGS="-g -DHAVE_DESIGNATED_INITIALIZERS=0" bootstrap sudo make install
B) 10.4 PPC hosted Intel cross compiler:
sudo rm -R -f build-cross mkdir -p build-cross cd build-cross ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=i386-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 --with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk/ --with-arch=pentium- m --with-tune=prescott make RANLIB_FOR_TARGET=ranlib AR_FOR_TARGET=ar NM_FOR_TARGET=nm CC=/Developer/Pascal/gpc345u2/bin/gcc sudo make RANLIB_FOR_TARGET=ranlib AR_FOR_TARGET=ar NM_FOR_TARGET=nm install
There is quite a bit more in the scripts, but I think those are the lines that are relevant to your question. (The B part appears after the A part in the script.)
Before those lines the script does quite a few other things getting everything done that needs to be done to successfully and correctly execute those particular lines.
Each of the three .command script files is on the order of 170 line each which is a litte bit too much to post in full. If you want copies to see the full context to help in providing help with Glenn's problem, let me know and I can send you copies direct to you by e-mail.
Gale Paeper gpaeper@empirenet.com
Glenn Howes wrote:
Hello, After months of being distracted by another portion of my application, I'm back to creating a universal binary version of the Pascal based library we are linking into our C++ based application. The problem is the application will not launch under PPC on Mac OS X 10.3 (Panther). The console registers an undefined symbol: _statvfs expected to be defined in /usr/lib/libSystem.B.dylib
A late reply to this email ....
I think, the problems you mentioned have been solved in the latest downloads for Mac OS X. I am not sure for Mac OS X 10.3, as I no longer have it installed.
Regards,
Adriaan van Os
-
Adriaan van Os -
Frank Heckenbach -
Gale Paeper -
Glenn Howes