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: <39B3B044.765E2666@ece.gatech.edu>
Date: Mon, 04 Sep 2000 10:23:00 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: cygwin AT sources DOT redhat DOT com
Subject: Re: DLL naming conventions
References: <17B78BDF120BD411B70100500422FC6309E0C3 AT IIS000> <001b01c0166d$d8f49d90$f7c723cb AT lifelesswks>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Collins wrote:
> 
> but this also means that mingw32 program won't use the cygwin compiled
> libpng if it is there? is that acceptable?

mingw programs can't use cygwin libraries. Period. This is due to
library dependencies.

cygwin-libpng.dll depends on cygwin1.dll, which implements many of the
runtime functions, such as printf(), startup code, etc.  

A mingw program (or mingw-libpng.dll, for that matter), depends on
crt.dll (or msvcrt.dll, depending on which flavor of mingw you're
using).  crt.dll (or msvcrt.dll) implement printf(), startup code, etc.

If you were to link a mingw-compiled .o with a cygwin-libpng.dll, using
the mingw linker -- which printf() would get used? Which startup code? 
Well, actually the link would fail -- due to 'duplicate symbol'
problems.

And all this happens *without* mysterious mingw-libpng.dll /
cygwin-libpng.dll DLL hell.

> -> if we are looking to keep the sandbox's separate then yes.. but why care
> about running a (say) mingw32 program from cygwin bash...

Okay, now this is a valid issue.  But, you are much too unspecific.  You
can still call a generic mingw32 program from cygwin bash.  The
assumption is, that while in bash, the PATH is set so that cygwin's
/usr/bin,/bin is in the front.  But that doesn't mean that some mingw
directory cannot be toward the back of the path.  Finally, recall that
dll's will get loaded preferentially from the same directory that the
executable is in.

So, the *only* way you get in trouble is if ALL of the following are
true:  You run bash.  cygwin's /usr/bin,/bin is in the front of the
PATH.  You call 'mingw-program1', which depends on the mingw version of
my-dll.dll.  mingw-program1 is in, say, c:\mingw\usr\local\bin. 
my-dll.dll is in c:\mingw\usr\bin -- e.g. a different directory that
mingw-program1.  There is a cygwin-compiled version of my-dll.dll, in
cygwin's /usr/bin. 

Pretty damn unlikely, IMO. 

> -> if we are looking to let things cross the sandbox we should decide _what_
> things, (ie bin/pipes, bin/pipes/libs, binaries only..) we are able to
> support and then make it as flexable as possible.

libraries cannot. pipes probably can (given the textmode/binmode
issues...). Of course you can call programs from native- or
other-unix-on-win platforms; as long as there is no confusion about
dll's.

All we're discussing is how to avoid dll hell between these platforms.

> 
> I think we need to make that decide first, and then the rest falls into
> place....
> 
> if we want full cross over from the sandboxes then the answer should permit
> only porting layer/method to use another libraries. So a port layer/method
> specific library naming convention is not acceptable. 

Can't use other-compiled versions of libraries anyway (okay, *maybe* you
can mix mingw and msvc, but that's not at issue here. We're talking
about cygwin.)

> likewise if we want
> sandboxes then porting layer/method specific library file names becomes
> mandatory.

Not necessarily, if the PATH settings (or insuring that all dll's and
exe's go into the same directory) are sufficient to prevent problems.  I
don't think so, personally.  As distasteful and painful as renaming all
the dll's is, it *may*, repeat *may*, be the best option.  I believe
Chris is proactively doing some research; it is possible that we can do
something else, and avoid the 'cyg' prefix -- like using the 'AppPath'
registry or something.

It's just that there is an ingrained desire to stay as unix-like as
possible -- and that means, libraries start with 'lib', not 'cyg'.  If
AppPath can fix the problem, then I'd prefer that cygwin's install.exe
set the appropriate registry entry whenever installing an executable. 
This won't catch *everything*, but dagnabbit, I'm tired of packages
installing themselves with cp (which break on cygwin thanks to the .exe
suffix).  They oughta use install.

> 
> Personally I think that a mingw32 libpng should be useable by cygwin gcc AND
> cygwin distributed binaries, given that they are the same version... (and
> that should be part of the naming convention).

Just cannot be done. Sorry.

--Chuck

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