Richard B. Kreckel writes:<br>> Note that you'll find some linker problems at a later stage.<br>> Somebody knowledgeable about the way that linker works needs to fix this.<br><br>In my Great Quest to get GiNaC running on Mac OS X, I've done some digging on this problem.<br>The issue lies with the machine-dependent hacks in include/cln/modules.h for forcing<br>construction time ordering.<br><br>The following quote from <br>http://mail.gnu.org/archive/html/users-prolog/2004-01/msg00028.html<br>sums up the issue at hand:<br><br> The problem comes down to the fact that Mach-o has lazy linking and<br> does not allow any changes in the .text section where our compiled<br> code resides. Therefore the message below, which states "<br> non-writable section". This means that all external symbols need a<br> stub construct in the .data section. The code in .text jumps to<br> .data section, which
in the
meantime has magically been changed to<br> point to the actual implementation of the target routine in linked<br> shared libraries.<br><br>I still need to fullly understand the approach implemented by CL_PROVIDE and related macros in<br>modules.h, then determine/implement/test the solution for Darwin-based platforms.<br><br>FWIW, I've had to manage this problem in C++ embedded systems before, e.g. via a linker <br>directive files. I'm unclear as to what motivated the design choices in CLN, such that it even <br>encounters the constructor ordering problem in the first place? <br><br>Thanks,<br>John Whitley<br>