Dear Norman,
I am not very brainy but I do have the same
configuration as you, software wise, "uname -a" gives
me the same answer: welcome to 10.3.7.
I went into some linking problem too, although I
didn't have the bravery to compile g77 on my own, but
all my problems disapeared after the november 2004 gcc
update provided by ADC.
Try "gcc -v", mine answers:
Reading specs from
/usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build
1671)
Whereas the previous version coming along with XCode
1.5 was build 1666...
Hope this will help, I am so stupid.
Best regards
Nicolas
--- email@hidden wrote:
> Send Fortran-dev mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
> http://lists.apple.com/mailman/listinfo/fortran-dev
> or, via email, send a message with subject or body
> 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Fortran-dev digest..."
>
>
> Today's Topics:
>
> 1. Coalesced and regular symbols (Norman Gray)
>
>
>
----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 24 Jan 2005 23:12:27 +0000
> From: Norman Gray <email@hidden>
> Subject: Coalesced and regular symbols
> To: email@hidden
> Message-ID:
>
<email@hidden>
> Content-Type: text/plain; charset=US-ASCII;
> delsp=yes; format=flowed
>
>
> Greetings,
>
> 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 truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
_______________________________________________
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
This email sent to email@hidden
