This is the mail archive of the
mailing list for the Cygwin project.
Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?
Corinna Vinschen wrote:
> On Nov 2 20:05, Eric Blake wrote:
>> According to Corinna Vinschen on 11/2/2009 9:48 AM:
>>> While we tend to change the implementation to be more Linux-like,
>>> there could be some tools out there which erroneously depend on the
>>> Windows-like behaviour of Cygwin's dlopen().
>> My only worry is whether libtool depends on this behavior. But a quick
>> look at the source code (although not a definitive one) shows that libtool
>> is already adding a trailing dot on its own, in order to bypass window's
>> automatic .dll appending. So if anything, I'm guessing that not adding an
>> implicit suffix is actually what libtool would prefer.
Not exactly. That behavior only occurs in the loadlibrary.c file, which
is the native win32 libltdl implementation. cygwin uses the dlopen.c
implemention (first), and then falls back on the loadlibrary one only if
dlopen method fails.
But the main point is this: in *most* cases, the name of the module to
be opened is expected to include the suffix (which might actually be ".la").
If there is a libltdl client out there that is written as
lt_dlopen("libfoo") and expects to get "libfoo.dll" -- it won't really
work cross platform, because the unix/dlopen wrapper is not going to
magically find "libfoo.so".
> Maybe Chuck can make this definitive?
But that's not to say there aren't some packages out there that do
something evil like this:
# define MODULE_EXTENSION ".sl"
#elif !defined(__CYGWIN__) && !defined(_WIN32)
# define MODULE_EXTENSION ".so"
# define MODULE_EXTENSION ""
#define MODULE "libfoo" MODULE_EXTENSION
But, IMO, they should Not. Do. That. and deserve whatever pain they get.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple