Ticket #1977 (closed defect: fixed)

Opened 1 year ago

Last modified 7 months ago

Perl compile fails at autosplit phase

Reported by: Paul Lowman Assigned to: dnicholson@linuxfromscratch.org
Priority: normal Milestone:
Component: Book Version: 6.2
Severity: normal Keywords: preplibrary autosplit
Cc:

Description

Perl-5.8.8 compile fails with Make [preplibrary] Error 1. This is due to failure of miniperl to execute autosplit. The fix is to create lib/auto manually after the configure phase.

Attachments

perl_make.log (2.4 kB) - added by Paul Lowman on 03/25/07 20:22:00.
stdout
perl_make_errors.log (5.5 kB) - added by Paul Lowman on 03/25/07 20:22:20.
stderr
shell.trace (0.5 kB) - added by Paul Lowman on 03/25/07 21:33:16.

Change History

03/23/07 16:51:54 changed by dnicholson@linuxfromscratch.org

  • owner changed from lfs-book@linuxfromscratch.org to dnicholson@linuxfromscratch.org.
  • status changed from new to assigned.

Paul, what distro are you installing from?

03/23/07 18:20:16 changed by bdubbs@linuxfromscratch.org

  • milestone changed from 6.2 to 6.3.

03/25/07 18:24:22 changed by Paul Lowman

I am using a build from CoreLinux - now no longer active. I am now using jhalfs with the lfs live CD and it appears to be all ok ..

03/25/07 19:07:02 changed by dnicholson@linuxfromscratch.org

I had a hunch that it was because of the host's /bin/sh since I'd noticed some problems with that in a different context, but you should be using bash at that point if /tools/bin is at the front of your path.

I'd appreciate if you could help debug this since I can't reproduce it and there's another person with the same problem. Could you run this command before the build and log the output?

sed -i 's/^\([[:space:]]*\)@/\1/' Makefile.SH

That will cause make not to suppress the output from some commands. Hopefully the sed from CoreLinux can handle that, but I can't see why it shouldn't.

03/25/07 19:07:53 changed by dnicholson@linuxfromscratch.org

I meant log the output from make, not from the sed :)

03/25/07 20:22:00 changed by Paul Lowman

  • attachment perl_make.log added.

stdout

03/25/07 20:22:20 changed by Paul Lowman

  • attachment perl_make_errors.log added.

stderr

03/25/07 20:22:50 changed by Paul Lowman

Here are the outputs from the make after executing the sed command.

03/25/07 20:34:15 changed by dnicholson@linuxfromscratch.org

Looks like it fails silently. Thanks, perl! In the future, you can redirect one of the streams onto the other so that it comes out in a single stream. Here's one way:

do something > logfile 2>&1

Next question. After it fails, what happens if you just try to run the command on your own? What about if you remove the lib/auto directory first?

sh ./makedir lib/auto
echo $?

03/25/07 21:20:45 changed by Paul Lowman

the command returns an error of 1

the following works ...

mkdir lib/auto

also makedir works when root ...

the permissions of $LFS/sources/perl-5.8.8 all seem to be OK.

03/25/07 21:27:04 changed by dnicholson@linuxfromscratch.org

Right, something in their shell script makedir is failing. In the end, the workaround might just be to mkdir -p lib/auto before make, but I'd like to know what the issue is. In the same circumstances as before, what happens when you turn on tracing in the shell?

sh -x ./makedir lib/auto
echo $?

If you could attach the output from the 'sh -x' call, that would be great.

Also, did you mean that just running ./makedir worked, or that calling mkdir worked?

03/25/07 21:33:16 changed by Paul Lowman

  • attachment shell.trace added.

03/25/07 21:34:51 changed by Paul Lowman

./makedir works as root mkdir works as lfs

shell.trace attached ...

03/25/07 23:00:13 changed by dnicholson@linuxfromscratch.org

Interesting. For some reason, the for loop at the end of ./makedir doesn't work correctly. It ends up running mkdir with no arguments and failing.

When you are the lfs user, you have /tools/bin at the beginning of your path, right? What do you get when running "which sh"?

03/25/07 23:36:07 changed by Paul Lowman

lfs:~$ which sh /tools/bin/sh

03/25/07 23:39:40 changed by dnicholson@linuxfromscratch.org

OK. I think there's something wrong with the bash that you built. Try this test case.

$ cat > test.sh << "EOF"
set ./lib ./lib/auto
for dir do
  echo $dir
done
EOF
$ /tools/bin/sh -x ./test.sh

It should echo ./lib and ./lib/auto on separate lines with some tracing output.

03/25/07 23:40:10 changed by dnicholson@linuxfromscratch.org

Could you also execute the test script as "/tools/bin/bash -x ./test.sh"?

03/25/07 23:44:04 changed by Paul Lowman

[~]# /tools/bin/sh -x ./test.sh + set ./lib ./lib/auto + for dir in '""' + echo

03/25/07 23:56:38 changed by dnicholson@linuxfromscratch.org

Now that is peculiar and it's a bug in bash. My next guess is, what version of bison does your host have? From my look at the bash sources, the parser that defines this behavior is created by bison. You can get this by running "bison --version" from the host.

03/26/07 14:35:41 changed by Paul Lowman

Bison version is 1.75

04/13/07 15:55:31 changed by dnicholson@linuxfromscratch.org

On the support list, we were able to confirm that this is a bison issue. He also had bison-1.75, and updating his host to bison-2.2 solved the issue. I still have track down what the minimum required version is. I suspect 2.0.

http://linuxfromscratch.org/pipermail/lfs-support/2007-April/032888.html
http://linuxfromscratch.org/pipermail/lfs-support/2007-April/032909.html

The development book needs to have the host reqs page adjusted, and stable needs an errata entry (a more accurate one, anyway).

04/14/07 03:32:30 changed by manuel@linuxfromscratch.org

With Bison-1.875a (using LFS-6.0 as host) Perl builds fine.

04/14/07 10:21:41 changed by dnicholson@linuxfromscratch.org

Thanks, Manuel. I confirm that bash is broken with bison-1.75, but works with bison-1.875 and bison-2.0.

Can anyone remind me the story of bison 1.875a vs. 1.875? Is it acceptable to list 1.875 as the minimum version?

04/14/07 22:50:29 changed by alexander@linuxfromscratch.org

The story is that Bison 1.875 could not generate valid C++ parsers. This was first discovered when building OpenOffice.org, the BLFS book even contained a note that the reader must downgrade Bison to 1.75 to avoid the error.

04/16/07 14:24:40 changed by matthew@linuxfromscratch.org

  • status changed from assigned to closed.
  • resolution set to fixed.

Fixed in r8066.

10/05/07 07:53:16 changed by jhuntwork@linuxfromscratch.org

  • milestone deleted.

Milestone 6.3 deleted