search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.99k stars 559 forks source link

ExtUtils-ParseXS installs xsubpp twice #12873

Closed p5pRT closed 11 years ago

p5pRT commented 11 years ago

Migrated from rt.perl.org#117289 (status was 'resolved')

Searchable as RT117289$

p5pRT commented 11 years ago

From @ppisar

This is a bug report for perl from ppisar@​redhat.com\, generated with the help of perlbug 1.39 running under perl 5.16.2.

ExtUtils-ParseXS-3.18 installs xsubpp script twice​:

$ make pure_install DESTDIR=/tmp/ExtUtils-ParseXS-3.18-dest [...] $ find /tmp/ExtUtils-ParseXS-3.18-dest -name xsubpp /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/share/perl5/ExtUtils/xsubpp /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/bin/xsubpp

$ diff -u /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/bin/xsubpp /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/share/perl5/ExtUtils/xsubpp

Inline Patch ```diff --- /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/bin/xsubpp 2013-03-22 13:13:08.000000000 +0100 +++ /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/share/perl5/ExtUtils/xsubpp 2011-12-02 08:07:25.000000000 +0100 @@ -1,7 +1,4 @@ -#!/usr/bin/perl - -eval 'exec /usr/bin/perl -S $0 ${1+"$@"}' - if 0; # not running under some shell +#!perl use 5.006; use strict; eval { ```

Please stop installing xsubpp into @INC path.

-- Petr

Flags​:   category=library   severity=low   module=ExtUtils​::ParseXS

Site configuration information for perl 5.16.2​:

Configured by Red Hat\, Inc. at Tue Mar 5 13​:00​:19 UTC 2013.

Summary of my perl5 (revision 5 version 16 subversion 2) configuration​:  
  Platform​:   osname=linux\, osvers=2.6.32-279.19.1.el6.x86_64\, archname=x86_64-linux-thread-multi   uname='linux buildvm-26.phx2.fedoraproject.org 2.6.32-279.19.1.el6.x86_64 #1 smp sat nov 24 14​:35​:28 est 2012 x86_64 x86_64 x86_64 gnulinux '   config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp\,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Dccdlflags=-Wl\,--enable-new-dtags -Dlddlflags=-shared -O2 -g -pipe -Wall -Wp\,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl\,-z\,relro -DDEBUGGING=-g -Dversion=5.16.2 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat\, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbin! perl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize'   hint=recommended\, useposix=true\, d_sigaction=define   useithreads=define\, usemultiplicity=define   useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef   use64bitint=define\, use64bitall=define\, uselongdouble=undef   usemymalloc=n\, bincompat5005=undef   Compiler​:   cc='gcc'\, ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\,   optimize='-O2 -g -pipe -Wall -Wp\,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'\,   cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'   ccversion=''\, gccversion='4.7.2 20121109 (Red Hat 4.7.2-8)'\, gccosandvers=''   intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678   d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16   ivtype='long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8   alignbytes=8\, prototype=define   Linker and Libraries​:   ld='gcc'\, ldflags =' -fstack-protector'   libpth=/usr/local/lib64 /lib64 /usr/lib64   libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat   perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc   libc=\, so=so\, useshrplib=true\, libperl=libperl.so   gnulibc_version='2.16'   Dynamic Linking​:   dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,--enable-new-dtags -Wl\,-rpath\,/usr/lib64/perl5/CORE'   cccdlflags='-fPIC'\, lddlflags='-shared -O2 -g -pipe -Wall -Wp\,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl\,-z\,relro '

Locally applied patches​:  

@​INC for perl 5.16.2​:   /usr/local/lib64/perl5   /usr/local/share/perl5   /usr/lib64/perl5/vendor_perl   /usr/share/perl5/vendor_perl   /usr/lib64/perl5   /usr/share/perl5   .

Environment for perl 5.16.2​:   HOME=/home/petr   LANG=cs_CZ.UTF-8   LANGUAGE (unset)   LD_LIBRARY_PATH (unset)   LOGDIR (unset)   PATH=/home/petr/bin​:/usr/lib64/qt-3.3/bin​:/usr/lib64/icecc/bin​:/usr/local/bin​:/bin​:/usr/bin​:/usr/local/sbin​:/usr/sbin   PERL_BADLANG (unset)   SHELL=/bin/bash

p5pRT commented 11 years ago

From @jkeenan

On Fri Mar 22 05​:19​:42 2013\, ppisar wrote​:

This is a bug report for perl from ppisar@​redhat.com\, generated with the help of perlbug 1.39 running under perl 5.16.2.

-----------------------------------------------------------------

ExtUtils-ParseXS-3.18 installs xsubpp script twice​:

$ make pure_install DESTDIR=/tmp/ExtUtils-ParseXS-3.18-dest [...] $ find /tmp/ExtUtils-ParseXS-3.18-dest -name xsubpp /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/share/perl5/ExtUtils/xsubpp /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/bin/xsubpp

$ diff -u /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/bin/xsubpp /tmp/ExtUtils-ParseXS-3.18- dest/usr/local/share/perl5/ExtUtils/xsubpp --- /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/bin/xsubpp 2013- 03-22 13​:13​:08.000000000 +0100 +++ /tmp/ExtUtils-ParseXS-3.18- dest/usr/local/share/perl5/ExtUtils/xsubpp 2011-12-02 08​:07​:25.000000000 +0100 @​@​ -1\,7 +1\,4 @​@​ -#!/usr/bin/perl - -eval 'exec /usr/bin/perl -S $0 ${1+"$@​"}' - if 0; # not running under some shell +#!perl use 5.006; use strict; eval {

Please stop installing xsubpp into @​INC path.

-- Petr

I don't see what the problem is here.

In the first place\, when you install/upgrade ExtUtils​::ParseXS from CPAN\, it installs xsubpp into /usr/local/bin and its man page into /usr/local/share/man/man1 -- period; nothing else gets installed.

So that leaves the installation of xsubpp when you install a new version of Perl and get whatever version of ExtUtils​::ParseXS that comes along with that Perl. I have never had occasion to use 'make pure_install'\, so I cannot speak to your use of it. However\, I think your understanding of @​INC is not quite correct. From pod/perlvar.pod​:

##### =item @​INC X\<@​INC>

The array C\<@​INC> contains the list of places that the C\\, C\\, or C\ constructs look for their library files. #####

AFAIK\, there is no requirement that the paths named in @​INC contain *only* Perl library (.pm) files. Hence\, there is no reason to view as problematic placement of a version of xsubpp in a directory which happens to be locatable via @​INC. /usr/local/lib/perl5/5.16.0/ExtUtils/\, for example\, contains .pm files\, a .pod file\, a MANIFEST.SKIP\, a configuration file (typemap) as well as a read-only version of xsubpp.

So\, I don't see a bug here.

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From @ppisar

On Sat\, Mar 23\, 2013 at 11​:57​:12AM -0700\, James E Keenan via RT wrote​:

On Fri Mar 22 05​:19​:42 2013\, ppisar wrote​:

ExtUtils-ParseXS-3.18 installs xsubpp script twice​:

$ make pure_install DESTDIR=/tmp/ExtUtils-ParseXS-3.18-dest [...] $ find /tmp/ExtUtils-ParseXS-3.18-dest -name xsubpp /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/share/perl5/ExtUtils/xsubpp /tmp/ExtUtils-ParseXS-3.18-dest/usr/local/bin/xsubpp

[...] Please stop installing xsubpp into @​INC path.

I don't see what the problem is here.

The problem here is the same file gets installed into /usr/{\,local/}bin and into @​INC. What's good for to have the same file twice in your system?

In the first place\, when you install/upgrade ExtUtils​::ParseXS from CPAN\, it installs xsubpp into /usr/local/bin and its man page into /usr/local/share/man/man1 -- period; nothing else gets installed.

Not at all. I've just given a try​:

root@​fedora-20​:/usr/local # cpan -i -f ExtUtils​::ParseXS Reading '/root/.cpan/Metadata'   Database was generated on Mon\, 25 Mar 2013 14​:41​:04 GMT Running install for module 'ExtUtils​::ParseXS' Running make for S/SM/SMUELLER/ExtUtils-ParseXS-3.18.tar.gz [...] Result​: PASS   SMUELLER/ExtUtils-ParseXS-3.18.tar.gz   /usr/bin/make test -- OK Running make install Installing /usr/local/share/perl5/ExtUtils/Typemaps.pm Installing /usr/local/share/perl5/ExtUtils/ParseXS.pod Installing /usr/local/share/perl5/ExtUtils/xsubpp Installing /usr/local/share/perl5/ExtUtils/ParseXS.pm Installing /usr/local/share/perl5/ExtUtils/Typemaps/Type.pm Installing /usr/local/share/perl5/ExtUtils/Typemaps/InputMap.pm Installing /usr/local/share/perl5/ExtUtils/Typemaps/Cmd.pm Installing /usr/local/share/perl5/ExtUtils/Typemaps/OutputMap.pm Installing /usr/local/share/perl5/ExtUtils/ParseXS/Constants.pm Installing /usr/local/share/perl5/ExtUtils/ParseXS/CountLines.pm Installing /usr/local/share/perl5/ExtUtils/ParseXS/Utilities.pm Installing /usr/local/share/man/man1/xsubpp.1 Installing /usr/local/share/man/man3/ExtUtils​::ParseXS​::Utilities.3pm Installing /usr/local/share/man/man3/ExtUtils​::ParseXS.3pm Installing /usr/local/share/man/man3/ExtUtils​::ParseXS​::Constants.3pm Installing /usr/local/share/man/man3/ExtUtils​::Typemaps​::Type.3pm Installing /usr/local/share/man/man3/ExtUtils​::Typemaps​::OutputMap.3pm Installing /usr/local/share/man/man3/ExtUtils​::Typemaps​::Cmd.3pm Installing /usr/local/share/man/man3/ExtUtils​::Typemaps.3pm Installing /usr/local/share/man/man3/ExtUtils​::Typemaps​::InputMap.3pm Installing /usr/local/bin/xsubpp Appending installation info to /usr/lib64/perl5/perllocal.pod   SMUELLER/ExtUtils-ParseXS-3.18.tar.gz   /usr/bin/make install -- OK

I have never had occasion to use 'make pure_install'\, The same as make install minus installing some unneeded stuff.

The array C\<@​INC> contains the list of places that the C\\, C\\, or C\ constructs look for their library files.

And is xsubpp supposed to be "require"-d by other perl code? Then there is no reason to install the file there.

AFAIK\, there is no requirement that the paths named in @​INC contain *only* Perl library (.pm) files.

Thus it's reasonable to put the file there?

/usr/local/lib/perl5/5.16.0/ExtUtils/\, for example\, contains .pm files\, a .pod file\, a MANIFEST.SKIP\, Yeah\, such usefull MANIFEST.SKIP that will get overwitten by another package installation? Maybe that's reason for make pure_install.

a configuration file (typemap) as well as a read-only version of xsubpp.

Again\, what is it good for?

So\, I don't see a bug here.

If I can be constructive\, moving lib/ExtUtils/xsubpp to scripts/xsubpp and removing 'EXE_FILES' => ['lib/ExtUtils/xsubpp'] from Makefile.PL should fix this issue.

-- Petr

p5pRT commented 11 years ago

From @Leont

On Mon\, Mar 25\, 2013 at 4​:45 PM\, Petr Pisar \ppisar@&#8203;redhat\.com wrote​:

The problem here is the same file gets installed into /usr/{\,local/}bin and into @​INC. What's good for to have the same file twice in your system?

AFAIK the original place was in @​INC. It was later added to install{\,vendor\,site}bin.

And is xsubpp supposed to be "require"-d by other perl code? Then there is no reason to install the file there.

AFAIK\, there is no requirement that the paths named in @​INC contain *only* Perl library (.pm) files.

Thus it's reasonable to put the file there?

Hysterical raisins.

MakeMaker depends on it being there. Even if we'd change how MakeMaker works\, there's still older versions to keep into account. I agree with you it's not a logical location\, but we just can't go around breaking 20 years of MakeMaker out of stylistic reasons.

a configuration file (typemap) as well as a read-only version of xsubpp.

Again\, what is it good for?

Actually\, I wouldn't know a better place for that than in @​INC. Granted\, nowadays we'd use File​::ShareDir or some such\, but it boils down to the same.

If I can be constructive\, moving lib/ExtUtils/xsubpp to scripts/xsubpp and removing 'EXE_FILES' => ['lib/ExtUtils/xsubpp'] from Makefile.PL should fix this issue.

Hindsight is 20/20.

Leon

p5pRT commented 11 years ago

From @jkeenan

On Mon Mar 25 12​:49​:34 2013\, LeonT wrote​:

On Mon\, Mar 25\, 2013 at 4​:45 PM\, Petr Pisar \ppisar@&#8203;redhat\.com wrote​:

The problem here is the same file gets installed into /usr/{\,local/}bin and into @​INC. What's good for to have the same file twice in your system?

AFAIK the original place was in @​INC. It was later added to install{\,vendor\,site}bin.

And is xsubpp supposed to be "require"-d by other perl code? Then there is no reason to install the file there.

AFAIK\, there is no requirement that the paths named in @​INC contain *only* Perl library (.pm) files.

Thus it's reasonable to put the file there?

Hysterical raisins.

MakeMaker depends on it being there. Even if we'd change how MakeMaker works\, there's still older versions to keep into account. I agree with you it's not a logical location\, but we just can't go around breaking 20 years of MakeMaker out of stylistic reasons.

a configuration file (typemap) as well as a read-only version of xsubpp.

Again\, what is it good for?

Actually\, I wouldn't know a better place for that than in @​INC. Granted\, nowadays we'd use File​::ShareDir or some such\, but it boils down to the same.

If I can be constructive\, moving lib/ExtUtils/xsubpp to scripts/xsubpp and removing 'EXE_FILES' => ['lib/ExtUtils/xsubpp'] from Makefile.PL should fix this issue.

Hindsight is 20/20.

Leon

If Leon's argument is correct\, then we are stuck with the status quo -- which makes this ticket closable?

Any dissent?

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

From @tonycoz

On Mon Mar 25 17​:55​:05 2013\, jkeenan wrote​:

If Leon's argument is correct\, then we are stuck with the status quo -- which makes this ticket closable?

I agree\, and closing it.

Tony

p5pRT commented 11 years ago

@tonycoz - Status changed from 'open' to 'resolved'