Mail Archives: cygwin/2000/09/04/17:19:56
...
> 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
- Raw text -