Perl v5.20.1 Configure bug?

p5pRT commented 9 years ago

Migrated from rt.perl.org#123250 (status was 'rejected')

Searchable as RT123250$

p5pRT commented 9 years ago

From hafen.mccormick@gmail.com

Hello\,

I am attempting to build and install Perl v5.20.1 on OS X 10.6.8\, but I'm having serious problems. Because I'm sure the Configure script that comes with the Perl distribution has been tested thoroughly and used successfully an unimaginably large number of times\, I'm absolutely puzzled to see what would seem to be a basic and fundamental problem with Configure.

I can see that the Configure script compiles and sometimes runs test programs to determine the answers to many configuration questions (I explicitly chose to have it do so rather than using 'nm'). The code that examines the result of those test programs considers a non-zero exit status a successful result. However\, the gcc compiler I'm using (gcc-mp-4.6) returns non-zero upon failure.

This shows up\, of course\, during the compile phase when many errors similar to the one below appear:

proto.h:975:47: error: unknown type name 'off64_t'

Though I do not have 'off64_t'\, the Configure script reports that I do have it:

Checking to see if you have off64_t... You have off64_t.

When I run the test program myself\, it fails and returns a non-zero exit status:

$ cat >mytry.c \<\<EOCP > #include \<sys/types.h> > #include \<unistd.h> > int main() { off64_t x = 7; } > EOCP $ gcc-mp-4.6 -o mytry -O3 -fno-common -DPERL_DARWIN -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/opt/local/include -I/usr/local/include -DDEBUGGING mytry.c mytry.c: In function 'main': mytry.c:3:14: error: unknown type name 'off64_t' $ echo $? 1

Including here the most relevant parts of the Configure script\, i.e. the parts that decide how to evaluate this test program:

if eval $compile; then val="$define" echo "You have off64_t." else val="$undef" echo "You do not have off64_t." fi

where the last line of the definition of "compile" is this:

$cc -o ${mc_file} $optimize $ccflags $ldflags $* ${mc_file}.c $libs;

Looking through the configure script\, it seems that evaluation of $compile (and $compile_ok\, also) follows a similar pattern throughout the rest of the code.

Am I doing something terribly wrong here? I'm running Configure right after unpacking the tarball\, and I'm simply running it like so:

./Configure -Dprefix=/usr/local/

Thanks for any help you can provide!

Sincerely\,

-Hafen

p5pRT commented 9 years ago

From @jhi

where the last line of the definition of "compile" is this:
 $cc \-o $\{mc\_file\} $optimize $ccflags $ldflags $\* $\{mc\_file\}\.c $libs;
Looking through the configure script\, it seems that evaluation of $compile (and $compile_ok\, also) follows a similar pattern throughout the rest of the code.

Indeed it looks weird.

Could you temporarily modify your Configure by adding the line

set -x

just before the ": check for off64_t" line\, and adding the line

exit 0

just after the "eval $setvar" line that completes the off64_t scan\, and then

rm -f config.sh config.over

(to reset any cached values) and then run Configure with exactly all the same arguments you've been using.

The "set -x" will give us more debugging once the script reaches the off64_t scan.

Have you tried with the Apple-provided cc (which is actually clang) from XCode?

p5pRT commented 9 years ago

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

p5pRT commented 9 years ago

From hafen.mccormick@gmail.com

No I haven't tried llvm (I'm still running OS X 10.6.8 with XCode 3.2.3 which means llvm is there\, but not the default). Part of my motivation for trying to build Perl from source is so that I can use gcc-mp-4.6 rather than the apple-provided gcc-4.2 (or even llvm).

This is the output from the modification you suggested:

+ : check for off64_t + echo ' '

+ echo 'Checking to see if you have off64_t...' Checking to see if you have off64_t... + /bin/cat + set try + eval 'mc_file=$1;' 'shift;' case '"$usedevel"' in '$define|true|[yY]*)' if '$test' '!' -f '"${mc_file}.c";' then echo '"Internal' Configure script bug - compiler test file '${mc_file}.c' is missing. Please report this to 'perlbug@perl.org"' '>&4;' exit '1;' 'fi;' 'esac;' '$cc' -o '${mc_file}' '$optimize' '$ccflags' '$ldflags' '$*' '${mc_file}.c' '$libs' '>' /dev/null '2>&1;' ++ mc_file=try ++ shift ++ case "$usedevel" in ++ gcc-mp-4.6 -o try -O3 -fno-common -DPERL_DARWIN -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/opt/local/include -I/usr/local/include -DDEBUGGING -fstack-protector -L/opt/local/lib -L/opt/local/lib/gcc46 -L/usr/local/lib try.c -lgdbm + val=define + echo 'You have off64_t.' You have off64_t. + /bin/rm -f try try a.out .out try.c try..o core 'core.try*' 'try.core*' + set d_off64_t + eval 'var=$1;' eval '"was=\$$1";' 'td=$define;' 'tu=$undef;' case '"$val$was"' in '$define$undef)' . './whoa;' eval '"$var=\$td";;' '$undef$define)' . './whoa;' eval '"$var=\$tu";;' '*)' eval '"$var=$val";;' esac ++ var=d_off64_t ++ eval 'was=$d_off64_t' +++ was= ++ td=define ++ tu=undef ++ case "$val$was" in ++ eval d_off64_t=define +++ d_off64_t=define + exit 0

On Nov 19\, 2014\, at 12:51 PM\, Jarkko Hietaniemi via RT wrote:

where the last line of the definition of "compile" is this:
$cc \-o $\{mc\_file\} $optimize $ccflags $ldflags $\* $\{mc\_file\}\.c $libs;
Looking through the configure script\, it seems that evaluation of $compile (and $compile_ok\, also) follows a similar pattern throughout the rest of the code.
Indeed it looks weird.

Could you temporarily modify your Configure by adding the line

set -x

just before the ": check for off64_t" line\, and adding the line

exit 0

just after the "eval $setvar" line that completes the off64_t scan\, and then

rm -f config.sh config.over

(to reset any cached values) and then run Configure with exactly all the same arguments you've been using.

The "set -x" will give us more debugging once the script reaches the off64_t scan.

Have you tried with the Apple-provided cc (which is actually clang) from XCode?

p5pRT commented 9 years ago

From @jhi

So that gcc line compiled the try.c without failing.

On Thu\, Nov 20\, 2014 at 08:34 Hafen McCormick \hafen\.mccormick@gmail\.com wrote:

No I haven't tried llvm (I'm still running OS X 10.6.8 with XCode 3.2.3 which means llvm is there\, but not the default). Part of my motivation for trying to build Perl from source is so that I can use gcc-mp-4.6 rather than the apple-provided gcc-4.2 (or even llvm).

This is the output from the modification you suggested:

+ : check for off64_t + echo ' '

+ echo 'Checking to see if you have off64_t...' Checking to see if you have off64_t... + /bin/cat + set try + eval 'mc_file=$1;' 'shift;' case '"$usedevel"' in '$define|true|[yY]*)' if '$test' '!' -f '"${mc_file}.c";' then echo '"Internal' Configure script bug - compiler test file '${mc_file}.c' is missing. Please report this to 'perlbug@perl.org"' '>&4;' exit '1;' 'fi;' 'esac;' '$cc' -o '${mc_file}' '$optimize' '$ccflags' '$ldflags' '$*' '${mc_file}.c' '$libs' '>' /dev/null '2>&1;' ++ mc_file=try ++ shift ++ case "$usedevel" in ++ gcc-mp-4.6 -o try -O3 -fno-common -DPERL_DARWIN -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/opt/local/include -I/usr/local/include -DDEBUGGING -fstack-protector -L/opt/local/lib -L/opt/local/lib/gcc46 -L/usr/local/lib try.c -lgdbm + val=define + echo 'You have off64_t.' You have off64_t. + /bin/rm -f try try a.out .out try.c try..o core 'core.try*' 'try.core*' + set d_off64_t + eval 'var=$1;' eval '"was=\$$1";' 'td=$define;' 'tu=$undef;' case '"$val$was"' in '$define$undef)' . './whoa;' eval '"$var=\$td";;' '$undef$define)' . './whoa;' eval '"$var=\$tu";;' '*)' eval '"$var=$val";;' esac ++ var=d_off64_t ++ eval 'was=$d_off64_t' +++ was= ++ td=define ++ tu=undef ++ case "$val$was" in ++ eval d_off64_t=define +++ d_off64_t=define + exit 0

On Nov 19\, 2014\, at 12:51 PM\, Jarkko Hietaniemi via RT wrote:

where the last line of the definition of "compile" is this:
$cc \-o $\{mc\_file\} $optimize $ccflags $ldflags $\* $\{mc\_file\}\.c $libs;
Looking through the configure script\, it seems that evaluation of $compile (and $compile_ok\, also) follows a similar pattern throughout the rest of the code.

Indeed it looks weird.

Could you temporarily modify your Configure by adding the line

set -x

just before the ": check for off64_t" line\, and adding the line

exit 0

just after the "eval $setvar" line that completes the off64_t scan\, and then

rm -f config.sh config.over

(to reset any cached values) and then run Configure with exactly all the same arguments you've been using.

The "set -x" will give us more debugging once the script reaches the off64_t scan.

Have you tried with the Apple-provided cc (which is actually clang) from XCode?

p5pRT commented 9 years ago

From @doughera88

On Tue\, Nov 18\, 2014 at 06:24:42PM -0800\, Hafen McCormick wrote:

# New Ticket Created by Hafen McCormick # Please include the string: [perl #123250] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=123250 >

Hello\,

I am attempting to build and install Perl v5.20.1 on OS X 10.6.8\, but I'm having serious problems. Because I'm sure the Configure script that comes with the Perl distribution has been tested thoroughly and used successfully an unimaginably large number of times\, I'm absolutely puzzled to see what would seem to be a basic and fundamental problem with Configure.

I can see that the Configure script compiles and sometimes runs test programs to determine the answers to many configuration questions (I explicitly chose to have it do so rather than using 'nm'). The code that examines the result of those test programs considers a non-zero exit status a successful result. However\, the gcc compiler I'm using (gcc-mp-4.6) returns non-zero upon failure.

Configure agrees with gcc that a non-zero exit status is a failure. (This is standard for Bourne Shell\, but indeed backwards from what you might based on return values in other languages.) The if/then logic is correct; you're just not getting the expected return status from gcc-mp-4.6.

This shows up\, of course\, during the compile phase when many errors similar to the one below appear:
proto\.h&#8203;:975&#8203;:47&#8203;: error&#8203;: unknown type name 'off64\_t'
Though I do not have 'off64_t'\, the Configure script reports that I do have it:
Checking to see if you have off64\_t\.\.\.
You have off64\_t\.
When I run the test program myself\, it fails and returns a non-zero exit status:
$ cat >mytry\.c \<\<EOCP
> \#include \<sys/types\.h>
> \#include \<unistd\.h>
> int main \{ off64\_t x = 7; \}
> EOCP
$ gcc\-mp\-4\.6 \-o mytry \-O3 \-fno\-common \-DPERL\_DARWIN \-fwrapv \-fno\-strict\-aliasing \-pipe \-fstack\-protector \-I/opt/local/include \-I/usr/local/include \-DDEBUGGING mytry\.c
mytry\.c&#8203;: In function 'main'&#8203;:
mytry\.c&#8203;:3&#8203;:14&#8203;: error&#8203;: unknown type name 'off64\_t'
$ echo $?
1

This is indeed odd. There must be something somewhere different between what Configure is running and what you are running by hand. Can you try applying the following little patch to Configure and then re-try\, i.e.

rm -f config.sh config.over; ./Configure -Dprefix=/usr/local/ 2>&1 | tee config.log

The patch prints out the environment\, passes in the verbose flag to gcc\, and uses the $compile_ok function\, which doesn't hide the output. This should allow you to manually recreate the exact same command line in the exact same environment to see whether the test still fails when run by hand but passes when run within Configure. My guess is you're going to find some subtle differences between what Configure ran and what you ran by hand.

Inline Patch

```diff diff --git a/Configure b/Configure index 69dd589..a31d37c 100755 --- a/Configure +++ b/Configure @@ -17121,8 +17121,9 @@ $cat >try.c < int main() { off64_t x = 7; } EOCP -set try -if eval $compile; then +env +set try -v +if eval $compile_ok; then val="$define" echo "You have off64_t." else ```

Hope this helps. Let us know how it goes.

-- Andy Dougherty doughera@lafayette.edu

p5pRT commented 9 years ago

From hafen.mccormick@gmail.com

On Nov 20\, 2014\, at 3:43 PM\, Andy Dougherty via RT wrote:

On Tue\, Nov 18\, 2014 at 06:24:42PM -0800\, Hafen McCormick wrote:

# New Ticket Created by Hafen McCormick # Please include the string: [perl #123250] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=123250 >

Hello\,

I am attempting to build and install Perl v5.20.1 on OS X 10.6.8\, but I'm having serious problems. Because I'm sure the Configure script that comes with the Perl distribution has been tested thoroughly and used successfully an unimaginably large number of times\, I'm absolutely puzzled to see what would seem to be a basic and fundamental problem with Configure.

I can see that the Configure script compiles and sometimes runs test programs to determine the answers to many configuration questions (I explicitly chose to have it do so rather than using 'nm'). The code that examines the result of those test programs considers a non-zero exit status a successful result. However\, the gcc compiler I'm using (gcc-mp-4.6) returns non-zero upon failure.

Configure agrees with gcc that a non-zero exit status is a failure. (This is standard for Bourne Shell\, but indeed backwards from what you might based on return values in other languages.) The if/then logic is correct; you're just not getting the expected return status from gcc-mp-4.6.

This shows up\, of course\, during the compile phase when many errors similar to the one below appear:

proto.h:975:47: error: unknown type name 'off64_t'

Though I do not have 'off64_t'\, the Configure script reports that I do have it:

Checking to see if you have off64_t... You have off64_t.

When I run the test program myself\, it fails and returns a non-zero exit status:

$ cat >mytry.c \<\<EOCP

#include \<sys/types.h> #include \<unistd.h> int main() { off64_t x = 7; } EOCP $ gcc-mp-4.6 -o mytry -O3 -fno-common -DPERL_DARWIN -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/opt/local/include -I/usr/local/include -DDEBUGGING mytry.c mytry.c: In function 'main': mytry.c:3:14: error: unknown type name 'off64_t' $ echo $? 1

This is indeed odd. There must be something somewhere different between what Configure is running and what you are running by hand. Can you try applying the following little patch to Configure and then re-try\, i.e.
rm \-f config\.sh config\.over;
./Configure -Dprefix=/usr/local/ 2>&1 | tee config.log

The patch prints out the environment\, passes in the verbose flag to gcc\, and uses the $compile_ok function\, which doesn't hide the output. This should allow you to manually recreate the exact same command line in the exact same environment to see whether the test still fails when run by hand but passes when run within Configure. My guess is you're going to find some subtle differences between what Configure ran and what you ran by hand.

diff --git a/Configure b/Configure index 69dd589..a31d37c 100755 --- a/Configure +++ b/Configure @@ -17121\,8 +17121\,9 @@ $cat >try.c \<\<EOCP #include \<unistd.h> int main() { off64_t x = 7; } EOCP -set try -if eval $compile; then +env +set try -v +if eval $compile_ok; then val="$define" echo "You have off64_t." else

Hope this helps. Let us know how it goes.

-- Andy Dougherty doughera@lafayette.edu

You were correct. Thanks to the change you suggested\, I was able to discover that I had a wrapper around gcc which was failing to pass along the correct exit status.

Thank you so much for your help!

p5pRT commented 9 years ago

@cpansprout - Status changed from 'open' to 'rejected'

Perl / perl5