Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Thu, 31 Aug 2000 14:14:56 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Mailer: The Bat! (v1.32) S/N AB51B607
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
X-Priority: 3 (Normal)
Message-ID: <7593.000831@is.lg.ua>
To: Chris Faylor <cygwin AT sources DOT redhat DOT com>
Subject: Re[2]: DLL naming conventions
In-reply-To: <20000830102210.A25880@cygnus.com>
References: <20000830102210 DOT A25880 AT cygnus DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Chris,

Chris Faylor <cgf AT cygnus DOT com> wrote:

>>Will it be possible to re-consider this matter and if it applies,
>>recommend to follow it?  More importantly, it can be automatically
>>supported on appropriate level (in libtool).

CF> Nope.  Sorry.

CF> If "end users" are using "incompatible" libraries then they'll really
CF> have to deal with this themselves.  It's too late to change now.

CF> Of course, on reflection, the cygwin project doesn't really have to
CF> change at all.

    Yes! Who here proposes to change something? Blame him, beat him,
cut him! But we, as cicvilized people, let's talk about conventions,
*not* about changing anything, ok?

CF> All of these other "GNU targets" which came along after
CF> cygwin was well established, and benefitted from years of cygwin
CF> development, should probably be making naming concessions if it is a
CF> problem.

    Exactly! I knew you'll recommend that, so I'm going to submit
patch to libtool which will use different naming convention for
GNU/Win32 target I maintain. But not everyone so reflective as me, and
there're at least two other targets cygwin and mingw32. Ok, we'll
leave rock-solid cygwin aside. But what about poor mingw32? Chris, I
understand your position: that's not cygwin problem. But what if you,
maintainer of Cygwin, mother of all GNU-Win32 targets, considered that
it is problem of - not Cygwin - whole GNU-Win32? Then, you might
consider doing something. If you'd consider it, you might come with
following thought: "Hey, but we already using 'cyg' prefix for some libs.
At the same time, GNU has convention of prefixing libraries with
'lib'. Let's recommend for cygwin use prefix 'cyg' instead (for *dlls
only*) - it is consistent with existing practise. As for mingw32,
we'll leave it 'lib' - after all, it's the most native GNU-Win32
target, let it use defualt conventions. All other, being
superstructures on win32, to use distinguishable naming scheme".


================= Specific proposal ================
I'm going to submit patch to libtool which (supposing it will be
accepted) will make it use other naming scheme for PW32,
posix-on-win32 layer I maintain. If it is in favor of Cygwin,
community, I may do the same for cygwin too.

Proposed naming conventions [only pertinent one shown]

 For some library 'foo', libtool will procude on

Cygwin:
libfoo.la - standard libtool wrapper
libfoo.a  - import library, thing against which objects are linked
            ("developer" part)
cygfoo.<release>.dll - dll, this is what gets loaded in runtime
                       ("user" part)

Note that <release> is standard part of name of shared libraries
produced by libtool. While it sequency of three arbitrary numbers,
there's strictly recommended policy to using them - in two words, they
should reflect interface version, never version of library itself. And
yes, there's a way to disable putting it in name. Most packages don't do
that, however.

For mingw32, those will be:
libfoo.la
libfoo.a
libfoo.<release>.dll


Note - no efforts or changes will be required from programmer's or
maintainer's side to support different names of run-time DLLs, their
different version or whatever - it will be completely hidden in implib
the wondeful thing.

====================================


CF> Expecting cygwin to change its conventions is just a tad
CF> bit arrogant, don't you think?

    Chris, you often ask strange questions. If, I say - if, someone
would propose to change its conventions, I'd first listen one's
reasoning before making my opinion whether it is arrogant or not. But
what relation this has to our present conversation?

CF> cgf



--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com