[CLN-list] Linking on Mac OS X

[Richard B. Kreckel]

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/>