From rongqing.li@windriver.com

1. failed to compile perl5 when path includes the string "blib"
Reproduce as below​:

#mkdir blib
#cd blib
#unxz perl-5.22.0.tar.xz
#tar -xvf perl-5.22.0.tar
#cd perl-5.22.0
#./Configure -des -Dprefix=./
#make

2. the possible patch is below​:
+---
+ dist/PathTools/Makefile.PL | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/dist/PathTools/Makefile.PL b/dist/PathTools/Makefile.PL
+index 1b21de4..f562cb2 100644
+--- a/dist/PathTools/Makefile.PL
++++ b/dist/PathTools/Makefile.PL
+@​@​ -1,6 +1,3 @​@​
+-
+-BEGIN { @​INC = grep {!/blib/} @​INC }
+-
+ require 5.005;
+ use ExtUtils​::MakeMaker;
+ WriteMakefile
+--
+1.9.1

From @jkeenan

On Sun Jul 12 19​:08​:58 2015, rongqing.li@​windriver.com wrote​:

1. failed to compile perl5 when path includes the string "blib"
Reproduce as below​:

#mkdir blib
#cd blib
#unxz perl-5.22.0.tar.xz
#tar -xvf perl-5.22.0.tar
#cd perl-5.22.0
#./Configure -des -Dprefix=./
#make

2. the possible patch is below​:
+---
+ dist/PathTools/Makefile.PL | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/dist/PathTools/Makefile.PL b/dist/PathTools/Makefile.PL
+index 1b21de4..f562cb2 100644
+--- a/dist/PathTools/Makefile.PL
++++ b/dist/PathTools/Makefile.PL
+@​@​ -1,6 +1,3 @​@​
+-
+-BEGIN { @​INC = grep {!/blib/} @​INC }
+-
+ require 5.005;
+ use ExtUtils​::MakeMaker;
+ WriteMakefile
+--
+1.9.1

PathTools is a library which is distributed with the Perl 5 core, but also available on CPAN (http​://search.cpan.org/dist/PathTools/). The fact that it is in the 'dist/' means that it is primarily maintained by the Perl 5 Porters.

However, any deficiency in dist/PathTools/Makefile.PL would *at most* affect the compilation of the PathTools library. It would *not* affect the compilation of perl 5 as a whole. So I doubt that a change to that Makefile.PL would be the remedy to your problem -- if indeed your problem is a failure of perl5 as a whole?

Could you please post, as an attachment to this bug report (or email attachment), the complete arguments you used to configure Perl and all the output of 'sh ./Configure' and 'make' up to the point where you experienced a failure?

Also, please let us know your OS; how you are attempting to build Perl 5; etc.

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

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

From rongqing.li@windriver.com

On Mon Jul 13 15​:37​:54 2015, jkeenan wrote​:

On Sun Jul 12 19​:08​:58 2015, rongqing.li@​windriver.com wrote​:

1. failed to compile perl5 when path includes the string "blib"
Reproduce as below​:

#mkdir blib
#cd blib
#unxz perl-5.22.0.tar.xz
#tar -xvf perl-5.22.0.tar
#cd perl-5.22.0
#./Configure -des -Dprefix=./
#make

2. the possible patch is below​:
+---
+ dist/PathTools/Makefile.PL | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/dist/PathTools/Makefile.PL b/dist/PathTools/Makefile.PL
+index 1b21de4..f562cb2 100644
+--- a/dist/PathTools/Makefile.PL
++++ b/dist/PathTools/Makefile.PL
+@​@​ -1,6 +1,3 @​@​
+-
+-BEGIN { @​INC = grep {!/blib/} @​INC }
+-
+ require 5.005;
+ use ExtUtils​::MakeMaker;
+ WriteMakefile
+--
+1.9.1

PathTools is a library which is distributed with the Perl 5 core, but
also available on CPAN (http​://search.cpan.org/dist/PathTools/). The
fact that it is in the 'dist/' means that it is primarily maintained
by the Perl 5 Porters.

However, any deficiency in dist/PathTools/Makefile.PL would *at most*
affect the compilation of the PathTools library. It would *not*
affect the compilation of perl 5 as a whole. So I doubt that a change
to that Makefile.PL would be the remedy to your problem -- if indeed
your problem is a failure of perl5 as a whole?

Could you please post, as an attachment to this bug report (or email
attachment), the complete arguments you used to configure Perl and all
the output of 'sh ./Configure' and 'make' up to the point where you
experienced a failure?

Also, please let us know your OS; how you are attempting to build Perl
5; etc.

Thank you very much.

I am using Ubuntu 14.04 LTS;

the configure log, make log, and config.h are attached

thanks.

From rongqing.li@windriver.com

config-result

From rongqing.li@windriver.com

config.h

From rongqing.li@windriver.com

make-result

From @jkeenan

On Sun Jul 12 19​:08​:58 2015, rongqing.li@​windriver.com wrote​:

1. failed to compile perl5 when path includes the string "blib"
Reproduce as below​:

#mkdir blib
#cd blib
#unxz perl-5.22.0.tar.xz
#tar -xvf perl-5.22.0.tar
#cd perl-5.22.0
#./Configure -des -Dprefix=./
#make

Is there some reason why you are trying to configure and build perl in a directory whose path ends in 'blib'?

For most Perl modules 'blib' is a directory reserved for the build process. It is something typically created by 'make'. While I suppose there is no law against working in a directory called 'blib', it does seem to be asking for trouble.

Can you explain why you are attempting this?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From rehsack@gmail.com

Am 15.07.2015 um 04​:20 schrieb Rongqing Li <rongqing.li@​windriver.com>​:

On 2015年07月15日 09​:58, James E Keenan via RT wrote​:

On Sun Jul 12 19​:08​:58 2015, rongqing.li@​windriver.com wrote​:

1. failed to compile perl5 when path includes the string "blib"
Reproduce as below​:

#mkdir blib
#cd blib
#unxz perl-5.22.0.tar.xz
#tar -xvf perl-5.22.0.tar
#cd perl-5.22.0
#./Configure -des -Dprefix=./
#make

Is there some reason why you are trying to configure and build perl in a directory whose path ends in 'blib'?

no special reason;

I are building a Yocto project, which includes perl;
but I can not building this project under a directory whose
path has "blib", since perl will fail to be compiled

I think others must spend lots of effect to find why
compilation failed once he meet this issue.

As far as I understand, Roy is complaining about reserved words in path.

From non-perl developers point of view, failing in configure stage with an
error of a reserved word is found in path would make it clearer for anyone,
but preferred would be a rewrite of the filter only removing the really
issued path components (I expect the current module build area).

blib already computes them, maybe sharing them (our) and PathTools filter
only the desired part?

I don't know about any other project failing because of reserved word in
build path.

Cheers
--
Jens Rehsack - rehsack@​gmail.com

From rongqing.li@windriver.com

On 2015年07月15日 09​:58, James E Keenan via RT wrote​:

On Sun Jul 12 19​:08​:58 2015, rongqing.li@​windriver.com wrote​:

1. failed to compile perl5 when path includes the string "blib"
Reproduce as below​:

#mkdir blib
#cd blib
#unxz perl-5.22.0.tar.xz
#tar -xvf perl-5.22.0.tar
#cd perl-5.22.0
#./Configure -des -Dprefix=./
#make

Is there some reason why you are trying to configure and build perl in a directory whose path ends in 'blib'?

no special reason;

I are building a Yocto project, which includes perl;
but I can not building this project under a directory whose
path has "blib", since perl will fail to be compiled

I think others must spend lots of effect to find why
compilation failed once he meet this issue.

-Roy

For most Perl modules 'blib' is a directory reserved for the build process. It is something typically created by 'make'. While I suppose there is no law against working in a directory called 'blib', it does seem to be asking for trouble.

Can you explain why you are attempting this?

Thank you very much.

--
Best Reagrds,
Roy | RongQing Li

From rongqing.li@windriver.com

On 2015年07月15日 13​:58, Jens Rehsack via RT wrote​:

I don't know about any other project failing because of reserved word in
build path.

Yes, I agree

-Roy

From @iabyn

On Wed, Jul 15, 2015 at 02​:59​:36PM +0800, Rongqing Li wrote​:

On 2015年07月15日 13​:58, Jens Rehsack via RT wrote​:

I don't know about any other project failing because of reserved word in
build path.

Yes, I agree

-Roy

I agree that perl should build regardless of whether the 4 chars "blib"
are in the build directory path or not; I also agree that removing this
line from Makefile.PL​:

  BEGIN { @​INC = grep {!/blib/} @​INC }

will fix the immediate problem. However, since I don't understand what
purpose that line serves / served, I'd be reluctant to remove it.

I would speculate that its trying to avoid picking up files from the blib/
subdir in the module's directory, which presumably may contain rubbish
from a failed earlier build attempt. In which case maybe the grep line
should be changed to

  BEGIN { @​INC = grep {!/^blib/} @​INC }

? By why that would have been thought necessary, I don't know.

The history if this line is that originally PathTools, as part of Cwd,
was in perl core (ext/) and didn't have this line. At some point it was
promoted / moved to cpan/ and used an auto-generated Makefile.PL. Then
at some point (5.19.3), the auto-generated file was replaced with the real
one from the CPAN distribution, which had, at some point, for some reason,
gained that line.

--
In England there is a special word which means the last sunshine
of the summer. That word is "spring".

From rehsack@gmail.com

Am 16.07.2015 um 15​:06 schrieb Dave Mitchell via RT <perlbug-followup@​perl.org>​:

On Wed, Jul 15, 2015 at 02​:59​:36PM +0800, Rongqing Li wrote​:

On 2015年07月15日 13​:58, Jens Rehsack via RT wrote​:

I don't know about any other project failing because of reserved word in
build path.

Yes, I agree

-Roy

I agree that perl should build regardless of whether the 4 chars "blib"
are in the build directory path or not; I also agree that removing this
line from Makefile.PL​:

BEGIN { @​INC = grep {!/blib/} @​INC }

will fix the immediate problem. However, since I don't understand what
purpose that line serves / served, I'd be reluctant to remove it.

That's why I voted against that patch in open-embedded and pressured for
an RT ;)

It is very reasonable to find the root cause as you started below.

I would speculate that its trying to avoid picking up files from the blib/
subdir in the module's directory, which presumably may contain rubbish
from a failed earlier build attempt. In which case maybe the grep line
should be changed to

BEGIN { @​INC = grep {!/^blib/} @​INC }

? By why that would have been thought necessary, I don't know.

The history if this line is that originally PathTools, as part of Cwd,
was in perl core (ext/) and didn't have this line. At some point it was
promoted / moved to cpan/ and used an auto-generated Makefile.PL. Then
at some point (5.19.3), the auto-generated file was replaced with the real
one from the CPAN distribution, which had, at some point, for some reason,
gained that line.

Maybe Steffen Müller has an idea (especially at PathTools I'm always
confused whether it's first updated in core and than mirrored to 2nd
life on CPAN or vice versa), or Leon Timmermans or David Golden (who
was responsible for Module​::Build​::Compat version 0.2808_01? Oh my, it
was Ken Williams - maybe one should ask him or simply regenerate ...)

Cheers
--
Jens Rehsack - rehsack@​gmail.com

From @Tux

On Thu, 16 Jul 2015 14​:05​:21 +0100, Dave Mitchell <davem@​iabyn.com>
wrote​:

On Wed, Jul 15, 2015 at 02​:59​:36PM +0800, Rongqing Li wrote​:

On 2015年07月15日 13​:58, Jens Rehsack via RT wrote​:

I don't know about any other project failing because of reserved word in
build path.

Yes, I agree

-Roy

I agree that perl should build regardless of whether the 4 chars "blib"
are in the build directory path or not; I also agree that removing this
line from Makefile.PL​:

BEGIN \{ @​INC = grep \{\!/blib/\} @​INC \}

That is wrong anyway, it should most likely be /\bblib\b/. I see no
reason whatsoever to skipp "/foo/blibber/duh" or "/foo/foblib/ong"

will fix the immediate problem. However, since I don't understand what
purpose that line serves / served, I'd be reluctant to remove it.

I would speculate that its trying to avoid picking up files from the blib/
subdir in the module's directory, which presumably may contain rubbish
from a failed earlier build attempt. In which case maybe the grep line
should be changed to

BEGIN \{ @​INC = grep \{\!/^blib/\} @​INC \}

? By why that would have been thought necessary, I don't know.

The history if this line is that originally PathTools, as part of Cwd,
was in perl core (ext/) and didn't have this line. At some point it was
promoted / moved to cpan/ and used an auto-generated Makefile.PL. Then
at some point (5.19.3), the auto-generated file was replaced with the real
one from the CPAN distribution, which had, at some point, for some reason,
gained that line.

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

From rongqing.li@windriver.com

On 2015年07月21日 20​:55, H. Merijn Brand via RT wrote​:

On Thu, 16 Jul 2015 14​:05​:21 +0100, Dave Mitchell <davem@​iabyn.com>
wrote​:

On Wed, Jul 15, 2015 at 02​:59​:36PM +0800, Rongqing Li wrote​:

On 2015年07月15日 13​:58, Jens Rehsack via RT wrote​:

I don't know about any other project failing because of reserved word in
build path.

Yes, I agree

-Roy

I agree that perl should build regardless of whether the 4 chars "blib"
are in the build directory path or not; I also agree that removing this
line from Makefile.PL​:

 BEGIN \{ @​INC = grep \{\!/blib/\} @​INC \}

That is wrong anyway, it should most likely be /\bblib\b/. I see no
reason whatsoever to skipp "/foo/blibber/duh" or "/foo/foblib/ong"

could you submit a patch for this issue

thanks

-Roy

From rongqing.li@windriver.com

On 2015年07月21日 20​:55, H. Merijn Brand via RT wrote​:

On Thu, 16 Jul 2015 14​:05​:21 +0100, Dave Mitchell <davem@​iabyn.com>
wrote​:

On Wed, Jul 15, 2015 at 02​:59​:36PM +0800, Rongqing Li wrote​:

On 2015年07月15日 13​:58, Jens Rehsack via RT wrote​:

I don't know about any other project failing because of reserved word in
build path.

Yes, I agree

-Roy

I agree that perl should build regardless of whether the 4 chars "blib"
are in the build directory path or not; I also agree that removing this
line from Makefile.PL​:

 BEGIN \{ @​INC = grep \{\!/blib/\} @​INC \}

That is wrong anyway, it should most likely be /\bblib\b/. I see no
reason whatsoever to skipp "/foo/blibber/duh" or "/foo/foblib/ong"

it can not fix all issues to replace /blib/ with /\bblib\b/.

/\bblib\b/ will make the building path "/tmp/xxxxblibyy/" work.
but if the building path has sub-dir blib, it does not work, like
/tmp/blib/

since \b is anchor in perl

-Roy

From rehsack@gmail.com

Am 29.07.2015 um 05​:05 schrieb rongqing via RT <perlbug-followup@​perl.org>​:

On 2015年07月21日 20​:55, H. Merijn Brand via RT wrote​:

On Thu, 16 Jul 2015 14​:05​:21 +0100, Dave Mitchell <davem@​iabyn.com>
wrote​:

On Wed, Jul 15, 2015 at 02​:59​:36PM +0800, Rongqing Li wrote​:

On 2015年07月15日 13​:58, Jens Rehsack via RT wrote​:

I don't know about any other project failing because of reserved word in
build path.

Yes, I agree

-Roy

I agree that perl should build regardless of whether the 4 chars "blib"
are in the build directory path or not; I also agree that removing this
line from Makefile.PL​:

BEGIN \{ @​INC = grep \{\!/blib/\} @​INC \}

That is wrong anyway, it should most likely be /\bblib\b/. I see no
reason whatsoever to skipp "/foo/blibber/duh" or "/foo/foblib/ong"

it can not fix all issues to replace /blib/ with /\bblib\b/.

/\bblib\b/ will make the building path "/tmp/xxxxblibyy/" work.
but if the building path has sub-dir blib, it does not work, like
/tmp/blib/

since \b is anchor in perl

The more I think about the source of the line (Module​::Build​::Compat),
I vote for completely remove that line and review such imports in future.

Cheers
--
Jens Rehsack - rehsack@​gmail.com

From @tonycoz

On Thu Jul 16 06​:18​:09 2015, rehsack@​gmail.com wrote​:

Maybe Steffen Müller has an idea (especially at PathTools I'm always
confused whether it's first updated in core and than mirrored to 2nd
life on CPAN or vice versa), or Leon Timmermans or David Golden (who
was responsible for Module​::Build​::Compat version 0.2808_01? Oh my, it
was Ken Williams - maybe one should ask him or simply regenerate ...)

The offending line was added to fix this bug​:

https://rt.cpan.org/Ticket/Display.html?id=4681

The line wasn't generated by Module​::Build​::Compat

Tony

From rehsack@gmail.com

Am 12.08.2015 um 08​:41 schrieb Tony Cook via RT <perlbug-followup@​perl.org>​:

On Thu Jul 16 06​:18​:09 2015, rehsack@​gmail.com wrote​:

Maybe Steffen Müller has an idea (especially at PathTools I'm always
confused whether it's first updated in core and than mirrored to 2nd
life on CPAN or vice versa), or Leon Timmermans or David Golden (who
was responsible for Module​::Build​::Compat version 0.2808_01? Oh my, it
was Ken Williams - maybe one should ask him or simply regenerate ...)

The offending line was added to fix this bug​:

https://rt.cpan.org/Ticket/Display.html?id=4681

The bug looks very weird - where comes the dirty Cwd 2.08 stuff from?
I'm not sure the line fixes the root cause, it seems to work on symptom...

However - 10 years later searching and fixing the root-cause might not
be reasonable at all.

Let's try to figure out how to fix the symptom fix to avoid breakage
of third party environments​:

Merijn proposed using /\bblib\b/ instead of /blib/ - looking at rt#4681
I would suggest using /^\bblib\b/

That should be restrictive enough to avoid disturbing anything else than
dirty blib/inc ...

The line wasn't generated by Module​::Build​::Compat

Thanks for investigating, Tony.

Best regards
--
Jens Rehsack - rehsack@​gmail.com

From @iabyn

On Wed, Aug 12, 2015 at 03​:13​:38PM +0200, Jens Rehsack wrote​:

Am 12.08.2015 um 08​:41 schrieb Tony Cook via RT <perlbug-followup@​perl.org>​:

On Thu Jul 16 06​:18​:09 2015, rehsack@​gmail.com wrote​:

Maybe Steffen Müller has an idea (especially at PathTools I'm always
confused whether it's first updated in core and than mirrored to 2nd
life on CPAN or vice versa), or Leon Timmermans or David Golden (who
was responsible for Module​::Build​::Compat version 0.2808_01? Oh my, it
was Ken Williams - maybe one should ask him or simply regenerate ...)

The offending line was added to fix this bug​:

https://rt.cpan.org/Ticket/Display.html?id=4681

The bug looks very weird - where comes the dirty Cwd 2.08 stuff from?
I'm not sure the line fixes the root cause, it seems to work on symptom...

However - 10 years later searching and fixing the root-cause might not
be reasonable at all.

Let's try to figure out how to fix the symptom fix to avoid breakage
of third party environments​:

Merijn proposed using /\bblib\b/ instead of /blib/ - looking at rt#4681
I would suggest using /^\bblib\b/

That should be restrictive enough to avoid disturbing anything else than
dirty blib/inc ...

The line wasn't generated by Module​::Build​::Compat

Thanks for investigating, Tony.

I've just applied the following to blead. Hopefully its a suitable
compromise.

commit 850e14d
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Tue Sep 27 16​:43​:30 2016 +0100
Commit​: David Mitchell <davem@​iabyn.com>
CommitDate​: Tue Sep 27 16​:48​:53 2016 +0100

  Cwd.xs​: avoid blib better while building
 
  RT # 125603
 
  There's an old line in Cwd's Makefile.PL​:
 
  BEGIN { @​INC = grep {!/blib/} @​INC }
 
  This was added 12 years ago to solve a problem with a static perl and
  building a newer Cwd (but no-one's quite sure what *exactly* the issue was
  any more).
 
  However, this breaks building perl under a directory that has 'blib'
  in the pathname. This commit estricts the grep to just exclusing exactly
  blib/lib and blib/arch.
 
  This should hopefully still workaround the static build issue, while no
  longer breaking perl builds.

Affected files ...
  M dist/PathTools/Makefile.PL

Differences ...

diff --git a/dist/PathTools/Makefile.PL b/dist/PathTools/Makefile.PL
index 6cd70fa..71b9a60 100644
--- a/dist/PathTools/Makefile.PL
+++ b/dist/PathTools/Makefile.PL
@@ -1,5 +1,11 @@
 
-BEGIN { @INC = grep {!/blib/} @INC }
+# See https://rt.cpan.org/Public/Bug/Display.html?id=4681
+# and https://rt.perl.org/Ticket/Display.html?id=125603
+# When installing a newer Cwd on a system with an existing Cwd,
+# under some circumstances the old Cwd.pm and the new Cwd.xs could
+# get mixed up and SEGVs ensue.
+
+BEGIN { @INC = grep { $_ ne "blib/arch" and $_ ne "blib/lib" } @INC }


-- 

"Foul and greedy Dwarf - you have eaten the last candle."
  -- "Hordes of the Things", BBC Radio.

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