Subject: Re: importlibraries names
From: "Gerrit P. Haase" <[email-masked]>
To: Corinna Vinschen <[email-masked]>
Date: Tue, 26 Aug 2003 23:51:39 +0200

Hallo Corinna,

On 2003-08-26 17:24 Corinna wrote:
> [This isn't xfree-related.  Redirected to [email-masked]]

> On Tue, Aug 26, 2003 at 04:15:50PM +0200, Gerrit P. Haase wrote:
>>>> Would it be a problem to create the symlinks to be libxyz.a instead of
>>>> libxyz.dll.a in future releases or use the same names of the
>>>> importlibraries as it was before, without version included?

>>> No.  There are two types of import libs:

>>> libfoo.dll.a which results in linking against the apropriate DLL and
>>> libfoo.a which is the static lib.  This scheme has been settled already
>>> loooong ago and is obeyed by binutils.  If the configuration script
>>> gets this wrong, the configuration script should be fixed.

>> Hmmm, since there are no .dll.a import libraries on linux, pretty much
>> configure scripts are failing at this point.  It works well as long as
>> static and import libraries are provided as it is the case with the most
>> packages, but if there are no static libraries, what is lost if there
>> are no .dll.a files?

> Reliability?  You never know from the name if it's a shared or a static
> import lib.

What for, everyone knows that all Xfree libraries are shared libs and
if you don't know it, what happens if you link against them?  The link
succeeds, if it is shared or not.  I still cannot see the benefit why
an importlibrary *must* be suffixed with .dll.a as long as there is no
static archive with this name.

> The configuration script is just faulty.  A configuration script should
> test if linking against -lfoo works, not if there's a library called
> libfoo.a.  It's not exactly right to assume that all platforms are using
> this naming scheme.  A platform might as well use foo.lib or something
> entirely different.  Or, even simpler, as on Linux where libfoo.so is ok,
> too.  Does the script test for .so files?  If so, why not testing for
> .dll.a files as well?

Sure, I can fix all my configure scripts.  I like these small
configure tests, they are much faster than trying to link against
libfoo works.

So long,
Gerrit
-- 
=^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/