This is the mail archive of the
mailing list for the Cygwin project.
Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?
- From: Linda Walsh <cygwin at tlinx dot org>
- To: cygwin at cygwin dot com
- Date: Tue, 03 Nov 2009 16:28:40 -0800
- Subject: Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?
- References: <20091102164807.GA2897@calimero.vinschen.de>
Corinna Vinschen wrote:
For 1.7 our choice is to keep dlopen() checking for the .dll suffix to
be more Windows-like, or to be more Linux-like by dropping the check for
the .dll suffix so that dlopen() fails if the filename isn't specified
Does anybody know such a tool? If so, is there a chance to fix this
easily in that tool or do we have to keep up this behaviour? Finally,
is there another *good* reason to stick to the Windows-like behaviour
I don't have any such tools, but what I'd "rather" see as an
"alternative", from 'source-level' compatibility point of view, is to
1) go ahead make dlopen('file') (no extension), fail as it does on linux.
2) if application tries to open ('file.so'), then it would try to match:
'file.so', then 'file.dll' -- in that order, to provide optimal
At least, that's what I _think_ would provide optimal compatibility.
If I compile a linux source, and if the library calls are the same
(by intent or by accident), then it would "do the right thing" -- so
working linux app might be able to be ported to cygwin with no source
file changes -- just a recompile...
Just trying to think of "logical defaults" that would enable increased
Certainly, requiring that existing sources that dlopen("foo.so"), to be be
special cased to read "dlopen("foo.dll") on windows doesn't seem desirable.
In regards to "2", Under 64-bit linux, there is a separate lib64 that is
added between the name and ".so" extension, but I *doubt* the apps
explicitly specify the 'alternate' architecture unless they really
MEAN only 'lib64'. I'd *guess*, that a 64-bit app opening the QT3
jpeg library "qjpeg"
( (looking on a 64-bit linux mach):
), would simply try to open the "jpeg" name, and that lower level
libs' would add "libq" + ".so" and . that some even lower binary compat
layer adds the .lib64 before the .so for 64-bit binaries. Supporting
the 'name.so' format as possibly being ' name.dll' (after checking with
.so, would allow that level of source to work unchanged.
On winxp+cygwin1.5, I see those same libs under
libqjpeg.dll and libqmng.dll
It would be a 'nicety' if ported linux apps didn't have to worry that
windows calls something a 'dll' vs. '.so'...
At least that's what I'd do unless someone told me it was really dumb
because "XXYZ" ... then I might change my mind...:-)
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple