[ID 20000116.001] Perl Configure Errors

[Ray Phillips <r.phillips@mailbox.uq.edu.au>]

Dear Perl Maintainers:

I've a couple of trivial bugs to point out to you and a couple of questions
to ask if I may.

I'm installing perl 5.005_03 on an Alpha 3000/400 which is running
NetBSD/alpha 1.4.1.

I've noticed a couple of typos in the prompts that Configure prints:

    On some systems, shared libraries may be available.  Answer 'none' if
    you want to suppress searching of shared libraries for the remaining
    of this configuration.

    What is the file extension used for shared libraries? [so]

The word 'remaining' should be 'remainder'

2) In the prompt that says:

    Some systems may require passing special flags to cc to indicate that
    the resulting executable will use dynamic linking.  To use no flags,
    say "none".

    Any special flags to pass to cc to use dynamic loading? [-Wl,-E
-Wl,-R/lib ]


The question should be 'Any special flags ... dynamic linking?' instead of
asking about 'dynamic loading' that was the correct term for the preceeding
question.

3) In the prompt that says:

    I need to get your e-mail address in Internet format if possible, i.e.
    something like user@host.domain. Please answer accurately since I have
    no easy means to double check it. The default value provided below
    is most probably close to the reality but may not be valid from outside
    your organization...

The word 'the' should be deleted from 'is most probably close to the reality'


That's the end of the typos, now for the questions.


These two errors were thrown up at me during configuration:

setrgid() found.

*** WHOA THERE!!! ***
    The recommended value for $d_setrgid on this machine was "undef"!
    Keep the recommended value? [y]

setruid() found.

*** WHOA THERE!!! ***
    The recommended value for $d_setruid on this machine was "undef"!
    Keep the recommended value? [y]

I found this comment in the combined man page for setrgid and setruid:

    The use of these calls is not portable.  Their use is discouraged; they
    will be removed in the future.

So I assume it was all right for me to answer 'y' to both of these questions?


There's a question about vfork() in the configuration process:

    Perl can only use a vfork() that doesn't suffer from strict
    restrictions on calling functions or modifying global data in
    the child.  For example, glibc-2.1 contains such a vfork()
    that is unsuitable.  If your system provides a proper fork()
    call, chances are that you do NOT want perl to use vfork().

    Do you still want to use vfork()? [n]

NetBSD has a vfork() system call, but how do I tell if my vfork() is good
enough for perl to use or not, and does it make much difference if I choose
fork() instead of vfork()?



Ray Phillips

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---