This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] fix PR ada/42554 by dropping -c from ranlib on darwin10 and later
On Feb 4, 2010, at 3:11 PM, Jack Howarth wrote:
> I'm not doing ada builds myself. What happens on darwin10
> if you drop '-c' from the calls to ranlib throughout the
> ada build?
I think you can get linking failures in some cases: some symbols, which are defined only as common in
an archive member won't be found.
> Is '-fno-common' still required in that case for
> If so, we should definitely keep pushing Apple to
> fix radar 6320843.
It is possible to read the content of this radar issue ?
I am not sure that this is a bug. The Darwin semantic of archive is somewhat odd but coherent.
> On Thu, Feb 04, 2010 at 11:17:36AM +0100, Tristan Gingold wrote:
>> On Feb 4, 2010, at 5:20 AM, Jack Howarth wrote:
>>> The use of -c for common symbols with ranlib is considered
>>> a legacy option in Darwin10. The Xcode 3.2 linker doesn't
>>> properly ignore duplicate symbols from static libraries when
>>> they are prepared with 'ranlib -c' (radar 6320843). Apple's
>>> response to this was...
>>>> Darwin static archives traditionally do not have common symbols in there table of contents.
>>>> The -c option forces common symbols into the table of contents and causes this problem.
>>> The use of 'ranlib -c' was introduced with...
>>> The original purpose of that patch (to eliminate failures in g77) no
>>> longer exists on darwin10 as FSF gcc built without 'ranlib -c'
>>> shows no regressions on x86_64-apple-darwin10.
>>> The attached patch limits the use of the -c option with
>>> ranlib to darwin9 and earlier. This change will eliminate the
>>> linkage failures in ada on darwin10 (PR42554)...
>>> Okay for gcc trunk?
>> The PR comment contains everything.
>> Note that 'ranlib -c' is used elsewhere. For example in mlib-tgt-specific-darwin.adb
>> You will also hit this issue if you are using 'gnatmake -f -a' for example.
>> As the semantic of archives on Darwin are different from the standard UNIX one with regards to common
>> symbols, at AdaCore we avoided the whole issue by forcing -fno-common.