This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?


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
fully.
---
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
here?
----

  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.

BUT also,

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


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 source-level compatibility.

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): linux-64bit: /usr/lib64/qt3/plugins/imageformates: libqjpeg.lib64.so, libqmng.lib64.so
), 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
/lib/qt3/plugins/imageformats:
	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...:-)

linda




-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple


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