Front page | perl.perl5.porters |
Postings from December 2013
Re: Option to use and create "unique" library names
Thread Previous
|
Thread Next
From:
Craig A. Berry
Date:
December 1, 2013 21:03
Subject:
Re: Option to use and create "unique" library names
Message ID:
CA+vYcVy5v1wRJMtmuvX78xdxxFtPY5_7=X02cb-TdDLF=6t4gw@mail.gmail.com
On Thu, Nov 28, 2013 at 12:18 PM, Brian Fraser <fraserbn@gmail.com> wrote:
> 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
>> 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
>
I've built that on VMS and the report is at
<http://www.nntp.perl.org/group/perl.daily-build.reports/2013/12/msg154855.html>.
t/op/sub.t is an unrelated problem that I think has been fixed in
blead since your last rebase, ext/Pod-Html/t/cache.t is flaky and
fails sporadically on almost every platform, and lib/perl5db.t is a
long-standing set of problems I've never gotten around to. So I
think you're good to go as far as the tests can tell us.
And to be clear, what I'm testing is the case where
$Config{d_libname_unique} is *not* defined, but using the ancient
mod2fname definition in vms/vms.c. And so we know what you're doing
doesn't collide with that. But I'm now inclined to ditch the old XS
version of mod2fname and use yours, so I may give that a try.
I did note that in your _mod2fname_libname_unique function you have this line:
my $path_max = 1024; # No easy way to get this here
Maybe we can't load POSIX in DynaLoader, but I think what you really
want here is NAME_MAX, not PATH_MAX. What your'e assembling is the
name of an individual file, which may have directory portions
prepended in order to make up a complete path. If we can't call POSIX
directly, we can at least take a straw poll; this on Darwin:
$ perl -e "use POSIX; print POSIX::NAME_MAX . qq/\n/;"
255
So I would rename $path_max to $name_max and make it 255 if a better
number doesn't show up.
Thread Previous
|
Thread Next