This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] Build libgcc_s on Windows
Charles Wilson wrote on 27 August 2008 05:34:
> Dave Korn wrote:
>> Charles Wilson wrote on 19 August 2008 17:34:
>>
>>> Charles Wilson wrote (reordered):
>>>
>>>> Here, SHLIB_IMPLIB *could* be named @shlib_base_name@.dll.a to make
>>>> clear that it is an import library
>>> On second thought, I think this part is a bad idea. Stick with .a, not
>>> .dll.a.
>>
>> I'd like to understand a good reason for this. The use of .dll.a is a
>> system standard and implied by the search ordering in ld.
>
> With libgcc, the shared library and the static library have different
> names, so there is no "search order" confusion.
I managed to make it happen when I built a shared libgcc that excluded the
EH machinery and relied on pulling it in from the import lib. I accept that's
not a conventional setup but we have at least the case of ctors.o which is
excluded from the shared lib and supplied by the static lib.
There's still no motivation (that I'm aware of) for this. I don't see why
libgcc should be the one and only DLL on the planet that does things
differently from the rest. We should stick to standards to avoid confusion;
the import lib for cyg%.dll should be called lib%.dll.a, same as usual, unless
there is some clear and plain benefit from breaking with the convention, and
nobody's explained what that clear benefit is to me yet.
> -lgcc_s will find only libgcc_s.a; it will not be confused by libgcc.a
> Ditto -lgcc
They are in fact /both/ present on the commandline, so that static libgcc
can fill in anything not supplied by the DLL. Check the definition of
LIBGCC_SPEC in Aaron's patch.
> Second, I'm hoping we can get this stuff in under the wire before stage1
> closes...and I didn't want to delay things by sending Aaron on a
> wild-goose-expedition, chasing after an unnecessary modification with
> unknown ramifications. (Yeah, probably won't break anything -- but I
> didn't want Aaron to risk further delay.)
I could always propose a patch later, but it's a potential back-compat
breaker to make a change like that.
cheers,
DaveK
--
Can't think of a witty .sigline today....