On Wed, May 25, 2011 at 10:28 AM, Pascal Giard <evily...@gmail.com> wrote:
> Hello Chris,
>
> On Wed, May 25, 2011 at 1:49 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote:
> [...]
>> I guess we only stressed this on windows were we've hit the problem
>> but solved it differently. It looks for both libmp3lame.dll/.so and
>> libmp3lame-0.dll/.so; "-0" be windows version of .so version #'s.
>>
>> I couldn't really find any common solutions to this so I guess the
>> main solution would be to add libmp3lame.so.0 to the list of filenames
>> to search for. I think lt_dlopenext() can handle this full name.
>
> at least here, lt_dlopenext() goes straight to attempting
> libmp3lame.so.0.{la,so} when "libmp3lame.so.0" is specified.
>
> I can't seem to find a way to modify the extensions it will attempt,
> it does not seem to be accessible from the outside of ltdl.
> lt_dlforeachfile seems to be total overkill for this and only returns
> the filename without the extension anyway... (in my case it calls my
> function with /usr/lib/libmp3lame while only
> /usr/lib/libmp3lame{.so.0,.so.0.0.0} exist).
> But ltdl does not seem to be designed for our purpose as there is no
> other mechanism...
>
> I could only fix this by using lt_dlopen() with a full filename
> (appended extension myself with sprintf).
> I'm to shy to share my ugly patch tho as it involves a fixed size char
> array that can only be abused.
> (The magic should happen in the lsx_open_dllibrary function of src/util.c).
>
Thanks for feedback on behavior.
I'm not up for re-implementing lt_dlopenext() at the moment although
that sounds like best way to go. I'm thinking as a short term fix we
could scan the filename for a ".". If found use lt_dlopen() and if
not use lt_dlopenext()?
Of course, still update all the various library lists to include an
exact .so name.
Chris
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
