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

[Corinna Vinschen-2]

Weird question, right?

Here's the problem.

Assume you have a file "foo.so" on Linux.  If you call

  dlopen ("./foo.so", RTLD_LAZY);

it succeeds, but

  dlopen ("./foo", RTLD_LAZY);

fails because the dlopen function never adds any suffixes like .so
automatically.

Now assume you have a "foo.dll" file on Cygwin.

  dlopen ("./foo.dll", RTLD_LAZY);

succeeds, but so does

  dlopen ("./foo", RTLD_LAZY);

The reason is that Cygwin checks for the .dll suffix as well as the
Windows LoadLibrary function does.

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.

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

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?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[Larry Hall (Cygwin)]

On 11/02/2009 11:48 AM, Corinna Vinschen wrote:

> Weird question, right?
>
> Here's the problem.
>
> Assume you have a file "foo.so" on Linux.  If you call
>
>    dlopen ("./foo.so", RTLD_LAZY);
>
> it succeeds, but
>
>    dlopen ("./foo", RTLD_LAZY);
>
> fails because the dlopen function never adds any suffixes like .so
> automatically.
>
> Now assume you have a "foo.dll" file on Cygwin.
>
>    dlopen ("./foo.dll", RTLD_LAZY);
>
> succeeds, but so does
>
>    dlopen ("./foo", RTLD_LAZY);
>
> The reason is that Cygwin checks for the .dll suffix as well as the
> Windows LoadLibrary function does.
>
> 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.

OK, I'll admit I'm responding with a question without actually looking at the
code and so one can feel free to ignore me.  However the thought that came
to my mind is, should it really matter if dlopen() checks?  What does the check
give us that just passing the name along to LoadLibrary() doesn't?  At first
impression, doing the check just prematurely rejects names without the DLL
suffix
that would otherwise be accepted by Windows.  Since there's a source level
change
that (typically) needs to happen to make the code work on Windows as opposed
to Linux/Unix, what benefit are we getting from this added check?

--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

[Corinna Vinschen-2]

On Nov  2 14:17, Larry Hall (Cygwin) wrote:

> On 11/02/2009 11:48 AM, 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.
>
> OK, I'll admit I'm responding with a question without actually looking at the
> code and so one can feel free to ignore me.  However the thought that came
> to my mind is, should it really matter if dlopen() checks?  What does the check
> give us that just passing the name along to LoadLibrary() doesn't?  At first
> impression, doing the check just prematurely rejects names without
> the DLL suffix
> that would otherwise be accepted by Windows.  Since there's a source
> level change
> that (typically) needs to happen to make the code work on Windows as opposed
> to Linux/Unix, what benefit are we getting from this added check?

Good question, that's exactly why I'm asking.

Answer:  Nothing but *maybe* a less surprising behaviour in terms of
POSIX compatibility.  Allowing automatic file extension is not part of
the standards and not even mentioned as a possible option.  Sure, if
that's nothing to worry about, we can stick to the current behaviour.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[Christopher Faylor-8]

On Mon, Nov 02, 2009 at 09:33:49PM +0100, Corinna Vinschen wrote:

>On Nov  2 14:17, Larry Hall (Cygwin) wrote:
>> On 11/02/2009 11:48 AM, 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.
>>
>> OK, I'll admit I'm responding with a question without actually looking at the
>> code and so one can feel free to ignore me.  However the thought that came
>> to my mind is, should it really matter if dlopen() checks?  What does the check
>> give us that just passing the name along to LoadLibrary() doesn't?  At first
>> impression, doing the check just prematurely rejects names without
>> the DLL suffix
>> that would otherwise be accepted by Windows.  Since there's a source
>> level change
>> that (typically) needs to happen to make the code work on Windows as opposed
>> to Linux/Unix, what benefit are we getting from this added check?
>
>Good question, that's exactly why I'm asking.
>
>Answer:  Nothing but *maybe* a less surprising behaviour in terms of
>POSIX compatibility.  Allowing automatic file extension is not part of
>the standards and not even mentioned as a possible option.  Sure, if
>that's nothing to worry about, we can stick to the current behaviour.

There is already .dll mumbo jumbo going on in dlopen.  I'd rather just
remove it and make it behave as much like linux as possible, especially
since 1.7 has so many other changes to backwards comtemptibility.

cgf

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

[Larry Hall (Cygwin)]

On 11/02/2009 03:33 PM, Corinna Vinschen wrote:

> On Nov  2 14:17, Larry Hall (Cygwin) wrote:
>> On 11/02/2009 11:48 AM, 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.
>>
>> OK, I'll admit I'm responding with a question without actually looking at the
>> code and so one can feel free to ignore me.  However the thought that came
>> to my mind is, should it really matter if dlopen() checks?  What does the check
>> give us that just passing the name along to LoadLibrary() doesn't?  At first
>> impression, doing the check just prematurely rejects names without
>> the DLL suffix
>> that would otherwise be accepted by Windows.  Since there's a source
>> level change
>> that (typically) needs to happen to make the code work on Windows as opposed
>> to Linux/Unix, what benefit are we getting from this added check?
>
> Good question, that's exactly why I'm asking.
>
> Answer:  Nothing but *maybe* a less surprising behaviour in terms of
> POSIX compatibility.  Allowing automatic file extension is not part of
> the standards and not even mentioned as a possible option.  Sure, if
> that's nothing to worry about, we can stick to the current behaviour.

Ah, now that's starting to ring a bell.  OK, I understand why it was put in.

I guess I would come down on the side that we're stuck with Windows
implementation here (OK, not entirely true but...) so trying to circumvent
something that Windows allows probably just makes things more difficult.
For instance, going back to my comment about the need to make a source
level change here anyway, if we don't do checking in dlopen(), such a
change could be avoided.  I'm thinking of a case where foo.so is the Linux
name and the makefile is altered (instead) to generate foo.so.dll for
Cygwin.  OK, I expect this isn't going to be the average case by any
stretch of the imagination but it still seems like it's a nice "feature" that
someone might want to leverage.  The only advantage I can see to leaving
the current checks in place is to be more dogged in our attempts to be
POSIX compliant.  I don't object to POSIX but in this case, I'm wondering
if it really doesn't have any merit.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      [phone] - RFK Office
216 Dalton Rd.                          [phone] - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

[Karl M]

  <20091102203348.GC6836@...>

  <4AEF5B7C.90600@...>
 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> Date: Mon=2C 2 Nov 2009 17:21:48 -0500
> From: Larry Hall
> Subject: Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?
>
> On 11/02/2009 03:33 PM=2C Corinna Vinschen wrote:
>> On Nov 2 14:17=2C Larry Hall (Cygwin) wrote:
>>> On 11/02/2009 11:48 AM=2C Corinna Vinschen wrote:
>>>> For 1.7 our choice is to keep dlopen() checking for the .dll suffix to
>>>> be more Windows-like=2C 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.
>>>
>>> OK=2C I'll admit I'm responding with a question without actually lookin=
g at the
>>> code and so one can feel free to ignore me. However the thought that ca=
me
>>> to my mind is=2C should it really matter if dlopen() checks? What does =
the check
>>> give us that just passing the name along to LoadLibrary() doesn't? At f=
irst
>>> impression=2C doing the check just prematurely rejects names without
>>> the DLL suffix
>>> that would otherwise be accepted by Windows. Since there's a source
>>> level change
>>> that (typically) needs to happen to make the code work on Windows as op=
posed

>>> to Linux/Unix=2C what benefit are we getting from this added check?
>>
>> Good question=2C that's exactly why I'm asking.
>>
>> Answer: Nothing but *maybe* a less surprising behaviour in terms of
>> POSIX compatibility. Allowing automatic file extension is not part of
>> the standards and not even mentioned as a possible option. Sure=2C if
>> that's nothing to worry about=2C we can stick to the current behaviour.
>
> Ah=2C now that's starting to ring a bell. OK=2C I understand why it was p=

ut in.
>
> I guess I would come down on the side that we're stuck with Windows
> implementation here (OK=2C not entirely true but...) so trying to circumv=
ent
> something that Windows allows probably just makes things more difficult.
> For instance=2C going back to my comment about the need to make a source
> level change here anyway=2C if we don't do checking in dlopen()=2C such a
> change could be avoided. I'm thinking of a case where foo.so is the Linux
> name and the makefile is altered (instead) to generate foo.so.dll for
> Cygwin. OK=2C I expect this isn't going to be the average case by any
> stretch of the imagination but it still seems like it's a nice "feature" =
that
> someone might want to leverage. The only advantage I can see to leaving
> the current checks in place is to be more dogged in our attempts to be
> POSIX compliant. I don't object to POSIX but in this case=2C I'm wonderin=
g
> if it really doesn't have any merit.
>
But this does not seem to be about POSIX compliance=2C insted it seems (to =
me)
to be about non-POSIX non-compliance=2C for which we have no requirement.

...Karl   =20
_________________________________________________________________
Bing brings you maps=2C menus=2C and reviews organized in one place.
http://www.bing.com/search?q=3Drestaurants&form=3DMFESRP&publ=3DWLHMTAG&cre=
a=3DTEXT_MFESRP_Local_MapsMenu_Resturants_1x1=

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

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 11/2/2009 9:48 AM:

> Weird question, right?
>
> Here's the problem.
>
> Assume you have a file "foo.so" on Linux.  If you call
>
>   dlopen ("./foo.so", RTLD_LAZY);
>
> it succeeds, but
>
>   dlopen ("./foo", RTLD_LAZY);
>
> fails because the dlopen function never adds any suffixes like .so
> automatically.

And POSIX says "If file contains a <slash> character, the file argument is
used as the pathname for the file. Otherwise, file is used in an
implementation-defined manner to yield a pathname."  So I think we are
better off NOT adding an implicit .dll.

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

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrvnhAACgkQ84KuGfSFAYBbVwCfQgwsMJtWPhW+0Ed+gCKFaI0L
smQAoKxXOi1fvSBDbGXxERRhToQXuPCS
=rgXj
-----END PGP SIGNATURE-----

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

[Thomas Wolff-3]

Corinna Vinschen schrieb:

> On Nov  2 14:17, Larry Hall (Cygwin) wrote:
>  
>> On 11/02/2009 11:48 AM, 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.
>>>      
>> OK, I'll admit I'm responding with a question without actually looking at the
>> code and so one can feel free to ignore me.  However the thought that came
>> to my mind is, should it really matter if dlopen() checks?  What does the check
>> give us that just passing the name along to LoadLibrary() doesn't?  At first
>> impression, doing the check just prematurely rejects names without
>> the DLL suffix
>> that would otherwise be accepted by Windows.  Since there's a source
>> level change
>> that (typically) needs to happen to make the code work on Windows as opposed
>> to Linux/Unix, what benefit are we getting from this added check?
>>    
>
> Good question, that's exactly why I'm asking.
>
> Answer:  Nothing but *maybe* a less surprising behaviour in terms of
> POSIX compatibility.  Allowing automatic file extension is not part of
> the standards and not even mentioned as a possible option.  Sure, if
> that's nothing to worry about, we can stick to the current behaviour.
>  

In terms of compatibility and least surprising behavior, what about
accepting
dlopen ("bla.so") and looking for "bla.dll"? This might help to avoid
source changes,
and it's kind of like the ".exe magic".
If POSIX requires to give the suffix I'm not sure whether this was wise
and whether they had
different suffixes in different environments in mind. I wonder how this
is handled on Mac
with its ".dylib" suffixes.

Thomas

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

[Yaakov (Cygwin/X)]

On 03/11/2009 02:21, Thomas Wolff wrote:
> In terms of compatibility and least surprising behavior, what about
> accepting dlopen ("bla.so") and looking for "bla.dll"?

No, Ruby and Apache2 (among others) use .so on all platforms, including
native Win32.


Yaakov

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

[Corinna Vinschen-2]

On Nov  2 20:05, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Corinna Vinschen on 11/2/2009 9:48 AM:
> > Weird question, right?
> >
> > Here's the problem.
> >
> > Assume you have a file "foo.so" on Linux.  If you call
> >
> >   dlopen ("./foo.so", RTLD_LAZY);
> >
> > it succeeds, but
> >
> >   dlopen ("./foo", RTLD_LAZY);
> >
> > fails because the dlopen function never adds any suffixes like .so
> > automatically.
>
> And POSIX says "If file contains a <slash> character, the file argument is
> used as the pathname for the file. Otherwise, file is used in an
> implementation-defined manner to yield a pathname."  So I think we are
> better off NOT adding an implicit .dll.
>
> > 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.

Maybe Chuck can make this definitive?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[Linda Walsh]

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

[Charles Wilson-2]

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:

#if defined(__HPUX__)
# define MODULE_EXTENSION ".sl"
#elif !defined(__CYGWIN__) && !defined(_WIN32)
# define MODULE_EXTENSION ".so"
#else
# define MODULE_EXTENSION ""
#endif
#define MODULE "libfoo" MODULE_EXTENSION

But, IMO, they should Not. Do. That. and deserve whatever pain they get.

--
Chuck

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

[Corinna Vinschen-2]

On Nov  3 20:13, Charles Wilson wrote:

> Corinna Vinschen wrote:
> > 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:
>
> #if defined(__HPUX__)
> # define MODULE_EXTENSION ".sl"
> #elif !defined(__CYGWIN__) && !defined(_WIN32)
> # define MODULE_EXTENSION ".so"
> #else
> # define MODULE_EXTENSION ""
> #endif
> #define MODULE "libfoo" MODULE_EXTENSION
>
> But, IMO, they should Not. Do. That. and deserve whatever pain they get.

And then again, as Yaakov already wrote, packages with runtime
modules like ruby, apache, and openssl use the .so suffix on all
platforms.

But what about perl?  It uses the .dll suffix for modules on Cygwin.
Does it call dlopen("foo.dll") or dlopen("foo")?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

[Charles Wilson-2]

Corinna Vinschen wrote:

> But what about perl?  It uses the .dll suffix for modules on Cygwin.

perl uses dl_dlopen.xs on cygwin AFAICT, which basically passes its
arguments unchanged to the system dlopen.

> Does it call dlopen("foo.dll") or dlopen("foo")?

Looking at DynaLoader_pm.PL (this is self-modifying code, used to
generate the actual DynaLoader.pm, so it's a little odd):

($dl_dlext, $dl_so, $dlsrc) = @Config::Config{qw(dlext so dlsrc)};

sub dl_findfile {
...
   #  Only files should get this far...
   my(@names, $name);    # what filenames to look for
   if (m:-l: ) {          # convert -lname to appropriate library name
     s/-l//;
     push(@names,"lib$_.$dl_so");
     push(@names,"lib$_.a");
   } else {                # Umm, a bare name. Try various alternatives:
     # these should be ordered with the most likely first
     push(@names,"$_.$dl_dlext")    unless m/\.$dl_dlext$/o;
     push(@names,"$_.$dl_so")     unless m/\.$dl_so$/o;
     push(@names,"lib$_.$dl_so")  unless m:/:;
     push(@names,"$_.a")          if !m/\.a$/ and $dlsrc eq "dl_dld.xs";
     push(@names, $_);
   }
...

On cygwin:
use Config; print join("\n",@Config::Config{qw(dlext so dlsrc)});
dll
dll
dl_dlopen.xs

So it looks like perl itself accepts either a "bare" library name, or a
properly .dll-decorated one (or even "-lfoo"!) -- but will eventually
try the .dll extension if "bare" fails.

--
Chuck

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

[Corinna Vinschen-2]

On Nov  4 22:38, Charles Wilson wrote:

> Corinna Vinschen wrote:
>
> > But what about perl?  It uses the .dll suffix for modules on Cygwin.
>
> perl uses dl_dlopen.xs on cygwin AFAICT, which basically passes its
> arguments unchanged to the system dlopen.
>
> > Does it call dlopen("foo.dll") or dlopen("foo")?
>
> Looking at DynaLoader_pm.PL (this is self-modifying code, used to
> generate the actual DynaLoader.pm, so it's a little odd):
> [...]
> On cygwin:
> use Config; print join("\n",@Config::Config{qw(dlext so dlsrc)});
> dll
> dll
> dl_dlopen.xs
>
> So it looks like perl itself accepts either a "bare" library name, or a
> properly .dll-decorated one (or even "-lfoo"!) -- but will eventually
> try the .dll extension if "bare" fails.

It looks like perl tries the dll suffix immediately.  I just tried
this:

  $ perl -e 'use Alias;'

under strace and the first access is already to the file called
/usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Alias/Alias.dll

I removed the automatic adding of the .dll suffix, and the above
perl statement still works fine and dlopen succeeds.

I'm going to check this change in.  I think I should prepare a new
Cygwin release quite soon, not only for testing this change, but also
due to the cygpath problem.


Thanks to all of you,
Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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