Bug#773300: Improve glibc bootstrap
In the mean time, the other patch #766877 was merged into experimental.
Time to review this bug. Unfortunately, the original submission lacks
details on what problems are being solved, so assessing the solutions is
difficult and I do not understand all the aspects.
| diff -urN debian/rules /usr/src/glibc/debian/rules
| --- debian/rules 2015-03-18 11:08:54.000000000 +0000
| +++ /usr/src/glibc/debian/rules 2015-05-10 07:31:39.000000000 +0000
| @@ -140,8 +140,12 @@
| endif
| endif
|
| +ifeq ($(DEB_STAGE),stage2)
| + DEB_BUILD_PROFILES+=stage2
| +endif
| +
Do we still want to support DEB_STAGE or DEB_BUILD_PROFILE? Maybe we can
just remove support for these variables in 2.21 entirely?
| ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
| - DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev
| + DEB_ARCH_REGULAR_PACKAGES = $(libc)-dev $(libc)
I still disagree with this approach. The underlying problem is that
currently the resulting libc-dev packages from stage1 cannot be
installed, because they depend on libc packages that are not built in
stage1. I think that generating empty libc packages is wrong and that
the dependencies should be dropped in stage1 instead.
| DEB_INDEP_REGULAR_PACKAGES =
| DEB_UDEB_PACKAGES =
| else
| diff -urN debian/rules.d/build.mk /usr/src/glibc/debian/rules.d/build.mk
| --- debian/rules.d/build.mk 2015-03-19 20:28:42.000000000 +0000
| +++ /usr/src/glibc/debian/rules.d/build.mk 2015-05-10 07:31:39.000000000 +0000
| @@ -160,10 +160,19 @@
| cross-compiling=yes install_root=$(CURDIR)/debian/tmp-$(curpass) \
| install-bootstrap-headers=yes install-headers )
|
| - install -d $(CURDIR)/debian/tmp-$(curpass)/lib
| - install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o $(CURDIR)/debian/tmp-$(curpass)/lib
| - ${CC} -nostdlib -nostartfiles -shared -x c /dev/null \
| - -o $(CURDIR)/debian/tmp-$(curpass)/lib/libc.so
| + install -d $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
| + install -m 644 $(DEB_BUILDDIR)/csu/crt[1in].o $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)
| + $(call xx,CC) -nostdlib -nostartfiles -shared -x c /dev/null \
| + -o $(CURDIR)/debian/tmp-$(curpass)/$(call xx,libdir)/libc.so
Fixed in experimental.
| + if [ $(curpass) = libc ]; then \
| + mkdir -p debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/bits debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/gnu debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/sys debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/fpu_control.h debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/a.out.h debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + mv debian/tmp-$(curpass)/usr/include/ieee754.h debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
| + fi
I would appreciate an explanation on what problem this hunk solves.
| else
| : # FIXME: why just needed for ARM multilib?
| case "$(curpass)" in \
| diff -urN debian/rules.d/debhelper.mk /usr/src/glibc/debian/rules.d/debhelper.mk
| --- debian/rules.d/debhelper.mk 2015-03-19 22:15:39.000000000 +0000
| +++ /usr/src/glibc/debian/rules.d/debhelper.mk 2015-05-10 12:12:25.937141495 +0000
| @@ -109,7 +109,8 @@
| ./debian/shlibs-add-udebs $(curpass)
|
| dh_installdeb -p$(curpass)
| - dh_shlibdeps -p$(curpass)
| + [ -n "$$(echo $(curpass) | grep 'mips32')" ] && o32_libs="-l$(CURDIR)/debian/$(curpass)/libo32/"; \
| + dh_shlibdeps $$o32_libs -p$(curpass)
Why does this special case mips32? Would it be possible to solve this
issue for more architectures by relying on slibdir instead?
| dh_gencontrol -p$(curpass)
| if [ $(curpass) = nscd ] ; then \
| sed -i -e "s/\(Depends:.*libc[0-9.]\+\)-[a-z0-9]\+/\1/" debian/nscd/DEBIAN/control ; \
| @@ -179,7 +180,7 @@
|
| # Generate common substvars files.
| : > tmp.substvars
| -ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
| +ifeq ($(filter stage1 stage2,$(DEB_BUILD_PROFILES)),)
| echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4 [hppa]' >> tmp.substvars
| endif
The gcc stage2 (which can be built with glibc stage1 packages) includes
libgccN packages. Thus the dependency is satisfiable in stage2. Dropping
it here should not be necessary and I think it also is wrong.
|
| @@ -197,9 +198,20 @@
| slibdir=$(call xx,slibdir) ; \
| rtlddir=$(call xx,rtlddir) ; \
| curpass=$(curpass) ; \
| - templates="libc-dev" ;\
| - pass="" ; \
| - suffix="" ;\
| + templates="libc-dev" ; \
| + case "$$curpass:$$slibdir" in \
| + libc:*) \
| + suffix="" \
| + pass="" \
| + ;; \
| + *:/lib32 | *:/lib64 | *:/libo32 | *:/libx32 | *:/lib/arm-linux-gnueabi*) \
| + suffix="-$(curpass)" \
| + pass="-alt" \
| + ;; \
| + *:*) \
| + templates="" ; \
| + ;; \
| + esac ; \
| for t in $$templates ; do \
| for s in debian/$$t$$pass.* ; do \
| t=`echo $$s | sed -e "s#libc\(.*\)$$pass#$(libc)\1$$suffix#"` ; \
| @@ -210,10 +222,11 @@
| sed -e "s#RTLDDIR#$$rtlddir#g" -i $$t; \
| sed -e "s#SLIBDIR#$$slibdir#g" -i $$t; \
| sed -e "s#LIBDIR#$$libdir#g" -i $$t; \
| + sed -e "s#MULTIARCHDIR#$$DEB_HOST_MULTIARCH#g" -i $$t ; \
| done ; \
| - done
| + done; \
| + sed -e "/.*.a /d" -i debian/$(libc)-dev$$suffix.install
|
| - sed -e "/$$libdir.*.a /d" -i debian/$(libc)-dev.install
| else
| $(patsubst %,debhelper_%,$(GLIBC_PASSES)) :: debhelper_% : $(stamp)debhelper_%
| $(stamp)debhelper_%: $(stamp)debhelper-common $(stamp)install_%
Fixed in experimental.
| diff -urN debian/sysdeps/linux.mk /usr/src/glibc/debian/sysdeps/linux.mk
| --- debian/sysdeps/linux.mk 2015-03-16 16:03:45.000000000 +0000
| +++ /usr/src/glibc/debian/sysdeps/linux.mk 2015-05-10 22:20:49.109875755 +0000
| @@ -16,7 +16,7 @@
| endif
|
| ifndef LINUX_SOURCE
| - ifeq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
| + ifeq ($(shell dpkg-query --status linux-libc-dev-$(DEB_HOST_ARCH)-cross 2>/dev/null),)
| LINUX_HEADERS := /usr/include
| else
| LINUX_HEADERS := /usr/$(DEB_HOST_GNU_TYPE)/include
I'm not sure that the test covers all relevant cases, but I have been
using the very same test in rebootstrap with success. Without this hunk,
cross building glibc will not find linux headers when
linux-libc-dev:$(DEB_HOST_ARCH) is installed.
So it looks like roughly a third of the issues are fixed in
experimental.
Helmut
Reply to: