public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Paul Sokolovsky <paul-ml@is.lg.ua>
To: Chris Faylor <cygwin@sources.redhat.com>
Subject: Re[2]: DLL naming conventions
Date: Thu, 31 Aug 2000 04:21:00 -0000	[thread overview]
Message-ID: <7593.000831@is.lg.ua> (raw)
In-Reply-To: <20000830102210.A25880@cygnus.com>

Hello Chris,

Chris Faylor <cgf@cygnus.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@sourceware.cygnus.com

  reply	other threads:[~2000-08-31  4:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-30  3:36 Paul Sokolovsky
2000-08-30  7:26 ` Chris Faylor
2000-08-31  4:21   ` Paul Sokolovsky [this message]
2000-08-31  8:56     ` Chris Faylor
2000-09-01  9:10       ` Re[2]: " Paul Sokolovsky
2000-08-31 18:05     ` Gary V. Vaughan
2000-08-30  7:48 ` Charles Wilson
2000-08-30  7:52   ` Chris Faylor
2000-08-30  8:07     ` Norman Vine
2000-08-30  8:17       ` Charles Wilson
2000-08-30  8:19         ` Charles Wilson
2000-08-30 11:37         ` Chris Faylor
2000-08-31  5:14           ` Re[2]: " Paul Sokolovsky
2000-08-30  8:11     ` Charles Wilson
2000-08-31  5:07   ` Re[2]: " Paul Sokolovsky
2000-08-31  8:58     ` Charles S. Wilson
2000-08-31 11:28     ` Re[2]: " Tor Lillqvist
2000-08-31 11:47       ` Chris Faylor
2000-08-31 12:07         ` Larry Hall (RFK Partners, Inc)
     [not found]   ` <20000831230822.R7695@demon.co.uk>
2000-08-31 18:58     ` Charles S. Wilson
2000-09-02  6:56       ` Gary V. Vaughan
2000-08-31 20:27 ` Charles S. Wilson
2000-08-31  6:52 Re[2]: " Earnie Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7593.000831@is.lg.ua \
    --to=paul-ml@is.lg.ua \
    --cc=cygwin@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).