search

Perl / perl5

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

Build fails on HP-UX when using GNU "make" as "gmake" instead of "make". #20502

Open Antinode-org opened 1 year ago

Antinode-org commented 1 year ago

I tried to build perl 5.36.0 on HP-UX 11.31 (11i v3), using GCC (because the bundled compiler is lame) and GNU "make" (because the the "make" program supplied with the OS is lame).

GNU "make" is installed as "/usr/local/bin/make", with a symlink for convenience: "/usr/local/bin/gmake -> make". This allows a user to run GNU "make" as "gmake", when his PATH would normally lead to "/usr/bin/make" for plain-old "make".

The following commands then failed (well into the build):

  dyi# CC=gcc ./configure.gnu
  dyi# gmake

[...] Writing Makefile for Encode gmake[1]: Entering directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' gmake[1]: Leaving directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' Making all in ext/Encode gmake all PERL_CORE=1 LIBPERL_A=libperl.a LINKTYPE=dynamic gmake[1]: Entering directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' Skip ../../lib/Encode/JP/H2Z.pm (unchanged) [...] Skip ../../lib/Encode/CJKConstants.pm (unchanged) Make: Unknown flag argument . Stop. gmake[1]: [Makefile:621: subdirs] Error 1 gmake[1]: Leaving directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' Unsuccessful make(ext/Encode): code=512 at make_ext.pl line 360. gmake: [makefile:672: lib/auto/Encode/Encode.so] Error 25

I have not investigated this thoroughly, but my guess is that some "make" file in the middle of the build is using a plain "make" instead of a "$(MAKE)", so that the lame "/usr/bin/make" is getting used instead of the "gmake" specified explicitly by the user.

Changing my PATH so that "/usr/local/bin" came before "/usr/bin/" seemed to work around this problem, but I claim that this should not be necessary. All the builders and sub-builders, I claim, should use the same "make" program, and not surprise the victim mid-build by unexpectedly pulling in some random "make" program which he deliberately did not specify. This, I thought, was the purpose of the "MAKE" macro.

Thanks for your consideration.

dyi# uname -a HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license

dyi# gcc --version gcc (GCC) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dyi# gmake --version GNU Make 4.4 Built for ia64-hp-hpux11.31 Copyright (C) 1988-2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

tonycoz commented 1 year ago

Try adding -Dmake=gmake to the configure step.

Tux commented 1 year ago

On Thu, 10 Nov 2022 21:49:26 -0800, Antinode-org @.***> wrote:

I tried to build perl 5.36.0 on HP-UX 11.31 (11i v3), using GCC (because the bundled compiler is lame) and GNU "make" (because the the "make" program supplied with the OS is lame).

GNU "make" is installed as "/usr/local/bin/make", with a symlink for convenience: "/usr/local/bin/gmake -> make". This allows a user to run GNU "make" as "gmake", when his PATH would normally lead to "/usr/bin/make" for plain-old "make".

$ export PATH=/usr/local/bin:$PATH % setenv PATH /usr/local/bin:$PATH

problem solved

The following commands then failed (well into the build):

  dyi# CC=gcc ./configure.gnu
  dyi# gmake

[...] Writing Makefile for Encode gmake[1]: Entering directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' gmake[1]: Leaving directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' Making all in ext/Encode gmake all PERL_CORE=1 LIBPERL_A=libperl.a LINKTYPE=dynamic gmake[1]: Entering directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' Skip ../../lib/Encode/JP/H2Z.pm (unchanged) [...] Skip ../../lib/Encode/CJKConstants.pm (unchanged) Make: Unknown flag argument . Stop. gmake[1]: [Makefile:621: subdirs] Error 1 gmake[1]: Leaving directory '/usr/local/src/perl/perl-5.10.1/ext/Encode' Unsuccessful make(ext/Encode): code=512 at make_ext.pl line 360. gmake: [makefile:672: lib/auto/Encode/Encode.so] Error 25

I have not investigated this thoroughly, but my guess is that some "make" file in the middle of the build is using a plain "make" instead of a "$(MAKE)", so that the lame "/usr/bin/make" is getting used instead of the "gmake" specified explicitly by the user.

Changing my PATH so that "/usr/local/bin" came before "/usr/bin/" seemed to work around this problem, but I claim that this should not be necessary.

If you don't want to take the easy way, use what Tony proposed

-Dmake=gmake

All the builders and sub-builders, I claim, should use the same "make" program, and not surprise the victim mid-build by unexpectedly pulling in some random "make" program which he deliberately did not specify. This, I thought, was the purpose of the "MAKE" macro.

Thanks for your consideration.

dyi# uname -a HP-UX dyi B.11.31 U ia64 4235313755 unlimited-user license

dyi# gcc --version gcc (GCC) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

dyi# gmake --version GNU Make 4.4 Built for ia64-hp-hpux11.31 Copyright (C) 1988-2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

-- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

Antinode-org commented 1 year ago

Try adding -Dmake=gmake to the configure step.

How, exactly? I tried:

  dyi# CC=gcc DEFS='-Dmake=gmake' ./configure.gnu

which seemed to get "-Dmake=gmake" added to "gcc" commands, and 'MAKE="gmake"' added to "./miniperl" commands. All of which seems to have had no effect on the actual problem:

[...] gmake[1]: Leaving directory '/usr/local/src/perl/perl-5.36.0/cpan/Digest-SHA' ./miniperl -Ilib make_ext.pl lib/auto/Encode/Encode.so MAKE="gmake" LIBPERL_A=libperl.a LINKTYPE=dynamic Generating a Unix-style Makefile Writing Makefile for Encode gmake[1]: Entering directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' Make: Unknown flag argument . Stop. gmake[1]: [Makefile:588: subdirs] Error 1 gmake[1]: Leaving directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' gmake[1]: Entering directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' Make: Unknown flag argument . Stop. gmake[1]: [Makefile:588: subdirs] Error 1 gmake[1]: Leaving directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' Unsuccessful make(cpan/Encode): code=512 at make_ext.pl line 584. gmake: *** [makefile:583: lib/auto/Encode/Encode.so] Error 25

I see that this situation seems to be discussed in "make_ext.pl":

Previously, $make was taken from config.sh. However, the user might

instead be running a possibly incompatible make. This might happen if

the user types "gmake" instead of a plain "make", for example. The

correct current value of MAKE will come through from the main perl

makefile as MAKE=/whatever/make in $makecmd. [...]

I'm not fluent in perl, and wasn't intending to become so. All I was trying to do was build a recent OpenSSL version, which demanded a fresher perl than what I already had on the system in question. So my trying to trace/track problems in the perl builders serves mainly to make my head hurt. However, I'd expect it to be pretty easy for someone with greater perl expertise to replicate the problem. For example:

dyi# pwd /usr/local/src/perl/perl-5.36.0 dyi# mkdir junk dyi# echo '#!/bin/sh -fred' > junk/make dyi# chmod a+x junk/make dyi# export PATH=pwd/junk:${PATH} dyi# type make make is /usr/local/src/perl/perl-5.36.0/junk/make dyi# make -fred: A specified flag is not valid for this command.

dyi# CC=gcc ./configure.gnu # Add options as desired. dyi# /usr/local/bin/make # Actual path to a working "make" program.

[...] make[1]: Leaving directory '/usr/local/src/perl/perl-5.36.0/cpan/Digest-SHA' ./miniperl -Ilib make_ext.pl lib/auto/Encode/Encode.so MAKE="/usr/local/bin/make" LIBPERL_A=libperl.a LINKTYPE=dynamic Generating a Unix-style Makefile Writing Makefile for Encode make[1]: Entering directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' -fred: A specified flag is not valid for this command. make[1]: [Makefile:588: subdirs] Error 1 make[1]: Leaving directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' make[1]: Entering directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' -fred: A specified flag is not valid for this command. make[1]: [Makefile:588: subdirs] Error 1 make[1]: Leaving directory '/usr/local/src/perl/perl-5.36.0/cpan/Encode' Unsuccessful make(cpan/Encode): code=512 at make_ext.pl line 584. make: *** [Makefile:583: lib/auto/Encode/Encode.so] Error 25

That "-fred: A specified flag is not valid for this command." error message, which clearly came from my new "junk/make" script, indicates to me that someone, someplace is using plain "make" rather than the victim-specified "make" program.

problem solved

I thank you for suggesting the work-around which I had already described. Please note, however, that "solved" and "worked around" are spelled differently for a reason.

If there were an actual requirement for a simple "make" command to work in the victim's environment, rather than for the victim to use an adequate "make" program (like, say, "gmake"), then I'd expect such a requirement to be prominently documented in INSTALL. I saw no such documentation, but if you could direct me to it, then I'd be grateful.

Regardless, in such a case, the builders should include an automated test of a simple "make" command, so that the failure could occur promptly, with a more informative error message, rather than some minutes into the build, emitting this unhelpful message from a program which the victim had no reason to believe was involved.

Otherwise, I (continue to) claim that this behavior is defective. But I'm always open to a good counter-argument.

Antinode-org commented 1 year ago

(Giant font chosen by the forum software, not by me.)

tonycoz commented 1 year ago

I meant something like:

CC=gcc ./configure.gnu -Dmake=gmake

The large font is from using the # at the beginning of line and not marking it as code, the single # formats the line as a level 1 heading. See the markdown help linked from the "M" icon at the bottom right of the comment box.

Antinode-org commented 1 year ago

I meant something like:

CC=gcc ./configure.gnu -Dmake=gmake

Ah. Ok. That seems to work. Thanks. My quick look at "configure.gnu" didn't make it obvious that pasting such stuff onto the command would make sense. So, this just gets stuck into "opts" (where it needs to be), and thus gets passed along to "Configure"?

Is there some documentation where I should have found this magic trick? Is there any good reason for it to be needed? Or for no good error message when it is? Plenty of stuff has no trouble using the victim-specified "[g]make" program before getting to the failure. And the origin of the error message from the lame (on-PATH) "make" program (use of which I had explicitly tried to avoid) is obscure (at best).

The large font is from using the # [...]

I assumed that further study of the forum features would reveal the details, but I'd already invested more time than I could justify here.

tonycoz commented 1 year ago

Ah. Ok. That seems to work. Thanks. My quick look at "configure.gnu" didn't make it obvious that pasting such stuff onto the command would make sense. So, this just gets stuck into "opts" (where it needs to be), and thus gets passed along to "Configure"?

Exactly. This should be (but isn't) documented in INSTALL, I'll look at it today (I hope).

Is there some documentation where I should have found this magic trick? Is there any good reason for it to be needed? Or for no good error message when it is?

I suspect this is an issue with the bundled ExtUtils::MakeMaker which is taking the Configured make instead of the invoked make, but I haven't looked that closely yet. It appears to be using the correct make to start building Encode, but then fails when building the sub directories under Encode (which is controlled by EU::MM).

The -Dmake=gmake sets the configured make and so EU::MM's generated makefile invokes the correct make for the subdirs targets.