On Tue, 17 Aug 2004, Darren Bane wrote:
I'm trying to build CLN 1.1.8 on a G4/Mac OS X 10.3.5 system with the XCode 1.5 tools (i.e. Apple's version of GCC 3.3 and the Mach linker). By disabling shared libraries, I've got quite far with this, up to linking the CLN test case, exam. This gives unresolved externals ending with _ctorend and _dtorend.
I've tracked it down to the fact that each object in the library has a _XXX_[cd]torend symbol defined module-local (i.e. nm entry prefixed by "s"). However, each module has an unresolved XXX_[cd]torend symbol (nm entry prefixed by "U"), without the underscore prefix.
This is a recurring and still unsolved issue. Back in February, John Whitley got stuck at the same point. For the record I quote his last mail on the topic: : Richard B. Kreckel writes: : > Note that you'll find some linker problems at a later stage. : > Somebody knowledgeable about the way that linker works needs to fix this. : : In my Great Quest to get GiNaC running on Mac OS X, I've done some digging on this problem. : The issue lies with the machine-dependent hacks in include/cln/modules.h for forcing : construction time ordering. : The following quote from : http://mail.gnu.org/archive/html/users-prolog/2004-01/msg00028.html : sums up the issue at hand: : : The problem comes down to the fact that Mach-o has lazy linking and : does not allow any changes in the .text section where our compiled : code resides. Therefore the message below, which states " : non-writable section". This means that all external symbols need a : stub construct in the .data section. The code in .text jumps to : .data section, which in the meantime has magically been changed to : point to the actual implementation of the target routine in linked : shared libraries. : : I still need to fullly understand the approach implemented by CL_PROVIDE and related macros in : modules.h, then determine/implement/test the solution for Darwin-based platforms. : : FWIW, I've had to manage this problem in C++ embedded systems before, e.g. via a linker : directive files. I'm unclear as to what motivated the design choices in CLN, such that it even : encounters the constructor ordering problem in the first place?
This is the CL_PROVIDE and CL_REQUIRE macros. My include/cln/config.h has ASM_UNDERSCORE defined. I tried to read the macro definition, but got lost. Can anyone help?
Have you tried fully expanding them, either manually or with the help of the preprocessor (c++ -E)?
I searched the archives for relevant information a few days ago and didn't find any. They seem to have disappeared in the meantime???
No, this list is new. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>