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? Thanks, John Whitley
On Sun, 22 Feb 2004, John Whitley wrote:
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.
Luck! Just expanding things makes it rather clear, doesn't it?
FWIW, I've had to manage this problem in C++ embedded systems before, e.g. via a linker directive files.
What's a "linker directive file"? Do you mean you just force the linker command line, such that the objects up in the graph come before the ones below it? That would be feasible on GNU/Linux as well because the order of initialization is determined by the order on the linker commandline, AFAIK. If that is it, how does such a file look like?
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?
Err... guarding objects from accidentally being used before they are even initialzed... without resorting to clumsy construct-on-first-use functions... What was your question again? By the way: what happens with -DNO_PROVIDE_REQUIRE? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/email.html>
participants (2)
-
John Whitley
-
Richard B. Kreckel