develooper Front page | perl.perl5.porters | Postings from January 2014

Re: Option to use and create "unique" library names

Thread Previous | Thread Next
From:
Brian Fraser
Date:
January 18, 2014 18:17
Subject:
Re: Option to use and create "unique" library names
Message ID:
CA+nL+nZJL1mw5RKD8r7_Xj6jSmBpEFEqwunoy_94SoKZwvCW2g@mail.gmail.com
On Tue, Jan 7, 2014 at 3:52 AM, bulk88 <bulk88@hotmail.com> wrote:

> Brian Fraser wrote:
>
>> Background:
>> Android's linker has some bugg^Wunusual behavior, in that it caches loaded
>> libraries, but only uses the basename in the cache.  That means that,
>> as far as its dlopen() is concerned, the libraries for Hash::Util and
>> List::Util,
>> both of which are named Util.so, are the same.
>>
>> What we did in the android branch was introduce an option,
>> d_libname_unique,
>> that when defined, has Makemaker create an "unique" libname for each
>> module,
>> and teaches XSLoader and Dynaloader to look for those; So for example,
>> Hash/Util/Util.so becomes Hash/Util/Perl_Hash_Util.so.
>>
>> The changes for this are in http://perl5.git.perl.org/
>> perl.git/shortlog/refs/heads/hugmeir/d_libname_unique and can be tested
>> by compiling perl with -Dd_libname_unique.
>>
>> Any objections to this going in?
>>
>>
> I'm wondering a little bit if Win32 Perl needs this. Win32's runtime
> linker does the same basename matching unless you pass an absolute path
> (Dynaloader passes absolute paths to Win32's runtime linker). A big problem
> results, if a XS DLL has the same filename as non-XS DLL, and another DLL
> tries to link to the filename, and linker finds the XS DLL instead, which
> only exports the boot function, not dozens of non-Perl C functions. Here is
> one with version::'s version.dll conflicting with MS's version.dll (MS
> version.dll is a metadata library for PE files's "version resource")
> https://rt.cpan.org/Ticket/Display.html?id=88458#txn-1308331 . I also
> recently ran into this problem with building http://search.cpan.org/~
> pjacklam/Math-BigInt-GMP-1.37/lib/Math/BigInt/GMP.pm which generated a
> GMP.dll, which linked to gmp.dll, and couldn't be loaded into any process
> due to missing functions (GMP.dll the XS lib's imported functions were
> attempted to be resolved with GMP.dll the XS lib's exported function table
> by the Win32 runtime linker, instead of searching for another gmp.dll using
> the default collection of folders). I had to rename the C function
> exporting gmp.dll to something else and recompile to make it work.
>

I haven't actually tried running this in Windows, but I don't see why it
wouldn't work -- try adding a line with d_libname_unique='define' to the
config files in win32?

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About