Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <17B78BDF120BD411B70100500422FC6309E0C3@IIS000>
From: Bernard Dautrevaux <Dautrevaux AT microprocess DOT com>
To: "'Charles Wilson'" <cwilson AT ece DOT gatech DOT edu>, cygwin AT sources DOT redhat DOT com
Cc: gvv AT techie DOT com
Subject: RE: DLL naming conventions
Date: Mon, 4 Sep 2000 14:20:42 +0200 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

> -----Original Message-----
> From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> Sent: Sunday, September 03, 2000 8:00 AM
> To: cygwin AT sources DOT redhat DOT com
> Cc: gvv AT techie DOT com
> Subject: Re: DLL naming conventions
> 
> 
	<skipped>

> 
> Won't fix the problem for exe's that aren't part of the official
> install, but you can work around that by requiring that 
> /bin,/usr/bin be
> in the front of the path (prior to 'outside' dirs). Even this, though,
> will not fix the problem for 'modeless' users (Michael's 'user 2') --
> because modeless users don't want /usr/bin in the front.
> 
> However, no modeless users (except for Paul) have complained.  Perhaps
> Paul should become modal. :-)

The problem iw that when you say "modal" you are really saying that we
should have several sandboxes and that a programm from sandbox "cygwin"
could not play with (i.e. call) a program with sandbox "pw32" or "mingw32";
that was exactly what render the Win32 Posix subsystem so inattractive: it
can't mix with win32.

Here the situation would only be slightly better: it may work by chance and
suddenly fall apart in the wrong place (i.e. I added something to mingw32
sandbox, and then a program from the cygwin sandbox no more works, assuming
I need to call some mingw32 program from cygwin bash...)

I *know* that having cygpng.dll instead of libpng.dll is a bit of a burden
for cygwin maintainers, but defining the convention and using it to all new
ports should prevent the problem to suddenly arise when there will be more
conflict than the apparently isolated zlib problem.

The fact that only one complain was received does not mean that there is no
problem and that we should not try to avoid the problem to be come worse.
Then progressively one could start rename all libfoo.dll's as cyfoo.dll,
still providing libfoo.dll as an interim measure to let maintainers update
their ports (which should only require a recompile provided libfoo.dll.a now
reflects cyfoo.dll).

Otherwise I'm afraid that one day the list suddenly gets filled of complains
of people saying: "I've installed foo.x.y on cygwin-1.1.4 and gets a
segfault in libbar.dll when running foo" with answers like "Don't
understand; I also use foo.x.y on cygwin-1.1.4 and do not have any problem;
do you also install xchess?" and all the expected messages to finally
understand that the native mingw32 port of gnugo also installs a libbar.dll
that is incompatible with the one needed by foo.x.y and provided by cygwin
or some other package foo depends on.

> 
> > I love being as
> > close to UNIX as possible but if it is going to cause problems then
> > it makes sense not to do things that way.
> 
> Yep -- so libtool and dll versioning issues should be 
> addressed.  But it
> appears that the 'modal' PATH requirement is the least 
> intrusive method
> of fixing the platform-specific dll confusion (e.g. native vs. cygwin
> vs. UWin vs. PW dll's, all with the same name).
> 

I don't think so, as we must rely on the PATH and thus are NOT allowed to
have two different sandboxes in one PATH (not even perhaps the standard
WIN32 directories) as we may have conflicts. Right conflicts with WIN32
native DLLs is quite improbable but that's just because this fancy "lib"
prefix for cygwin dlls :-)

I think what was proposed here was just refining a bit this convention,
saying that "lib" should be avoided (by *everybody* IMNSHO) but replaced by
a short prefix that should try to be as unambiguous as possible (and if
possible 3-char-long to avoid breaking some habits and poorly written sed
scripts) like for example "cyg" for cygwin, "mgw" for mingw32, "pow" for
Paul's Powix-On-Windows layer and so on.

This would not be perfect and clashes will still be possible but at least
they will be a lot less likely.

As for the versioning I favor without any doubt versioning the DLLs for
incompatible ABI/API changes while the (needed) import library is
non-versioned. But I think the scheme is almost agreed upon, at least for
the future when ABI or API-incompatible versions of not-yet-versioned DLLs
will appear.

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux AT microprocess DOT com
		b DOT dautrevaux AT usa DOT net
-------------------------------------------- 

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