Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 29899
Status: resolved
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: duncan_j_ferguson [...] yahoo.co.uk
rhythmic01 [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.2808
Fixed in: (no value)



Subject: Solaris build error: Can't locate the perl binary used to run this script
Attempting to build the module fails on Solaris 10 using perlgcc. perlgcc is a wrapper around perl to amend the Config module (since perl was built with cc but I am using gcc to compile with). $ uname -a SunOS dev17 5.10 Generic_118855-33 i86pc i386 i86pc $ which perlgcc /usr/perl5/bin/perlgcc $ ls -la /usr/perl5/5.8.4/bin/perlgcc -r-xr-xr-x 1 root bin 651 Jan 21 2005 /usr/perl5/5.8.4/bin/perlgcc $ perlgcc Makefile.PL # running Build.PL Can't locate the perl binary used to run this script in (/usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin /usr/perl5/bin /usr/local/bin /usr/bin . /usr/sfw/bin /opt/sfw/bin /opt/sfw/sbin /usr/ccs/bin /usr/local/mysql/bin) $ perlgcc -V Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=solaris, osvers=2.10, archname=i86pc-solaris-64int uname='sunos localhost 5.10 i86pc i386 i86pc' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO', optimize='-O2 -fno-strict-aliasing', cppflags='' ccversion='GNU gcc', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags ='' libpth=/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R /usr/perl5/5.8.4/lib/i86pc-solaris-64int/CORE' cccdlflags='-fPIC', lddlflags='-G' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_LARGE_FILES Locally applied patches: 22667 The optree builder was looping when constructing the ops ... 22715 Upgrade to FileCache 1.04 22733 Missing copyright in the README. 22746 fix a coredump caused by rv2gv not fully converting a PV ... 22755 Fix 29149 - another UTF8 cache bug hit by substr. 22774 [perl #28938] split could leave an array without ... 22775 [perl #29127] scalar delete of empty slice returned garbage 22776 [perl #28986] perl -e "open m" crashes Perl 22777 add test for change #22776 ("open m" crashes Perl) 22778 add test for change #22746 ([perl #29102] Crash on assign ... 22781 [perl #29340] Bizarre copy of ARRAY make sure a pad op's ... 22796 [perl #29346] Double warning for int(undef) and abs(undef) ... 22818 BOM-marked and (BOMless) UTF-16 scripts not working 22823 [perl #29581] glob() misses a lot of matches 22827 Smoke [5.9.2] 22818 FAIL(F) MSWin32 WinXP/.Net SP1 (x86/1 cpu) 22830 [perl #29637] Thread creation time is hypersensitive 22831 improve hashing algorithm for ptr tables in perl_clone: ... 22839 [perl #29790] Optimization busted: '@a = "b", sort @a' ... 22850 [PATCH] 'perl -v' fails if local_patches contains code snippets 22852 TEST needs to ignore SCM files 22886 Pod::Find should ignore SCM files and dirs 22888 Remove redundant %SIG assignments from FileCache 23006 [perl #30509] use encoding and "eq" cause memory leak 23074 Segfault using HTML::Entities 23106 Numeric comparison operators mustn't compare addresses of ... 23320 [perl #30066] Memory leak in nested shared data structures ... 23321 [perl #31459] Bug in read() SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 Built under solaris Compiled at Feb 9 2006 06:26:23 %ENV: PERL="/usr/perl5/bin/perlgcc" PERL5LIB="/usr/perl5/5.8.4/lib/Sun/Solaris/PerlGcc:/usr/local/nagios/perl/lib:/usr/local/rrdtool-1.2.19/lib/perl/5.8.7/i86pc-solaris/" PERL5_OVERRIDE_CONFIG="1" @INC: /usr/perl5/5.8.4/lib/Sun/Solaris/PerlGcc /usr/local/nagios/perl/lib/i86pc-solaris-64int /usr/local/nagios/perl/lib /usr/local/rrdtool-1.2.19/lib/perl/5.8.7/i86pc-solaris/ /usr/perl5/5.8.4/lib/i86pc-solaris-64int /usr/perl5/5.8.4/lib /usr/perl5/site_perl/5.8.4/i86pc-solaris-64int /usr/perl5/site_perl/5.8.4 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.8.4/i86pc-solaris-64int /usr/perl5/vendor_perl/5.8.4 /usr/perl5/vendor_perl .
What is `perlgcc -le 'print $^X'` in this case?
From: duncan_j_ferguson [...] yahoo.co.uk
On Wed Oct 10 12:58:25 2007, EWILHELM wrote: Show quoted text
> What is `perlgcc -le 'print $^X'` in this case?
$ perlgcc -le 'print $^X' /usr/perl5/5.8.4/bin/perl
On Wed Oct 10 13:37:22 2007, duncs wrote: Show quoted text
> On Wed Oct 10 12:58:25 2007, EWILHELM wrote:
> > What is `perlgcc -le 'print $^X'` in this case?
> > $ perlgcc -le 'print $^X' > /usr/perl5/5.8.4/bin/perl
Thanks Duncan, I don't have a good answer for that. If the wrapper is changing the config, then we'll see a different one when we run $^X (which is likely to break the build process.) Is this typical of solaris? (If so, I would rather they do it differently (I don't know of any precedent for using $ENV{PERL}.)) We could try to support this usage in Module::Build, but I'm afraid we'll miss something propagating it to a subprocess (and any random test or other setup code from CPAN might get it wrong too.) I think a better approach would be to set PERL5OPT (e.g. to -MConfigGCC and have ConfigGCC.pm take care of things), which is a supported and documented perl feature that will always propagate to subprocesses (except taint, but we don't build under taint.) With that, I'm thinking this is not a bug. If the PERL5OPT thing doesn't work, let's reopen it as a wishlist item. Thanks, Eric
Subject: Re: [rt.cpan.org #29899] Solaris: Can't locate the perlgcc binary used to run this script
Date: Wed, 10 Oct 2007 16:17:52 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Duncan Ferguson via RT wrote: Show quoted text
> Queue: Module-Build > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=29899 > > > On Wed Oct 10 12:58:25 2007, EWILHELM wrote:
>> What is `perlgcc -le 'print $^X'` in this case?
> > $ perlgcc -le 'print $^X' > /usr/perl5/5.8.4/bin/perl
Does that file exist? -- Stabbing you in the face for your own good.
On Wed Oct 10 13:59:29 2007, EWILHELM wrote: Show quoted text
> > I don't have a good answer for that. If the wrapper is changing the > config, then we'll see a different one when we run $^X (which is > likely to break the build process.) Is this typical of solaris? (If > so, I would rather they do it differently (I don't know of any > precedent for using $ENV{PERL}.))
When _perl_is_same() returns false, the two most common reasons are locale problems (the config text gets messed up) or that they're not really the same. To make sure I'm following properly, are /usr/perl5/5.8.4/bin/perl and /usr/perl5/bin/perlgcc the same perl? Symlinks or something? If so, can you verify that their Config->myconfig() output is the same as each other? -Ken
From: duncan_j_ferguson [...] yahoo.co.uk
On Wed Oct 10 19:18:44 2007, schwern@pobox.com wrote: Show quoted text
> Duncan Ferguson via RT wrote:
> > Queue: Module-Build > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=29899 > > > > > On Wed Oct 10 12:58:25 2007, EWILHELM wrote:
> >> What is `perlgcc -le 'print $^X'` in this case?
> > > > $ perlgcc -le 'print $^X' > > /usr/perl5/5.8.4/bin/perl
> > Does that file exist?
$ ls -la /usr/perl5/5.8.4/bin/perl -r-xr-xr-x 2 root bin 10348 Jan 23 2005 /usr/perl5/5.8.4/bin/perl $ file /usr/perl5/5.8.4/bin/perl /usr/perl5/5.8.4/bin/perl: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped
From: duncan_j_ferguson [...] yahoo.co.uk
On Wed Oct 10 20:58:24 2007, KWILLIAMS wrote: Show quoted text
> To make sure I'm following properly, are /usr/perl5/5.8.4/bin/perl and > /usr/perl5/bin/perlgcc the same perl? Symlinks or something? If so, > can you verify that > their Config->myconfig() output is the same as each other?
perlgcc is a small wrapper script that adds in a new directory to @INC containing a different Config.pm - the wrapper script is attached. This is because the Sun provided perl is compiled with cc (which isnt supplied by default) but i have gcc on my system (which is); modules won't compile as they try to use the same setup as perl does. The replacement config changes all the necessary vars to allow gcc to be used instead of cc. ExtUtils::MakeMaker modules can be successfully compiled and installed when using perlgcc to build them (the only time perlgcc is really required is for building modules). This becomes more of an issue when using CPAN to install modules, when dependencies use a mixture of both Module::Build and ExtUtils::MakeMaker as one set need perlgcc, and the other cannot use it. $ perl -MConfig -e 'print "$_=$Config{$_}\n" foreach(sort(keys(%Config)))' > perl.config $ perlgcc -MConfig -e 'print "$_=$Config{$_}\n" foreach(sort(keys(%Config)))' > perlgcc.config $ diff perl.config perlgcc.config 52,53c52,53 < cc=cc < cccdlflags=-KPIC --- Show quoted text
> cc=gcc > cccdlflags=-fPIC
56d55 < ccflags=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO 58,60c57,59 < ccname=cc < ccsymbols= < ccversion=Sun WorkShop --- Show quoted text
> ccname=gcc > ccsymbols=__i386=1 __i386__=1 __sun=1 __sun__=1 __SVR4=1 __svr4__=1
__unix=1 __unix__=1 cpu=i386 machine=i386 system=svr4 Show quoted text
> ccversion=GNU gcc
79c78 < cppccsymbols= --- Show quoted text
> cppccsymbols=i386=1 sun=1 unix=1
83,85c82,84 < cpprun=cc -E < cppstdin=cc -E < cppsymbols=_FILE_OFFSET_BITS=64 i386=1 __i386=1 _ILP32=1 _LARGEFILE64_SOURCE=1 _LARGEFILE_SOURCE=1 _LITTLE_ENDIAN=1 __STDC__=1 sun=1 __sun=1 __SVR4=1 unix=1 __unix=1 --- Show quoted text
> cpprun=gcc -E > cppstdin=gcc -E > cppsymbols=_FILE_OFFSET_BITS=64 __i386=1 __i386__=1 _ILP32=1
_LARGEFILE64_SOURCE=1 _LARGEFILE_SOURCE=1 _LITTLE_ENDIAN=1 __STDC__=1 __sun=1 __sun__=1 __SVR4=1 __svr4__=1 __unix=1 __unix__=1 114c113 < d_attribut= --- Show quoted text
> d_attribut=define
627c626 < i_sunmath=define --- Show quoted text
> i_sunmath=
706c705 < ld=cc --- Show quoted text
> ld=gcc
730c729 < loclibpth=/usr/sfw/lib /opt/sfw/lib /usr/lib /usr/ccs/lib /usr/local/lib /opt/local/lib /usr/gnu/lib /opt/gnu/lib /usr/GNU/lib /opt/GNU/lib --- Show quoted text
> loclibpth=/usr/sfw/lib /opt/sfw/lib /usr/local/lib /opt/local/lib
/usr/gnu/lib /opt/gnu/lib /usr/GNU/lib /opt/GNU/lib 787c786 < optimize=-xO3 -xspace -xildoff --- Show quoted text
> optimize=-O2 -fno-strict-aliasing
or, to put it another way $ perl -MConfig -e 'print Config->myconfig(),$/' > perl.myconfig $ perlgcc -MConfig -e 'print Config->myconfig(),$/' > perlgcc.myconfig $ diff perl.myconfig perlgcc.myconfig 12,13c12,13 < cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO', < optimize='-xO3 -xspace -xildoff', --- Show quoted text
> cc='gcc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TS_ERRNO', Show quoted text
> optimize='-O2 -fno-strict-aliasing',
15c15 < ccversion='Sun WorkShop', gccversion='', gccosandvers='' --- Show quoted text
> ccversion='GNU gcc', gccversion='', gccosandvers=''
21c21 < ld='cc', ldflags ='' --- Show quoted text
> ld='gcc', ldflags =''
29c29 < cccdlflags='-KPIC', lddlflags='-G' --- Show quoted text
> cccdlflags='-fPIC', lddlflags='-G'
Download perlgcc
application/octet-stream 651b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #29899] Solaris: Can't locate the perlgcc binary used to run this script
Date: Thu, 11 Oct 2007 01:48:03 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <scratchcomputing [...] gmail.com>
# from Duncan Ferguson via RT # on Thursday 11 October 2007 01:19: Show quoted text
>perlgcc is a small wrapper script that adds in a new directory to @INC >containing a different Config.pm - the wrapper script is attached.
I think that reduces to: PERL5OPT="-I/usr/perl5/5.8.4/lib/Sun/Solaris/PerlGcc" I'm not seeing why the PERL5LIB isn't affecting _perl_is_same() though. Show quoted text
>This becomes more of an issue when using CPAN to install modules, when >dependencies use a mixture of both Module::Build and >ExtUtils::MakeMaker as one set need perlgcc, and the other cannot use >it.
Are you saying "cannot use it" because of this issue or is that a deeper issue involving the compiler? Which set needs which? I notice that you're running Makefile.PL in the Module::Build distribution. Does running Build.PL give different results? --Eric
From: duncan_j_ferguson [...] yahoo.co.uk
On Thu Oct 11 04:53:08 2007, scratchcomputing@gmail.com wrote: Show quoted text
> >This becomes more of an issue when using CPAN to install modules, when > >dependencies use a mixture of both Module::Build and > >ExtUtils::MakeMaker as one set need perlgcc, and the other cannot use > >it.
> > Are you saying "cannot use it" because of this issue or is that a deeper > issue involving the compiler? Which set needs which?
When using CPAN to install modules, $ perl -MCPAN -e 'shell' ExtUtils::MakerMaker modules fail to build, but Module::Build is ok $ perlgcc -MCPAN -e 'shell' then Module::Build fails, but ExtUtils::MakeMaker modules are ok This is a problem when dependencies of a module i am building use both schemes. Show quoted text
> I notice that you're running Makefile.PL in the Module::Build > distribution. Does running Build.PL give different results?
I was copying what my version of CPAN does. However, $ pwd /../../../Module-Build-0.2808 $ perlgcc Build.PL Checking whether your kit is complete... Looks good .... $ ./Build Can't locate the perl binary used to run this script in (/usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin /usr/perl5/bin /usr/local/bin /usr/bin . /usr/sfw/bin /opt/sfw/bin /opt/sfw/sbin /usr/ccs/bin /usr/local/mysql/bin /usr/local/nagios/bin /usr/local/nagios/perl/bin) Using perl instead of perlgcc and everything works as expected
From: duncan_j_ferguson [...] yahoo.co.uk
On Thu Oct 11 04:53:08 2007, scratchcomputing@gmail.com wrote: Show quoted text
> # from Duncan Ferguson via RT > # on Thursday 11 October 2007 01:19: >
> >perlgcc is a small wrapper script that adds in a new directory to @INC > >containing a different Config.pm - the wrapper script is attached.
> > I think that reduces to: > > PERL5OPT="-I/usr/perl5/5.8.4/lib/Sun/Solaris/PerlGcc" > > I'm not seeing why the PERL5LIB isn't affecting _perl_is_same() though.
Using perl and not perlgcc with the above env var certainly seems to be working on both types of module. Getting the following warnings, but I'll see how it goes after the installs have finished (tests do seem to be passing ok) ==== Checking if your kit is complete... Looks good Have /usr/perl5/5.8.4/lib/Sun/Solaris/PerlGcc/Config.pm expected /usr/perl5/5.8.4/lib/i86pc-solaris-64int/Config.pm Your perl and your Config.pm seem to have different ideas about the architecture they are running on. Perl thinks: [PerlGcc] Config says: [i86pc-solaris-64int] This may or may not cause problems. Please check your installation of perl if you have problems building this extension. Writing Makefile for .... ====
Subject: Re: [rt.cpan.org #29899] Solaris: Can't locate the perlgcc binary used to run this script
Date: Thu, 11 Oct 2007 17:33:37 -0500
To: bug-Module-Build [...] rt.cpan.org
From: "Ken Williams" <kenahoo [...] gmail.com>
On 10/11/07, Duncan Ferguson via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> $ pwd > /../../../Module-Build-0.2808 > $ perlgcc Build.PL > Checking whether your kit is complete... > Looks good > .... > $ ./Build > Can't locate the perl binary used to run this script in > (/usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin > /usr/perl5/bin /usr/local/bin /usr/bin . /usr/sfw/bin /opt/sfw/bin > /opt/sfw/sbin /usr/ccs/bin /usr/local/mysql/bin /usr/local/nagios/bin > /usr/local/nagios/perl/bin)
What if instead of "./Build" you do "perlgcc ./Build"? Some platforms have shebang-line problems where $^X doesn't get set correctly by the kernel and/or perl. -Ken
Subject: Re: [rt.cpan.org #29899] Solaris: Can't locate the perlgcc binary used to run this script
Date: Thu, 11 Oct 2007 16:28:45 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <scratchcomputing [...] gmail.com>
# from Ken Williams via RT # on Thursday 11 October 2007 15:38: Show quoted text
>On 10/11/07, Duncan Ferguson wrote:
>> $ perlgcc Build.PL >> Checking whether your kit is complete... >> Looks good >> .... >> $ ./Build >> Can't locate the perl binary used to run this script in >> (/usr/perl5/5.8.4/bin ...
> >What if instead of "./Build" you do "perlgcc ./Build"? Some platforms >have shebang-line problems where $^X doesn't get set correctly by the >kernel and/or perl.
Ah. You've made a situation where PERL5LIB is changing between Build.PL and ./Build. To replicate this on a linux system (or osx via slight adjustment to the first line below) # mkdir /tmp/fake && perl -pe 's/(osname.*)linux/$1LiNux/' < \ $(perl -MConfig -e 'print $INC{"Config.pm"}') > /tmp/fake/Config.pm # cd /tmp && module-starter Foo && cd Foo # PERL5LIB="/tmp/fake:$PERL5LIB" perl Build.PL ... (business as usual) ... # ./Build Can't locate the perl binary used to run this script in (/usr/bin ...) Because the perl binary (not 'perlgcc') is $^X in Build.PL, that's what you're going to get for a shebang in ./Build. Thus, exporting PERL5LIB or PERL5OPT would work, but the wrapper script won't (unless it sets $^X, but my hunch says it is better to avoid that.) I'm still don't think this should be considered a bug. Do we want to try to DWIM in the face of a changing PERL5LIB (or any other env var for that matter?) What if paths were added or removed? What if the change was intentional? Seems like it makes too many cases where the magic behind the curtain could empuzzle the user. Hmm, we are restoring @INC in the ./Build script -- but we're not propagating that to the `perl` command in _perl_is_same(). If you stick 'warn $INC{"Config.pm"}' on the end of that @cmd, you'll see this. Thus, I think we actually need to be removing some DWIM rather than adding it (and I think this issue illustrates that.) (Note: the ./Build process is seeing "/tmp/fake/Config.pm", but _perl_is_same() is seeing the stock config. You can observe this by adding the following line just after 'use Module::Build' in the ./Build script (and modifying @cmd in _perl_is_same() of Base.pm) BEGIN {warn "inc ", $INC{'Config.pm'}}; ) --Eric
Sounds like this is solved by $PERL5OPT. The question of whether we're "doing the right thing" with @INC and $PERL5LIB has been moved to ticket #31566.
OS: Solaris 10.

Show quoted text
# /usr/perl5/bin/perlgcc Makefile.PL
# running Build.PL
Creating new 'MYMETA.yml' with configuration results
Creating new 'Build' script for 'Module-Build' version '0.3601'

Show quoted text
# /usr/sfw/bin/gmake
/usr/perl5/5.8.4/bin/perl Build --makefile_env_macros 1
Can't locate the perl binary used to run this script in (/usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin /usr/perl5/5.8.4/bin /usr/sbin /usr/bin /usr/openwin/bin /usr/ucb /usr/local/bin /usr/ccs/lib /usr/include /opt/apache-ant-1.7.1/bin)
gmake: *** [all] Error 2


My environment has the following settings:
#echo $LC_ALL
C

Kindly help me.

Regards,
Rathna
I do have my perl binaries at the location /usr/perl5/5.8.4/bin

/usr/perl5/5.8.4/bin:# ls
a2p          enc2xs       perl5.8.4    pl2pm        podchecker   s2p
c2ph         find2perl    perlbug      pod2html     podselect    shasum
cpan         h2ph         perlcc       pod2latex    prove        splain
dbilogstrip  h2xs         perldoc      pod2man      psed         tpage
dbiprof      instmodsh    perlgcc      pod2readme   pstruct      ttree
dbiproxy     libnetcfg    perlivp      pod2text     ptar         xsubpp
dprofpp      perl         piconv       pod2usage    ptardiff




On Mon Dec 28 14:06:18 2009, rathna wrote: Show quoted text
> # /usr/perl5/bin/perlgcc Makefile.PL
Please try the Build.PL interface. This appears to be the same as https://rt.cpan.org/Ticket/Display.html?id=29899 -- please see if the information there solves your problem. Thanks, Eric