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
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Wed, 30 Aug 2000 10:22:10 -0400
To: cygwin AT sources DOT redhat DOT com
Cc: paul-ml AT is DOT lg DOT ua
Subject: Re: DLL naming conventions
Message-ID: <20000830102210.A25880@cygnus.com>
Reply-To: cygwin AT sources DOT redhat DOT com
Mail-Followup-To: cygwin AT sources DOT redhat DOT com, paul-ml AT is DOT lg DOT ua
References: <19558 DOT 000830 AT is DOT lg DOT ua>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <19558.000830@is.lg.ua>; from paul-ml@is.lg.ua on Wed, Aug 30, 2000 at 01:24:11PM +0300

On Wed, Aug 30, 2000 at 01:24:11PM +0300, Paul Sokolovsky wrote:
>Existance of several GNU targets based on incompatible underlying
>libraries brings (or will bring soon) problem of clashes between their
>components.  Mere installing software build with each of them into
>separate directory and setting PATH to one of the in per-session manner
>is not flexible since often one piece of software absent in that or
>another distribution.  Of particular importance here is clashing of
>DLLs which is espicially hard to detect for end users.  It would be
>nice if there were some convention for naming DLLs build for particular
>target.  Cygwin did that for a some time, for example, native builds of
>Tcl/Tk, etc.  used to have 'cyg' prefix.  However, latest additions
>seem not to follow this practise.
>
>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).

Nope.  Sorry.

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

Of course, on reflection, the cygwin project doesn't really have to
change at all.  All of these other "GNU targets" which came along after
cygwin was well established, and benefitted from years of cygwin
development, should probably be making naming concessions if it is a
problem.  Expecting cygwin to change its conventions is just a tad
bit arrogant, don't you think?

cgf

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