On Monday 21 January 2008 01:09:29 Allison Randal wrote: > In the past few weeks we've had an increasing number of "Undefined > symbols" errors on OS X (Tiger). Previously it was only a handful of > failing tests, but now it's preventing 'make' from completing, > terminating with the following error: > > ------ > c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib > -L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib > -L/Users/allison/projects/svn/parrot/blib/lib -lparrot > -L/Users/allison/projects/svn/parrot/blib/lib -lm -lgmp -lreadline > /Users/allison/projects/svn/parrot/src/parrot_config.o > /usr/bin/ld: Undefined symbols: > _Parrot_set_executable_name > collect2: ld returned 1 exit status > linking failed > current instr.: 'link_file' pc 752 (pbc_to_exe.pir:365) > called from Sub 'main' pc 124 (pbc_to_exe.pir:32) > make: *** [pbc_to_exe] Error 1 > ------ > > Looks like this particular failure was caused by r25020, but it's only a > symptom of the wider problem.
Does this happen after a 'make realclean' and recompilation? You in particular know that I have a special dislike for the state of building and linking C code on Mac OS X, being dangerously close to The Best That Unix Had To Offer Circa NeXT 1987... ... but apart from slapping PARROT_API on the symbol, what in the world do we need to do special to tell GCC 4.x on Mac OS X to: 1) hide symbols not explicitly exported 2) actually export symbols when we mark them as exportable I mean, the main reason we hide symbols by default is so that we'll catch what would be compilation errors on Win32 on platforms with GCC 4.x, but if Mac OS X can't handle a bog-standard compilation option, well maybe we should work on getting them the source code to GCC or something. -- c
