Glibc fails to build using dash

[Matthew Burgess]

Ubuntu is now linking /bin/sh to /bin/dash rather than bash. This causes the building of Glibc in chapter 5 to fail as detailed in the thread at ​http://www.linuxfromscratch.org/pipermail/lfs-support/2007-February/032550.html.

It looks as though we've got 3 options:

1) Issue `make SHELL=/bin/bash' in chapter 5's Glibc 2) Document this requirement explicitly in the host requirements section. If folks end up on lfs-support complaining that Glibc didn't build right and they're not using bash we just quote from Mr. Drepper! 3) Investigate exactly what is causing issues with Glibc's builds with dash. Is it that Glibc is using bashisms or is it that Glibc is using valid POSIX syntax that dash doesn't handle correctly?

I personally prefer option 1 as it's a bit kinder to our users. If we can avoid build breakage and having our users jump through hoops to get their shell changed from the system default, I think we should.

I don't mind option 2 if that gets the group vote.

Option 3 may well end up at a dead end if the issue lies with Glibc as the upstream maintainers don't support building under any other shell than bash (see ​http://sourceware.org/bugzilla/show_bug.cgi?id=2930 and ​http://sourceware.org/bugzilla/show_bug.cgi?id=3266). In this case, maybe someone would like to come up with a patch to the ./configure, FAQ and INSTALL files to explicitly document this requirement? :-)

[ken@…]

Re option 3 - The problem was that version-info.h contained

"Compiled on a Linux 2.6.12 system on 2007-02-14.\n"
"Available extensions:
"

(note these lines are missing their ending '\n"')

which comes from (line wrapped when I originally posted it from my own log)

 files="../libio/Banner ../crypt/Banner ../libidn/Banner
../nptl/Banner ../resolv/Banner ../nis/Banner";
\
 if test -n "$files"; then                              \
   echo "\"Available extensions:\\n\"";                 \
                            ^^^^^^^^^

   sed -e '/^#/d' -e 's/^[[:space:]]*/  /'              \
       -e 's/^\(.*\)$/\"\1\\n\ fi) > /usr/src/glibc-build/csu/version-info.hT
mv -f /usr/src/glibc-build/csu/version-info.hT
/usr/src/glibc-build/csu/version-info.h
"/' $files;               \

So, it seems to be dash's 'echo' command which is the problem. I think I've seen something similar from an unpatched bash-3.1 on my own builds.

Personally, I prefer option 1.

[dnicholson@…]

Replying to ken@linuxfromscratch.org:

So, it seems to be dash's 'echo' command which is the problem. I think I've seen something similar from an unpatched bash-3.1 on my own builds.

Yeah. I'm playing around with it right now for jhalfs. echo behaves differently than bash. It actually behaves the similarly to the Bourne sh where the escape sequences are always interpreted. I don't know how POSIX sh is supposed to behave.

I also agree with option 1. We shouldn't have to make people alter their systems more than we have to.

[Matthew Burgess]

Dash advertises itself as a POSIX compatible shell at ​http://gondor.apana.org.au/~herbert/dash/. POSIX states:

The following operands shall be supported:

string

A string to be written to standard output. If the first operand is -n, or if any of the operands contain a backslash ( '\' ) character, the results are implementation-defined.

Backslash escape sequences, such as '\n' are an XSI extension. Assuming Dash is POSIX-only and therefore doesn't implement any XSI extensions, any escape sequences can be treated however Dash sees fit.

Note that under "Application Usage", POSIX says:

It is not possible to use echo portably across all POSIX systems unless both -n (as the first argument) and escape sequences are omitted.

Patching Glibc to fix these issues is trivial in this case:

echo "\"Available extensions:\\n\"";

becomes

echo '"Available extensions:';
echo '"'

Note that POSIX also recommends:

New applications are encouraged to use printf instead of echo.

In which case, this becomes:

printf "%s\n" '"Available extensions:\n"'

All of this is purely for information only though, as I'm sure there are many other cases of non-POSIX syntax in Glibc's sources and they won't entertain such patches anyway.

We'll just go with option number 1 and pass "SHELL=/bin/bash" through to Glibc's make processes. If any other packages show similar issues, the same workaround can be applied to them too, making it nice and consistent.

[dnicholson@…]

I'm not sure it's really needed, but we should probably passing in SHELL whenever we issue make for glibc in pass1.

[Matthew Burgess]

I'm marking this as invalid as it doesn't affect svn trunk. The problematic 'echo' statement that Ken pointed to is already a 'printf' in glibc-2.5, which fixes things up nicely (I didn't have the sources to hand when I went on my POSIX crusade earlier on!).

This is what I get on my Kubuntu-6.10 box:

$ cat csu/version-info.h
"Compiled on a Linux >>2.6.17-11-generic<< system on 2007-02-15.\n"
"Available extensions:\n"
"       crypt add-on version 2.1 by Michael Glad and others\n"
"       GNU libio by Per Bothner\n"
"       NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk\n"
"       Native POSIX Threads Library by Ulrich Drepper et al\n"
"       BIND-8.2.3-T5B\n"

[dnicholson@…]

I'm reopening the ticket against version 6.2 as a reminder to add this info to the errata.

[dnicholson@…]

Fixed in r852 on the website.

​http://www.linuxfromscratch.org/lfs/errata/stable/

[dnicholson@…]

I should probably mention that I did test the fix suggested, and I think Matthew did, too. A discussion took place on the alfs list.

​http://linuxfromscratch.org/pipermail/alfs-discuss/2007-February/009151.html