This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: DLL naming conventions


> -----Original Message-----
> From: Charles S. Wilson [mailto:cwilson@ece.gatech.edu]
> Sent: Monday, September 04, 2000 4:23 PM
> To: Robert Collins
> Cc: cygwin@sources.redhat.com
> Subject: Re: DLL naming conventions
> 
> 
> 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.

Sure; it will also happen if linking a mingw-compiled foo.o with a
cygwin-compiled bar.o and this whatever the linker is (mingw or cygwin).

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

Not so unlikely, if using libraries from contributed packages, that get
installed if following the standards, under /usr/local/package-x.y.z. I may
get one compiled for cygwin in C:\cygwin\usr\local\package-x.y.z and the
mingw32 one in c:\mingw\usr\local\package-x.y.z.

Now HOW could I set up my path?

I agree I can stash ALL cygwin stuff in C:\cygwin\usr\bin and ALL mingw32
stuff in C:\mingw\bin, but that seems even more hacky as having cygfoo.dll
and mgwfoo.dll located where I expect them :-)

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

100% agreed

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

In fact, under some conditions (mainly: no reference to msvcrt.dll nor
crtlib.dll) we should be able to use any native win32 DLL with either mingw
or cygwin or any other posix-on-windoze layer. In fact it is even almost a
requirement or we get in some kind of a closed sandbox like was Microsoft
POSIX subsystem.

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

Problem is that is a nightmare to manage a "stash everything in one dir"
installation method.

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

100% agreed; the fact that I don't *know* a better approach does not mean
there isn't one!

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

AppPath may be a solution, but with the problem that this puts the burden on
the package installer and expect *all* other package to be as clever as
mingw ?-) and I'm not sure of how to say when installing a package that DLLs
should be loaded ONLY from subdirectories of C:\cygwin or from standard
places even if the path contains directories where we can find a "matching"
DLL.

This may be a bit complicated, error prone and difficult to maintain (never
seen a dumb installer crashing the registry?)

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

And they end in .so.x.y, not .dll :-)

We had to change th esuffix, so changing the prefix will not break anything
more (i.e. almost nothing IIRC).

> 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 would mean that install.exe should analyze DLL dependencies when
installing an exe to list all the cygwin directories where to find DLLs;
however this will now add a dependency on the order of installation between
packages providing DLLs and the ones providing EXEs because this would not
be possible if the installed EXE reference a not-yet-installed DLL :-)

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

Sure, but I'm not sure install.exe will be able to solve the problem without
being provided with a lot of other info. (BTW does setup.exe install things
by calling install.exe or just by untarring them at the proper place?)

Another problem is that people may use cygwin as their hosting UNIX-on-WIN
environment and use install.exe to install their application code that may
be mingw32 or natively compiled! here the install.exe magic (which is
definitely not expected by UNIX users) will broke everything :-)

The problem that install.exe is more a programming environment tool than an
end-user tool that is to be executed when one simply wants to use a package.
Even on UNIX, one rarely if ever execute "install" when installing a binary
distribution fo a package.

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

True!

Cheers

		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@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]