Linking problems. Ooooh, I'm having linking problems, and have hit a
brick wall. This is a long one, I'm afraid -- it's quite a substantial
wall I've run into.
I'm getting lots of errors like:
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
This cropped up when linking C++ (compiled with Apple gcc) with
Fortran, compiled with either Fink and DarwinPorts g77 (g77 versions
3.4.1 and 3.3.3 respectively), though I've also seen it when linking
with just C. The _udivdi3 module is representative -- there are about
a dozen other similar modules.
Now, I understand a certain amount of what's going on here, but not
all, and I'd be grateful for any advice, or correction.
The various libgcc.a libraries include the udivdi3 module, which
includes some data, though exactly what I'm not sure, in a __eh_frame
section of the __TEXT segment [1]. The problem is that the libgcc.a
libraries which are associated with the two g77 installations mark this
section as of type S_REGULAR, while the system libgcc.a defines this
same section as of type S_COALESCED [2].
[Note for the rest of us: `regular' symbols are the normal type of
defined external symbol; `coalesced' symbols can be identically defined
in multiple object files, and only one copy is copied to the final
output file. See [3] for details.]
So I can broadly understand the problem: the linker doesn't like
copying data into the output from sections of different types. I even
think I understand why ld's symbol resolution algorithm results in both
the system and the g77 libgcc.a libraries being examined by the linker,
though I doubt I'd be able to give a very convincing account of it if
challenged... (libSystem.dylib refers to ___udivdi3 through private
defined/external symbols, which imply the system libgcc independently
of the ld library search path?).
What I'm puzzled about is: why now, and what can I portably do about
it? We have had this working on 10.3 before, but at some point, most
likely a 10.3 minor upgrade, or (my money's on this) the phase of the
moon, some incompatibility has risen to bite us, and it's stopped
working (my machine at least hasn't changed its DarwinPorts g77
version; my colleagues' machines may just possibly have changed their
Fink version). Now different machines with different releases of 10.3
are failing on different link targets.
One solution, of course, would be to find the precise configuration
which let things work and freeze that. But that's not an option for
us, because this is part of a large astronomical software set which we
want to build on as many posixish platforms as possible, courtesy of
mucho automake, autoconf and (GNU) libtool (I know that GNU libtool for
OSX has been evolving fairly rapidly; we have 1.5.6 at present).
Though we're working on 10.3.* at present, we'd quite like things to
work on 10.2, and we'll need things to work on 10.4 when that appears.
Using libtool makes it possible but slightly complicated to use custom
linker options.
The problem is that it's not clear to me that there _are_ any magic
linker options that will resolve what appears to be a fundamental
incompatibility between the system and g77 libgcc.a versions (the
corollary of which is that this never worked reliably, and we've just
been somehow lucky so far).
Another possibility would be to use an alternative compiler, which we
could be confident was compatible with the g77 to hand. For example,
I've seen a few suggestions (eg [4]) of hpc.sourceforge.net. However,
(a) this is starting to lay more hassle on the (sophisticated but
impatient) users we'd expect to see building this stuff (and besides,
it'd be me having to write the instructions...), and (b) I can see a
dark future of pain if I head too far down that route.
On the darwin-development list (see [5] and followups) there was some
discussion of the same problem appearing when building one's own
libgcc.a. Martin Costabel suggested that there was an important
difference between gcc 3.1 and 3.3, but the same coalesced symbols are
present in both 3.1 and 3.3 libgcc.a, as far as I can see. Scott
French's response to that referred to a libgcc.a bug which was fixed
after Apple's gcc 3.3 release, but I can't find any mention of this in
the opendarwin bugzilla, and the ADC bugreporter isn't publicly
searchable.
Adding -lcc_dynamic makes a difference, removing the coalesced vs.
regular warnings, presumably (?) because although
/usr/lib/libcc_dynamic.a links to the same library as
/usr/lib/libgcc.a, ld thinks this is a separate library and searches it
at two separate points on the library search list (says he, not really
believing it himself, and in any case not really seeing why that would
solve the problem). But is that success just another coincidence? I'm
bearing in mind here Martin Costabel's response to me in another
message on this list [6], suggesting that -lcc_dynamic can produce
inconsistencies if there is a libgcc.dylib elsewhere on the system (I
don't have one).
(Thanks for getting this far down!)
So, my big question is this (finally!, you say): are there any quick
fixes here, or failing that, some further source of information I can
read, which goes beyond the Mach-O architecture manual in [3]?
Thanks for _any_ pointers anyone can provide.
For reference, the g++ linking step which libtool generates is:
% g++ <various -D and -I options> \
-O \
-g \
-O2 \
tkAppInit.o \
gaia_swish.o \
-o bin/gaia_swish \
<lots of -L and -l options specific to this app, including refs to
g77 lib dirs> \
-lfrtbegin -lg2c -lSystem
% which cc
/usr/bin/cc
% cc --version
cc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
% uname -a
Darwin Basil.home 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7
16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power
Macintosh powerpc
--
----------------------------------------------------------------------
Norman Gray : Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fortran-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/fortran-dev/email@hidden
