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