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: <006201c016b5$cce7aa40$f7c723cb@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin AT sources DOT redhat DOT com>
References: <17B78BDF120BD411B70100500422FC6309E0C3 AT IIS000> <001b01c0166d$d8f49d90$f7c723cb AT lifelesswks> <39B3B044 DOT 765E2666 AT ece DOT gatech DOT edu>
Subject: Re: DLL naming conventions
Date: Tue, 5 Sep 2000 08:19:22 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
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.

that answers that question :]

> 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.

What about this then?
I start up bash, and then a cygwin X-server. it loads libXpm.dll into
memory.
from there I run, say Gimp for X11 on win32 (sorry Tor, it's just a good
example). it's been built with mingw32, and need libXpm.
it gets the cygwin libxpm. regardless of path, no questions asked. oops
crash oh well mail the support lists...

> > -> 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.

yes.. But we we going round the how much changes are needed questions with a
basic assumption - that we couldn't have libraries mixed, and we wanted
mixed executables on a given machine. I just wanted to understand clearly,
how much flexability we were trying to achieve.. which I've got now

Libraries: None. Not going to happen. End of story. Each 'environment' needs
to be partitioned - msvc, mingw32, cygwin, pw et al. they cannot use
libraries from each other

pipes: whatever the two exes support.

binaries from one environment to another... unknown at this point (ie in
cygwin X-term running a mingw32 ksh? (Ok I wouldn't do that but someone may
try).

> >
> > 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.

I think the in-memory issue is the critical problem... if we can't get two
different abc.dll files in memory then we much name all .dll's differently.

> 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.

Ah well.. worth asking. (Btw thanks Corinna and Bernard for your answers
too!)


(Shame they are both no!)

Rob


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