compiling static library + gpc runtime

Gale Paeper gpaeper at
Wed Oct 4 15:52:02 CEST 2006

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 at

More information about the Gpc mailing list