[32266] in Perl-Users-Digest
Perl-Users Digest, Issue: 3533 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 31 21:09:32 2011
Date: Mon, 31 Oct 2011 18:09:12 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 31 Oct 2011 Volume: 11 Number: 3533
Today's topics:
installation of PDL <ela@yantai.org>
Re: installation of PDL <justin.1104@purestblue.com>
Re: installation of PDL <rweikusat@mssgmbh.com>
Re: installation of PDL <rweikusat@mssgmbh.com>
Re: installation of PDL <ela@yantai.org>
Re: installation of PDL <ela@yantai.org>
Re: installation of PDL <ben@morrow.me.uk>
Re: installation of PDL <rweikusat@mssgmbh.com>
Re: installation of PDL <ben@morrow.me.uk>
Re: installation of PDL <ela@yantai.org>
Re: installation of PDL <ben@morrow.me.uk>
Re: installation of PDL <kkeller-usenet@wombat.san-francisco.ca.us>
Re: installation of PDL <ben@morrow.me.uk>
PERL_SYS_INIT() <h.b.furuseth@usit.uio.no>
Re: PERL_SYS_INIT() <ben@morrow.me.uk>
Re: PERL_SYS_INIT() <h.b.furuseth@usit.uio.no>
Re: PERL_SYS_INIT() <ben@morrow.me.uk>
Re: PERL_SYS_INIT() <h.b.furuseth@usit.uio.no>
Re: using module <ela@yantai.org>
Re: using module <jondk@FAKE.EMAIL.net>
Re: using module <news@lawshouse.org>
Re: using module <jondk@FAKE.EMAIL.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 31 Oct 2011 16:14:37 +0800
From: "ela" <ela@yantai.org>
Subject: installation of PDL
Message-Id: <j8lldf$vq1$1@ijustice.itsc.cuhk.edu.hk>
In CPAN, I used force install but failed.
/usr/bin/ld:
/base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a(s_sin.o):
relocation R_X86_64_32S against `a local symbol' can not be used when making
a shared object; recompile with -fPIC
/base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [../../blib/arch/auto/PDL/Ops/Ops.so] Error 1
make[2]: Leaving directory `/root/.cpan/build/PDL-2.4.9-gn4Jgf/Basic/Ops'
make[1]: *** [subdirs] Error 2
make[1]: Leaving directory `/root/.cpan/build/PDL-2.4.9-gn4Jgf/Basic'
make: *** [subdirs] Error 2
CHM/PDL-2.4.9.tar.gz
/usr/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
Make had returned bad status, install seems impossible
Failed during this command:
CHM/PDL-2.4.9.tar.gz : make NO
Google searches say -fPIC should be used but in CPAN I don't know how to do
that. Any suggestions?
------------------------------
Date: Mon, 31 Oct 2011 11:56:54 +0000
From: Justin C <justin.1104@purestblue.com>
Subject: Re: installation of PDL
Message-Id: <61f2o8-aqg.ln1@zem.masonsmusic.co.uk>
On 2011-10-31, ela <ela@yantai.org> wrote:
> In CPAN, I used force install but failed.
[snip]
>
> Google searches say -fPIC should be used but in CPAN I don't know how to do
> that. Any suggestions?
Have you tried searching for an RPM (it looks like you're using a RedHat
based system) for PDL? That could solve your problem.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Mon, 31 Oct 2011 13:43:56 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: installation of PDL
Message-Id: <877h3lmg2r.fsf@sapphire.mobileactivedefense.com>
"ela" <ela@yantai.org> writes:
>
> /usr/bin/ld:
> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a(s_sin.o):
> relocation R_X86_64_32S against `a local symbol' can not be used when making
> a shared object; recompile with -fPIC
[...]
> Google searches say -fPIC should be used but in CPAN I don't know how to do
> that. Any suggestions?
The problem is that you're trying to link a static version of the
'math' library (libm.a) into a so-called 'shared object' the perl
interpreter is supposed to load at runtime. This implies that the
address the corresponding 'object module' will be loaded at won't be
known until it is actually loaded and in order for this to work, the
code needs to be 'position independent' ('pic' means 'position
independent code'). You'll need to link with a 'shared object' (.so)
version of the C libary (libm is part of that) instead. Possibly,
that's just a matter of changing the configuration of the linker/ of
passing suitable -L and -R flags so that it finds the .so-files before
the .a files. In case you don't already have a version of the C
library suitable for dynamic linking, you need to create one by
compiling a 'suitably configured' C libary from the sources. In the
latter case, ensure that you are not installing the new library
objects over the ones already used by the system (if applicable). If
you're lucky, doing otherwise might work, but if you're not, the
installation will be toast (no longer capable of executing any program
until a suitable C library version is again available).
------------------------------
Date: Mon, 31 Oct 2011 14:29:23 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: installation of PDL
Message-Id: <8739e9mdz0.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> "ela" <ela@yantai.org> writes:
>> /usr/bin/ld:
>> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a(s_sin.o):
>> relocation R_X86_64_32S against `a local symbol' can not be used when making
>> a shared object; recompile with -fPIC
>
> [...]
>
>> Google searches say -fPIC should be used but in CPAN I don't know how to do
>> that. Any suggestions?
>
> The problem is that you're trying to link a static version of the
> 'math' library (libm.a)
[...]
> You'll need to link with a 'shared object' (.so) version of the C
> libary (libm is part of that) instead.
The latter isn't quite true: It is also possible to use position
independent code residing in a static 'archive file'.
------------------------------
Date: Mon, 31 Oct 2011 22:42:43 +0800
From: "ela" <ela@yantai.org>
Subject: Re: installation of PDL
Message-Id: <j8mc4t$85p$1@ijustice.itsc.cuhk.edu.hk>
"Rainer Weikusat" <rweikusat@mssgmbh.com> wrote in message
news:877h3lmg2r.fsf@sapphire.mobileactivedefense.com...
> Possibly,
> that's just a matter of changing the configuration of the linker/ of
> passing suitable -L and -R flags so that it finds the .so-files before
> the .a files.
Thank you for explaining down to such a detail. Today I finally know what
.so means... How to change the configuration? Any reference is highly
welcomed.
------------------------------
Date: Mon, 31 Oct 2011 22:55:24 +0800
From: "ela" <ela@yantai.org>
Subject: Re: installation of PDL
Message-Id: <j8mcsm$8dp$1@ijustice.itsc.cuhk.edu.hk>
In fact, to install PDL is only for reusing a module developed by "andye"
http://www.perlmonks.org/?node=Statistics%3A%20Jarque-Bera%20normality%20test
and from his post, it seems that in Perl there is no normality test. If
there is an alternative, I may be able to skip installing PDL.
------------------------------
Date: Mon, 31 Oct 2011 10:19:57 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: installation of PDL
Message-Id: <_t6dnfvYQcUAITPTnZ2dnUVZ8iydnZ2d@bt.com>
Quoth "ela" <ela@yantai.org>:
> In CPAN, I used force install but failed.
>
> /usr/bin/ld:
> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a(s_sin.o):
> relocation R_X86_64_32S against `a local symbol' can not be used when making
> a shared object; recompile with -fPIC
> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a:
> could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[2]: *** [../../blib/arch/auto/PDL/Ops/Ops.so] Error 1
> make[2]: Leaving directory `/root/.cpan/build/PDL-2.4.9-gn4Jgf/Basic/Ops'
> make[1]: *** [subdirs] Error 2
> make[1]: Leaving directory `/root/.cpan/build/PDL-2.4.9-gn4Jgf/Basic'
> make: *** [subdirs] Error 2
> CHM/PDL-2.4.9.tar.gz
> /usr/bin/make -- NOT OK
> Running make test
> Can't test without successful make
> Running make install
> Make had returned bad status, install seems impossible
> Failed during this command:
> CHM/PDL-2.4.9.tar.gz : make NO
>
> Google searches say -fPIC should be used but in CPAN I don't know how to do
> that. Any suggestions?
You need a perl built to use -fPIC instead of -fpic for shared
libraries. Run
perl -V:cccdlflags
(that's three 'c's, not two); if you see '-DPIC -fPIC' rather than
'-DPIC -fpic' the pic/PIC issue is a red herring. (AFAICT perl has build
with PIC by default on Linux since 5.8.5, so unless RH've made a mess of
it *again* I'd be surprised if your is wrong.)
If your perl *is* using -fpic, you need to upgrade perl to a version
which uses -fPIC. You might possibly be able to avoid this by editing
Config.pm and Config_heavy.pl and doing s/-fpic/-fPIC/ across both
files, but that is always a little dodgy.
If, OTOH, your perl is already using -fPIC, Rainer is probably right
about your problem being trying to link in a static libm. Do you have a
libm.so? I really can't imagine you don't. You may need to post more of
the output of 'make': you've posted the error message, but not the
command that produces that message.
Ben
------------------------------
Date: Mon, 31 Oct 2011 15:51:11 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: installation of PDL
Message-Id: <87y5w1kvm8.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "ela" <ela@yantai.org>:
>> In CPAN, I used force install but failed.
>>
>> /usr/bin/ld:
>> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a(s_sin.o):
>> relocation R_X86_64_32S against `a local symbol' can not be used when making
>> a shared object; recompile with -fPIC
>> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a:
>> could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> make[2]: *** [../../blib/arch/auto/PDL/Ops/Ops.so] Error 1
>> make[2]: Leaving directory `/root/.cpan/build/PDL-2.4.9-gn4Jgf/Basic/Ops'
>> make[1]: *** [subdirs] Error 2
>> make[1]: Leaving directory `/root/.cpan/build/PDL-2.4.9-gn4Jgf/Basic'
>> make: *** [subdirs] Error 2
>> CHM/PDL-2.4.9.tar.gz
>> /usr/bin/make -- NOT OK
>> Running make test
>> Can't test without successful make
>> Running make install
>> Make had returned bad status, install seems impossible
>> Failed during this command:
>> CHM/PDL-2.4.9.tar.gz : make NO
>>
>> Google searches say -fPIC should be used but in CPAN I don't know how to do
>> that. Any suggestions?
>
> You need a perl built to use -fPIC instead of -fpic for shared
> libraries.
According to the gcc 4.4 documentation,
`-fPIC'
If supported for the target machine, emit position-independent
code, suitable for dynamic linking and avoiding any limit on the
size of the global offset table. This option makes a difference
on the m68k, PowerPC and SPARC.
[...]
> If, OTOH, your perl is already using -fPIC, Rainer is probably right
> about your problem being trying to link in a static libm.
On of the Perl extension modules I'm presently using is based on a
static library. When this library was compiled w/o -fpic (not
-fPIC), trying to link the Perl module results in the following error:
/usr/bin/ld: /usr/local/lib/libevracoon.a(evr_maps.o): relocation
R_X86_64_32S against `.rodata' can not be used when making a shared
object; recompile with -fPIC
/usr/local/lib/libevracoon.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
Compiling the code for this static library with -fpic causes the error
to go away.
------------------------------
Date: Mon, 31 Oct 2011 11:12:50 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: installation of PDL
Message-Id: <vZidnSbD4Z2fVDPTnZ2dnUVZ7q6dnZ2d@bt.com>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth "ela" <ela@yantai.org>:
> >>
> >> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/
> >> ../../../../lib64/libm.a(s_sin.o):
> >> relocation R_X86_64_32S against `a local symbol' can not be used
> >> when making a shared object; recompile with -fPIC
> >> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/
> >> ../../../../lib64/libm.a:
> >> could not read symbols: Bad value
> >> collect2: ld returned 1 exit status
<snip>
> >
> > You need a perl built to use -fPIC instead of -fpic for shared
> > libraries.
>
> According to the gcc 4.4 documentation,
>
> `-fPIC'
> If supported for the target machine, emit position-independent
> code, suitable for dynamic linking and avoiding any limit on the
> size of the global offset table. This option makes a difference
> on the m68k, PowerPC and SPARC.
Hmm, I think you might be right that this makes no difference on amd64.
I've seen issues in the past due to perl being built to use -fpic rather
than -fPIC, but perhaps they were on SPARC.
> > If, OTOH, your perl is already using -fPIC, Rainer is probably right
> > about your problem being trying to link in a static libm.
>
> On of the Perl extension modules I'm presently using is based on a
> static library. When this library was compiled w/o -fpic (not
> -fPIC), trying to link the Perl module results in the following error:
>
> /usr/bin/ld: /usr/local/lib/libevracoon.a(evr_maps.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a shared
> object; recompile with -fPIC
> /usr/local/lib/libevracoon.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
>
> Compiling the code for this static library with -fpic causes the error
> to go away.
Yup.
So the question then becomes: how on earth did the OP end up trying to
link against a static libm?
Ben
------------------------------
Date: Tue, 1 Nov 2011 00:48:12 +0800
From: "ela" <ela@yantai.org>
Subject: Re: installation of PDL
Message-Id: <j8mjg9$b19$1@ijustice.itsc.cuhk.edu.hk>
"Ben Morrow" <ben@morrow.me.uk> wrote in message
news:_t6dnfvYQcUAITPTnZ2dnUVZ8iydnZ2d@bt.com...
> You may need to post more of
> the output of 'make': you've posted the error message, but not the
> command that produces that message.
I used CPAN to install so the command is
cpan> install PDL or
cpan> force install PDL
Some of the other warnings are shown below:
Ops.xs:19761: warning: unused variable aa_physdatapa
Ops.xs:19805: warning: unused variable ab_physdatapa
Ops.xs:19802: warning: unused variable aa_physdatapa
Ops.xs:19846: warning: unused variable ab_physdatapa
Ops.xs:19843: warning: unused variable aa_physdatapa
Ops.xs:19588: warning: unused variable a__dima
Ops.xs: In function apdl_assgn_freea:
Ops.xs:19892: warning: unused variable a__dima
Ops.c: In function aXS_PDL_assgna:
Ops.xs:23159: warning: ab_SVa may be used uninitialized in this function
Ops.c: In function aXS_PDL_loga:
Ops.xs:23015: warning: ab_SVa may be used uninitialized in this function
Ops.c: In function aXS_PDL_expa:
Ops.xs:22912: warning: ab_SVa may be used uninitialized in this function
Ops.c: In function aXS_PDL_nota:
Ops.xs:22803: warning: ab_SVa may be used uninitialized in this function
Ops.c: In function aXS_PDL_cosa:
Ops.xs:22694: warning: ab_SVa may be used uninitialized in this function
Ops.c: In function aXS_PDL_sina:
Ops.xs:22585: warning: ab_SVa may be used uninitialized in this function
Ops.c: In function aXS_PDL_absa:
Ops.xs:22479: warning: ab_SVa may be used uninitialized in this function
Ops.c: In function aXS_PDL_sqrta:
------------------------------
Date: Mon, 31 Oct 2011 13:11:33 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: installation of PDL
Message-Id: <XYydnSbi9eRIeTPTnZ2dnUVZ8sCdnZ2d@bt.com>
Quoth "ela" <ela@yantai.org>:
>
> "Ben Morrow" <ben@morrow.me.uk> wrote in message
> news:_t6dnfvYQcUAITPTnZ2dnUVZ8iydnZ2d@bt.com...
> > You may need to post more of
> > the output of 'make': you've posted the error message, but not the
> > command that produces that message.
>
> I used CPAN to install so the command is
>
> cpan> install PDL or
> cpan> force install PDL
No; you posted an error message from ld. Just before that there will
have been a message from make telling you what ld command-line it was
using. That's what we need to see; though it's probably best if you redo
the build by hand. Start with
cpan> look PDL
which will drop you into an unpacked PDL build directory, then run
perl Makefile.PL
make
from there. Post all of the output of both commands (I realise it will
be long, since PDL is such a large distribution, but there we go).
It seems definitely worth mentioning, at this point, that trying to
install modules by hand (or using the CPAN shell) against a vendor-
provided perl is usually a bad idea. The system package manager often
gets quite upset when it finds modules installed which it didn't expect
to be there. If RH provide a RPM of PDL (and I'd be surprised if they
don't) you will probably be better off just installing that.
> Some of the other warnings are shown below:
>
> Ops.xs:19761: warning: unused variable aa_physdatapa
<snip>
> Ops.xs:23159: warning: ab_SVa may be used uninitialized in this function
<snip>
These sorts of warnings are quite common if you're using a newer version
of gcc than a module's developer. *Usually* they don't indicate anything
important is wrong, it's just gcc being excessively paranoid.
Ben
------------------------------
Date: Mon, 31 Oct 2011 15:43:53 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: installation of PDL
Message-Id: <9uk3o8xvr4.ln2@goaway.wombat.san-francisco.ca.us>
On 2011-10-31, Ben Morrow <ben@morrow.me.uk> wrote:
>
> It seems definitely worth mentioning, at this point, that trying to
> install modules by hand (or using the CPAN shell) against a vendor-
> provided perl is usually a bad idea. The system package manager often
> gets quite upset when it finds modules installed which it didn't expect
> to be there. If RH provide a RPM of PDL (and I'd be surprised if they
> don't) you will probably be better off just installing that.
PDL is, AFAICT, not available in stock RedHat, but is available from
rpmforge (and possibly other RHEL repositories as well).
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Mon, 31 Oct 2011 20:06:58 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: installation of PDL
Message-Id: <pPKdnd0tyNCv2zLTnZ2dnUVZ8hednZ2d@bt.com>
Quoth "ela" <ela@yantai.org>:
>
> "Ben Morrow" <ben@morrow.me.uk> wrote in message
> news:XYydnSbi9eRIeTPTnZ2dnUVZ8sCdnZ2d@bt.com...
>
> > which will drop you into an unpacked PDL build directory, then run
> >
> > perl Makefile.PL
> > make
> >
> > from there. Post all of the output of both commands (I realise it will
> > be long, since PDL is such a large distribution, but there we go).
>
> With your help, I'm able to fix one error by myself - installing module F77.
> Yet, this hasn't solved the problem. Now please let me post the long output
> from both commands.... I believe only the last few sentences are useful
> because it's talking something like linking library problem...
You're right, but it's always better to post too much output than too
little. If you start cutting things out when you don't know what's going
on you are likely to remove something important.
> >perl Makefile.PL
<snip. Good God, there's a lot of this, isn't there?>
> pdlapi.c: In function ¡®pdl_allocdata¡¯:
> pdlapi.c:86: warning: format ¡®%x¡¯ expects type ¡®unsigned int¡¯, but
> argument 3 has type ¡®struct pdl *¡¯
[Incidentally, unlike all the 'unused variable' nonsense, this indicates
a genuine bug on amd64. (unsigned int is 32 bits wide, pointers are 64,
so using printf "%x" for a pointer will corrupt the stack.) Let's hope
all the warnings come from debug code that never gets run in
production...]
<snip>
> rm -f ../../blib/arch/auto/PDL/Core/Core.so
> gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic Core.o pdlcore.o pdlapi.o
> pdlhash.o pdlthread.o pdlconv.o pdlmagic.o pdlsections.o -o
> ../../blib/arch/auto/PDL/Core/Core.so \
> -lpthread \
>
> chmod 755 ../../blib/arch/auto/PDL/Core/Core.so
So this .so link, without an explicit -lm, succeeds...
> rm -f ../../blib/arch/auto/PDL/Ops/Ops.so
> gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic Ops.o -o
> ../../blib/arch/auto/PDL/Ops/Ops.so \
> -lm \
>
> /usr/bin/ld:
> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a(s_sin.o):
> relocation R_X86_64_32S against `a local symbol' can not be used when making
> a shared object; recompile with -fPIC
> /base1/usr/bin/../lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libm.a:
> could not read symbols: Bad value
> collect2: ld returned 1 exit status
...but this one, with -lm, fails.
So: do you have an appropriate libm.so? I would expect it to be a
symlink to a libm.so.6 somewhere, which is in turn a symlink to a
libm.so with three numbers. By the looks of things it should be in
/base1/usr/lib64/libm.so, but I'm not sure how Linux does mixed
64/32-bit library directories (and I've no idea where that /base1 came
from).
Maybe poke around in (/usr)?/lib(32|64)? and see what you can find, or
maybe ask locate(1). By the looks of things you will need a 64-bit
library: you can use file -L to see whether a lib is 32- or 64-bit.
If you haven't got a libm.so, ought you to have? Can you ask RPM if your
glibc installation has somehow become corrupted? On my system, perl
itself links libm dynamically; if I run
ldd /usr/bin/perl
the output includes
libm.so.5 => /lib/libm.so.5 (0x800891000)
Is your perl the same? If so, how is your system managing to run perl at
all? (You
Ben
------------------------------
Date: Mon, 31 Oct 2011 14:41:57 +0100
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Subject: PERL_SYS_INIT()
Message-Id: <hbf.20111031mq35@bombur.uio.no>
Is PERL_SYS_INIT() as portable as PERL_SYS_INIT3()? It is not
documented in the manpages. I'm wondering if I should use that or
pass a pointer to the possibly less portable extern char **environ;
since proto.h says __attribute__nonnull__ for env.
I'm looking at a program doing roughly
char *embedding[] = { "", "-e", "0" }, **argv = embedding;
int argc = 3;
PERL_SYS_INIT3(&argc, &argv, (char ***)NULL);
...
perl_parse(my_perl, xs_init, 3, argv, NULL);
Can PERL_SYS_INIT(,&argv) change argv? If so, how, and should
the remaining program pass the unchanged 'embedding' or the
changed 'argv' to perl_parse()? man perlembed shows both variants.
--
Hallvard
------------------------------
Date: Mon, 31 Oct 2011 10:46:16 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: PERL_SYS_INIT()
Message-Id: <EqmdnbNX97xVXzPTnZ2dnUVZ7rSdnZ2d@bt.com>
Quoth Hallvard B Furuseth <h.b.furuseth@usit.uio.no>:
> Is PERL_SYS_INIT() as portable as PERL_SYS_INIT3()? It is not
> documented in the manpages. I'm wondering if I should use that or
> pass a pointer to the possibly less portable extern char **environ;
> since proto.h says __attribute__nonnull__ for env.
AFAICT they are only different on OS/2, but _INIT3 was introduced in
5.6, so you should probably use it anyway. (They probably *ought* to be
different at least on Win32, as well, since the Win32 init code affects
the environment, but currently they aren't.)
> I'm looking at a program doing roughly
>
> char *embedding[] = { "", "-e", "0" }, **argv = embedding;
> int argc = 3;
> PERL_SYS_INIT3(&argc, &argv, (char ***)NULL);
> ...
> perl_parse(my_perl, xs_init, 3, argv, NULL);
>
> Can PERL_SYS_INIT(,&argv) change argv? If so, how, and should
> the remaining program pass the unchanged 'embedding' or the
> changed 'argv' to perl_parse()? man perlembed shows both variants.
Perl embedding is not very well tested. There are some notable cases
that work well, like mod_perl, but they all end up knowing more about
the perl guts than is documented in perlembed. About the only way to be
safe is to look at perlmain.c and do what that does, though even that
isn't always possible since it uses symbols that aren't exported on all
platforms. From my experiments with it all I can recommend is to try
things until you find something that works, and to expect to have to make
minor fixes if you upgrade to a new major version of perl.
That said, I believe the correct answer is you should pass the real
environment to _INIT3 (whether from the third arg of main or from the
global environ), and you should pass the argv pointer you passed to
_INIT3 to perl_parse. On some systems (VMS, OS/2) _INIT3 will modify the
passed-in argv; on some systems (Win32, at least) it will modify the
global environment and assume this will affect what perl_parse sees
(ignoring the env pointer passed to _INIT3).
Ben
------------------------------
Date: Mon, 31 Oct 2011 19:34:37 +0100
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Subject: Re: PERL_SYS_INIT()
Message-Id: <hbf.20111031rzrs@bombur.uio.no>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Hallvard B Furuseth <h.b.furuseth@usit.uio.no>:
>> Is PERL_SYS_INIT() as portable as PERL_SYS_INIT3()? It is not
>> documented in the manpages. I'm wondering if I should use that or
>> pass a pointer to the possibly less portable extern char **environ;
>> since proto.h says __attribute__nonnull__ for env.
>
> AFAICT they are only different on OS/2, but _INIT3 was introduced in
> 5.6, so you should probably use it anyway. (They probably *ought* to be
> different at least on Win32, as well, since the Win32 init code affects
> the environment, but currently they aren't.)
Sounds like it's safest to use INIT when available and INIT3 otherwise,
then. That leaves as much as possible of the work to Perl.
> (...) From my experiments with it all I can recommend is to try
> things until you find something that works, and to expect to have to
> make minor fixes if you upgrade to a new major version of perl.
>
> That said, I believe the correct answer is you should pass the real
> environment to _INIT3 (whether from the third arg of main or from the
> global environ), and you should pass the argv pointer you passed to
> _INIT3 to perl_parse. On some systems (VMS, OS/2) _INIT3 will modify the
> passed-in argv; on some systems (Win32, at least) it will modify the
> global environment and assume this will affect what perl_parse sees
> (ignoring the env pointer passed to _INIT3).
Yuck. I'm fixing some apparently untested code, and I won't be testing
my fix either on any of those systems:-( I'll try this for now, for the
application's set-up code:
char *embedding[] = { "", "-e", "0", NULL }; /*added NULL just in case*/
char **argv = embedding, **env = NULL;
int argc = 3;
#ifdef PERL_SYS_INIT
PERL_SYS_INIT(&argc, &argv);
#elif defined PERL_SYS_INIT3
env = environ;
PERL_SYS_INIT3(&argc, &argv, &env);
#endif
my_perl = perl_alloc();
perl_construct(my_perl);
#ifdef PERL_EXIT_DESTRUCT_END
PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
#endif
perl_parse(my_perl, my_xs_init, argc, argv, env);
perl_run(my_perl);
--
Hallvard
------------------------------
Date: Mon, 31 Oct 2011 17:26:10 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: PERL_SYS_INIT()
Message-Id: <K9qdnY9HVMIfvTLTnZ2dnUVZ8nWdnZ2d@bt.com>
Quoth Hallvard B Furuseth <h.b.furuseth@usit.uio.no>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > Quoth Hallvard B Furuseth <h.b.furuseth@usit.uio.no>:
> >> Is PERL_SYS_INIT() as portable as PERL_SYS_INIT3()? It is not
> >> documented in the manpages. I'm wondering if I should use that or
> >> pass a pointer to the possibly less portable extern char **environ;
> >> since proto.h says __attribute__nonnull__ for env.
> >
> > AFAICT they are only different on OS/2, but _INIT3 was introduced in
> > 5.6, so you should probably use it anyway. (They probably *ought* to be
> > different at least on Win32, as well, since the Win32 init code affects
> > the environment, but currently they aren't.)
>
> Sounds like it's safest to use INIT when available and INIT3 otherwise,
> then. That leaves as much as possible of the work to Perl.
_INIT is always available (at least, in all versions of perl which
support embedding).
> Yuck. I'm fixing some apparently untested code, and I won't be testing
> my fix either on any of those systems:-( I'll try this for now, for the
> application's set-up code:
<snip>
Looks sane to me.
Ben
------------------------------
Date: Tue, 01 Nov 2011 00:31:26 +0100
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Subject: Re: PERL_SYS_INIT()
Message-Id: <hbf.20111101xc5k@bombur.uio.no>
Ben Morrow writes:
> Quoth Hallvard B Furuseth <h.b.furuseth@usit.uio.no>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>> Quoth Hallvard B Furuseth <h.b.furuseth@usit.uio.no>:
>>>> Is PERL_SYS_INIT() as portable as PERL_SYS_INIT3()? (...)
>>>
>>> AFAICT they are only different on OS/2, but _INIT3 was introduced in
>>> 5.6, so you should probably use it anyway. (...)
>>
>> Sounds like it's safest to use INIT when available and INIT3 otherwise,
>> then. That leaves as much as possible of the work to Perl.
>
> _INIT is always available (at least, in all versions of perl which
> support embedding). (...)
I'll stick to INIT and drop INIT3 and env then, that'll equivalent to my
posted code. I misunderstood - I thought you meant INIT3 was introduced
earlier, not later.
Thank you for your help.
--
Hallvard
------------------------------
Date: Sun, 30 Oct 2011 18:06:36 +0800
From: "ela" <ela@yantai.org>
Subject: Re: using module
Message-Id: <j8j7j9$3sq$1@ijustice.itsc.cuhk.edu.hk>
Dear Tad McClellan,
Posting codes definitely represents the most clearestly. However, when the
modules have copyright issues, the problem becomes more complex as that
means I have to extract the content carefully, which is not always easy -
and that also explains why I cannot always post the codes in my post.
Sometimes I just need a better explanation about a concept. In this case, I
go to check out Perl bibles, Perl 21 days, Perl beginners, etc, and then
surf the web, but the resources just put the concept so complexly. Rainer
Weikusat indeed solves my problem.
I don't want to challenge the rules of this newsgroup and therefore I'd
appreciate your advice when my problem is like this one.
Best regards,
Ela
------------------------------
Date: Sun, 30 Oct 2011 13:43:05 -0400
From: Jon Du Kim <jondk@FAKE.EMAIL.net>
Subject: Re: using module
Message-Id: <d93ff$4ead8ca9$ad30ae40$7611@news.eurofeeds.com>
Oh, yes, the frequently posted but never read "Posting Guidelines".
Keep attacking those windmills!
On 10/28/11 8:49 AM, Tad McClellan wrote:
> Have you seen the Posting Guidelines that are posted here frequently?
------------------------------
Date: Sun, 30 Oct 2011 18:31:25 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: using module
Message-Id: <U9edneMdJdSdBTDTnZ2dnUVZ8hadnZ2d@giganews.com>
On 30/10/11 17:43, Jon Du Kim wrote:
> Oh, yes, the frequently posted but never read "Posting Guidelines".
Repeat after me: "Do Not Feed The Troll".
--
Henry Law Manchester, England
------------------------------
Date: Mon, 31 Oct 2011 19:40:59 -0400
From: Jon Du Kim <jondk@FAKE.EMAIL.net>
Subject: Re: using module
Message-Id: <e352f$4eaf320c$ad30ae40$12445@news.eurofeeds.com>
I'm sorry. I couldn't help but respond to the guidelines troll.
I'll do better in the future.
On 10/30/11 2:31 PM, Henry Law wrote:
> On 30/10/11 17:43, Jon Du Kim wrote:
>> Oh, yes, the frequently posted but never read "Posting Guidelines".
>
> Repeat after me: "Do Not Feed The Troll".
>
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3533
***************************************
