documentation / behavior discrepancy with lt_dlopenext

documentation / behavior discrepancy with lt_dlopenext

[Andy Wingo]

Hello list,

The ltdl docs say:

    — Function: lt_dlhandle lt_dlopenext (const char *filename)

        The same as lt_dlopen, except that it tries to append different file
        name extensions to the file name. If the file with the file name
        FILENAME cannot be found libltdl tries to append the following
        extensions: [...]

However, there are cases in which lt_dlopenext does not look for a bare
filename.  Specifically the code does:

      if (!filename
          || !advise
          || !advise->try_ext
          || has_library_ext (filename))
        try the bare file
      else if (filename && *filename)
        try extensions...

So, we see that if has_library_ext is FALSE, we don't try the bare
file.  But that check fails for full paths, like
"/usr/lib64/libSDL-1.2.so.0.11.3".

    $ strace guile -c '(dynamic-link "/usr/lib64/libSDL-1.2.so.0.11.3")'
    [...]
    open("/usr/lib64/libSDL-1.2.so.0.11.3.la", O_RDONLY) = -1 ENOENT (No such file or directory)
    open("/usr/lib64/libSDL-1.2.so.0.11.3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
    [...]

The documentation and the code do not agree.  I propose that we fix the
code, to add another `stat' (I know) -- of the bare file name, before
trying to add extensions, in the dlopenext case.

What do you think?

Andy
-- 
http://wingolog.org/

Re: documentation / behavior discrepancy with lt_dlopenext

[Ralf Wildenhues]

Hi Andy,

* Andy Wingo wrote on Wed, Mar 30, 2011 at 07:19:18PM CEST:
>     — Function: lt_dlhandle lt_dlopenext (const char *filename)
> 
>         The same as lt_dlopen, except that it tries to append different file
>         name extensions to the file name. If the file with the file name
>         FILENAME cannot be found libltdl tries to append the following
>         extensions: [...]
> 
> However, there are cases in which lt_dlopenext does not look for a bare
> filename.  Specifically the code does:
> 
>       if (!filename
>           || !advise
>           || !advise->try_ext
>           || has_library_ext (filename))
>         try the bare file
>       else if (filename && *filename)
>         try extensions...
> 
> So, we see that if has_library_ext is FALSE, we don't try the bare
> file.  But that check fails for full paths, like
> "/usr/lib64/libSDL-1.2.so.0.11.3".

Well, I'd kinda argue that that file has a library extension, but after
that extension, there's version the info extension.  This is common for
several systems (e.g., GNU/Linux, Solaris).

> The documentation and the code do not agree.  I propose that we fix the
> code, to add another `stat' (I know) -- of the bare file name, before
> trying to add extensions, in the dlopenext case.
> 
> What do you think?

I think that has_library_ext is too naive, but I'm not yet sure how to
fix it easily and reliably.  I also wonder whether other pieces of the
Libtool code make the same assumptions ...

but somehow matching/ignoring the $versuffix could avoid that dreaded
extra stat.  Maybe.

Thanks for the bug report,
Ralf

Re: documentation / behavior discrepancy with lt_dlopenext

[Andy Wingo]

Greets Ralf,

On Wed 30 Mar 2011 21:20, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> * Andy Wingo wrote on Wed, Mar 30, 2011 at 07:19:18PM CEST:
>> "/usr/lib64/libSDL-1.2.so.0.11.3".
>
> Well, I'd kinda argue that that file has a library extension, but after
> that extension, there's version the info extension.  This is common for
> several systems (e.g., GNU/Linux, Solaris).

Sure, that's probably right.  However it's tough to tell.  You could
look for "\.so(\.|$)" or something.  But that's encoding lots of
details.

I think that uses of dlopenext are already oblivious to `stat' calls,
because they sanction looking for .la files before e.g. .so files, so
it's not a problem to just do what the doc says: bare path first, then
grovel extensions.

MHO :)

Cheers,

Andy
-- 
http://wingolog.org/

Re: documentation / behavior discrepancy with lt_dlopenext

[Bob Friesenhahn]

On Wed, 30 Mar 2011, Andy Wingo wrote:
>
> Sure, that's probably right.  However it's tough to tell.  You could
> look for "\.so(\.|$)" or something.  But that's encoding lots of
> details.
>
> I think that uses of dlopenext are already oblivious to `stat' calls,
> because they sanction looking for .la files before e.g. .so files, so
> it's not a problem to just do what the doc says: bare path first, then
> grovel extensions.

Use of .la files does not incur more stat calls unless the .la file is 
not present.  Using .la files is really a better solution than what 
you are trying to do.  The .la file format is just simple text so 
guile could construct its own .la files (or rename/link-to existing 
.la files) to load versioned libraries in a particular way.

Clearly libltdl is not matching its documentation and what you 
requested to do should have worked.  Always keep in mind that there is 
a cost in terms of performance and security whenever libltdl looks in 
another place.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Re: documentation / behavior discrepancy with lt_dlopenext

[Andy Wingo]

On Thu 31 Mar 2011 03:31, Bob Friesenhahn <bfriesen@simple.dallas.tx.us> writes:

> On Wed, 30 Mar 2011, Andy Wingo wrote:
>>
>> Sure, that's probably right.  However it's tough to tell.  You could
>> look for "\.so(\.|$)" or something.  But that's encoding lots of
>> details.
>>
>> I think that uses of dlopenext are already oblivious to `stat' calls,
>> because they sanction looking for .la files before e.g. .so files, so
>> it's not a problem to just do what the doc says: bare path first, then
>> grovel extensions.
>
> Use of .la files does not incur more stat calls unless the .la file is
> not present.  Using .la files is really a better solution than what you
> are trying to do.

That might well be true!  (I don't know enough of the details.)  However
on most systems that does not work for system libraries like libc.  This
particular bug report came from a user who wanted to link against a
library without installing the -dev package on his OS, so he wouldn't
have .la files anyway.  Not to mention distros that don't install .la
files, like Fedora et al.

Just to clarify the use case.  I see we all agree the current behavior
is a bug :)

Cheers,

Andy
-- 
http://wingolog.org/

Re: documentation / behavior discrepancy with lt_dlopenext

[Andy Wingo]

Hi list,

Re-sending this report, now that you have debbugs.

On Wed 30 Mar 2011 19:19, Andy Wingo <wingo@pobox.com> writes:

> The ltdl docs say:
>
>     — Function: lt_dlhandle lt_dlopenext (const char *filename)
>
>         The same as lt_dlopen, except that it tries to append different file
>         name extensions to the file name. If the file with the file name
>         FILENAME cannot be found libltdl tries to append the following
>         extensions: [...]
>
> However, there are cases in which lt_dlopenext does not look for a bare
> filename.  Specifically the code does:
>
>       if (!filename
>           || !advise
>           || !advise->try_ext
>           || has_library_ext (filename))
>         try the bare file
>       else if (filename && *filename)
>         try extensions...
>
> So, we see that if has_library_ext is FALSE, we don't try the bare
> file.  But that check fails for full paths, like
> "/usr/lib64/libSDL-1.2.so.0.11.3".
>
>     $ strace guile -c '(dynamic-link "/usr/lib64/libSDL-1.2.so.0.11.3")'
>     [...]
>     open("/usr/lib64/libSDL-1.2.so.0.11.3.la", O_RDONLY) = -1 ENOENT (No such file or directory)
>     open("/usr/lib64/libSDL-1.2.so.0.11.3.so", O_RDONLY) = -1 ENOENT (No such file or directory)
>     [...]
>
> The documentation and the code do not agree.  I propose that we fix the
> code, to add another `stat' (I know) -- of the bare file name, before
> trying to add extensions, in the dlopenext case.
>
> What do you think?

The original discussion was here:

  http://thread.gmane.org/gmane.lisp.guile.bugs/5387

Any ideas? :-)

Andy
-- 
http://wingolog.org/