develooper Front page | perl.perl5.porters | Postings from November 2013

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

Thread Previous | Thread Next
From:
Brian Fraser
Date:
November 28, 2013 18:18
Subject:
Re: Option to use and create "unique" library names
Message ID:
CA+nL+naP1OmAuF_EQT4ZShS6aJTR4r=fWbNxOHEE-T9b2hMLTw@mail.gmail.com
On Thu, Nov 28, 2013 at 2:55 PM, Craig A. Berry <craig.a.berry@gmail.com>wrote:

> On Tue, Nov 26, 2013 at 6:20 PM, Leon Timmermans <fawaka@gmail.com> wrote:
> > On Wed, Nov 20, 2013 at 4:04 PM, Craig A. Berry <craig.a.berry@gmail.com
> >
> > wrote:
> >>
> >> We've done this since forever on VMS; the actual shareable image
> >> (dynamic library) names come out as PL_HASH__UTIL.EXE and
> >> PL_LIST__UTIL.EXE.  There is a function called DynaLoader::mod2fname
> >> that gets called from XSLoader::load.  Here's what it does:
> >>
> >> $ perl -MDynaLoader -e "@a=('Module','SubModule','SubSubModule');
> >> print DynaLoader::mod2fname(\@a);"
> >> PL_Module__SubModule__SubSubModule
> >>
> >> So I think you can get what you want by simply implementing a
> >> mod2fname function (ours is in vms/vms.c, but dl_xxx.xs might be a
> >> better place for a new one).  And I think there's a good chance you
> >> wouldn't need any MakeMaker modifications as mod2fname, if it exists,
> >> is already called from MM_Unix::init_main().
> >>
> >> Plus it seems less than optimal to introduce an entirely new mechanism
> >> to do something for which there is already an existing mechanism.
> >
> >
> > Actually, it seems ExtUtils::CBuilder is currently not doing this
> correctly
> > (it only passes the basename to mod2fname). Module::Build contains a
> > workaround that does do the right thing, which is why no one noticed this
> > before.
>
> Ouch.  You're right. ExtUtils::CBuilder::Platform::VMS::lib_file() is
> definitely wrong.  I don't really see how to fix it as that interface
> assumes you can create the correct loadable library name from the name
> of a single object file, but you can't.
>
> It looks like ExtUtils::CBuilder::Platform::os2::_do_link may do
> things right with regard to mod2fname as it only uses the output of
> lib_file() as a fallback.  But I don't think any of this should be in
> platform-specific overrides.  The definedness of DynaLoader::mod2fname
> is what determines whether it's used at run time, so the same thing
> should determine whether it's used at build time.
>

Yeah, we were discussing exactly that on irc yesterday. Overriding _do_link
is dodgy though, since it causes tests to fail, and means that
$b->link(lib_file => $b->lib_file($object)) ne $b->link().
I think that I have the least worst solution, though. We can have
->lib_file() accept an optional module_name parameter, and if that's
defined, we can use mod2fname there. Only two modules on CPAN use lib_file
directly, and only one would need changing, and the change is fully
backwards compatible, so I think it might be the way to go.

With that change, all tests pass on linux with d_libname_unique defined;
since the commits also remove the handling of mod2fname in the
platform-specific files, this will need smoking on VMS (and OS2, I guess,
but that's unlikely)

Proposed changes are now on
http://perl5.git.perl.org/perl.git/shortlog/refs/heads/hugmeir/d_libname_unique

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