[perl #36119] [PATCH] Reapply execute permissions on dynclasses for HP-UX

[Nick Glencross]

# New Ticket Created by Nick Glencross
# Please include the string: [perl #36119]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36119 >

Folks,

this small patch fixes a current problem with loading dynclasses on
HP-UX. The libraries are copied from dynclasses/ to
runtime/parrot/dynext/ but in the process lose their execute flags which
is one of the prerequisites for dlopen to open it.

Regards,

Nick

p.s. I've been having a look at how the internals of Configure work. I
like it! It's too early to say, but in the same way that it determines
if the C compiler is gcc, it may be necessary to do something similar
for the linker. Too early to say though...

[It looks like most of the initial values for Configure are extracted
from Perl. I need to find out why it chooses strange values for my 'ld',
unless we are misinterpreting some of their meanings]

[Leopold Toetsch]

Nick Glencross (via RT) wrote:

> + if ($^O ne 'MSWin32') {

I'd much more prefer one of:
a) if $^O eq 'hpux'
b) fix the "copy" to preserve perms

Anyway, as hpux is still broken in several other places, I'll drop a
note in PLATFORMS and not apply the patch now.

leo

[Nick Glencross]

Leopold Toetsch wrote:

While this change was put in specifically for HP-UX, from what I've seen
most Unices do actually have execute permissions on dynamic libraries,
which are currently lost in the copy. It just so happens that HP-UX is
really unhappy about it. That's why I've said chmod for non-Windows.

[Have a look in runtime/parrot/dynext, and you'll see that Linux has
libnci_test.so with execute, but the others don't]

I don't think that File::Copy is intended to preserve execute flags,
it's aim for for cross-platform compatibility.

Anyhow, as you say, let's leave this for the time being until I've made
better progress on HP-UX next week.

Nick

[Joshua Hoblitt via RT]

[cut from a off list thread between jhoblitt & nickg]

>As a general comment, 36119 makes me a little nervous as 'chmod' isn't
>something you can count on unless your on a POSIX like system and osname
>ne 'MSWin32' certainly would encompass non-POSIX systems. Are you
>planning on retool this patch to be more pedantic about platforms?
>
>
I guess that I need to find out whether chmod dies with an error if it
isn't supported, or silently continues. I'm hoping that it just silently
continues so that we can leave it as it is. If the platform needs
executes on the library, then this line should ensure that.

I would rather that we had an exception list of platforms for which it
doesn't work. I think what's best is if I post to the list to ask if
chmod dies if it is not supported.. Would you agree?

Cheers,

Nick

[Joshua Hoblitt]

On Sun, Oct 09, 2005 at 01:31:54PM -0700, Joshua Hoblitt via RT wrote:
> [cut from a off list thread between jhoblitt & nickg]
>
> >As a general comment, 36119 makes me a little nervous as 'chmod' isn't
> >something you can count on unless your on a POSIX like system and osname
> >ne 'MSWin32' certainly would encompass non-POSIX systems. Are you
> >planning on retool this patch to be more pedantic about platforms?
> >
> >
> I guess that I need to find out whether chmod dies with an error if it
> isn't supported, or silently continues. I'm hoping that it just silently
> continues so that we can leave it as it is. If the platform needs
> executes on the library, then this line should ensure that.

I think chmod silently does nothing if it isn't supported on that
platform but I could be wrong. Before we go that route... why don't we
try Leo's original suggestion of trying to preserve the permissions
during the copy. Can you try the attached patch and see if it works?

> I would rather that we had an exception list of platforms for which it
> doesn't work. I think what's best is if I post to the list to ask if
> chmod dies if it is not supported.. Would you agree?

It probably won't work on MacOS, MSWin32, os2, VMS, epoc, NetWare, or
dos and who knows how many other platforms that Perl runs on. I think
we're much better off using inclusive rather and exclusive lists.

Cheers,

-J

--

[Nick Glencross]

Joshua Hoblitt via RT wrote:

>- copy("$_$LOAD_EXT", $dest) or die "Copy $_$LOAD_EXT failed ($?)\n";
>+ File::Copy::syscopy("$_$LOAD_EXT", $dest) or die "Copy $_$LOAD_EXT failed ($?)\n";
>
Certainly on cygwin File::Copy::syscopy also seems to lose execute
permissions, despite what the manual page might imply. I recall trying
it before going down the chmod route.

I'll submit a patch this evening which just checks for HP-UX & cygwin.

Nick

[Nick Glencross]

Joshua Hoblitt via RT wrote:

>>>As a general comment, 36119 makes me a little nervous as 'chmod' isn't
>>>something you can count on unless your on a POSIX like system and osname
>>>ne 'MSWin32' certainly would encompass non-POSIX systems. Are you
>>>planning on retool this patch to be more pedantic about platforms?
>>>
>>>

The easiest thing to do is resubmit the patch, as suggested, with
specific platforms listed. We can then tweak them should more come along.

Thanks,

Nick

[Joshua Hoblitt via RT]

> [nickg - Mon Oct 10 12:11:00 2005]:

Applied as r9484. Thanks.

-J