PlashGlibc build fails on Ubuntu edgy
- Found in: SVN 2008/04/13
CategoryFixed. Fixed in 746 for release 1.19
Steps to reproduce:
sudo python chroot_build.py -t i386-ubuntu-edgy-story6 -a all_steps
Actual result: failure occurs when configuring glibc:
... running configure fragment for sysdeps/i386/elf checking for i386 TLS support... yes running configure fragment for nptl/sysdeps/pthread checking for forced unwind support... ../glibc-source/nptl/sysdeps/pthread/configure: line 67: conftest: command not found no configure: error: forced unwind support is required make: *** [stamp-configure-glibc] Error 1
This happens because glibc/configure is auto-generated at build time by Plash's build-glibc-integrated.sh, which runs autoconf, whereas glibc/nptl/sysdeps/pthread/configure is checked into the Git repository. The former is generated by edgy's version of autoconf, 2.60-1, while the latter was generated from autoconf 2.61, and the two are not compatible.
This problem was encountered by Ryan S. Arnold in a different situation: glibc-2.7 and autoconf 2.61 dependency in libc/nptl/sysdeps/configure
Projects generally take one of two approaches to files generated by autotools:
Generated files are not checked in to the SCM. This is how GNOME projects work. By convention, they have an autogen.sh script which runs autoconf, automake, libtoolize etc. to generate the generated files. This is described in the Autobook in the Bootstrapping section.
- Generated files are checked in to the SCM. This is what glibc does upstream.
The problem has occurred because I accidentally mixed these two approaches when I removed the file glibc/configure in Git. glibc is unusual in having multiple configure.in files scattered through the source tree generating configure fragments. This post -- autoconf-2.52 and configure.in "fragments" -- describes the situation.
There are two ways to fix it:
Remove all generated configure files, and add an autogen.sh script to generate them at build time.
Add glibc/configure back, generating it from autoconf 2.61 under feisty. This is the quick fix.
In the long term I would prefer to take the first approach. Having generated files under version control would make it harder to merge my branch with upstream. However, the autogen.sh script would be non-standard, because it has to deal with multiple configure fragments. This would be fiddly to test with my current build tools (see ContinuousIntegration), which create separate working copies in each chroot. I will apply the quick fix until I have improved the build tools.