Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Link problems: restFP/saveFP and -lcc_dynamic -- why?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Link problems: restFP/saveFP and -lcc_dynamic -- why?

Greetings,

Can anyone explain to me what the story is with the restFP/saveFP
symbols, which cause such inexplicable link problems with (some? all?)
combinations of g77 and gcc code? [I posted this query on
email@hidden a few days ago, but nobody wanted to bite].

For those as yet innocent of this, the problem is that in certain
circumstances, links fail because the restFP and saveFP symbols are
undefined. Do a little bit of Googling, and you'll soon come across
the advice to add -lcc_dynamic (or sometimes -lgcc, or even sometimes
libgcc.a) to the link options.

Now, that does seem to work most of the time (though see below), but
it's a bit voodoo. Can anyone explain just what really is going on here?
I'd love to know, because (a) I don't like voodoo, and (b) I'm trying to
do the configuration work to get a large software set building reliably
and portably, and if I randomly hack the problem away here, it'll surely
just break sometime later. Since I don't understand what's happening,
I can't even design a reliable test to detect the problem at configure
time, to work around it.

Here's what I understand (or have guessed) so far:

(1) It appears to happen when you use a Fortran compiler (well,
OpenDarwin or Fink g77 at least) to link in C code. That code is
typically moderately numerical, but calling a floating point function
is not enough to include a reference to the symbol in a .o file. That
fits in well with the statement ``When the compiler needs to save and
restore lots of float registers around function calls, it generates
calls to saveFP and restFP'' [Stan Shebs in
<http://www.omnigroup.com/mailman/archive/macosx-dev/2002-March/
024086.html>]. But calling a FP function with tens of arguments
doesn't produce a symbol reference either.

(2) When doing such a link (Fortran linker linking mixed Fortran/C code),
I shouldn't need to provide an explicit reference to the C runtime,
because (I think) g77 is Clever about this. This is the situation which
produces the restFP/saveFP link errors.

(3) Going the other way (C linker linking mixed code), I definitely need
to provide a reference to the Fortran runtime. From examining the g77
-v output (which is what Autoconf does) I can see that the specific OSX
magic is ``-lfrtbegin -lg2c -lSystem'': adding that does work (always?),
but isn't always convenient.

(4) With the Fortran link, the problem remains if I add -lgcc, but
disappears, and the link works, if I add -L/usr/lib -lgcc, which tells
us that the problem is somewhere in the gcc which my (OpenDarwin) g77
is picking up (in this case
/opt/local/lib/gcc-lib/powerpc-apple-darwin7.3.1/3.3.3/libgcc.a).

(5) With some of our code, the problem goes away if we add -lcc_dynamic
to the (g77) link. But not always: in the case I've got in front of me
now, that produces:

/usr/bin/ld:
/Volumes/Boltzmann/opt/local/bin/../lib/gcc-lib/powerpc-apple-
darwin7.3.1/3.3.3/libgcc.a(_udivdi3.o) section's (__TEXT,__eh_frame)
type S_REGULAR does not match previous objects type S_COALESCED

...which I'm not enough of a linker expert to be able to understand
in more than broad outline.

(6) Is it simply that the g77 link isn't being Clever (cf 2) enough, and I
need to force it to link against the C runtime in the _system_ libgcc?
If so, then this is the robust solution, and the fix with -lcc_dynamic
has the same effect only by accident, since I see that (the unique)
/usr/lib/libcc_dynamic.a is in fact a link to the system libgcc.a.
But then, is this something specific to Apple's gcc mods, or to this
release's library environment, which might therefore potentially change
in the next version?




So: presumably this is some version-skew problem. But is it
OpenDarwin's fault, autoconf's fault, libtool's fault, my fault?
Will it go away in 10.4, or 3.4? Is it the mismatch between the
gcc-lib/powerpc-apple-darwin7.3.1 and (uname) Darwin 7.4.0 (that fits
in with the behaviour in (4) above, I think)? I'm scrabbling around in
the dark, here. Google has drawn a blank (though I did find a reference
to a page that I wrote, complaining that there was little information
about this findable on the web, which was a little dispiriting), and
the ld manpage doesn't illuminate.

This is Darwin 7.4.0 and (as you can see) currently gcc 3.3, though it
also happens with 3.1.

Now my head's spinning.... Can anyone provide any pointers, or any
reading, or even a spark of illumination?

All the best, and many thanks in advance,

Norman


--
----------------------------------------------------------------------
Norman Gray : Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
_______________________________________________
fortran-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/fortran-dev
Do not post admin requests to the list. They will be ignored.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.