[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

kernel build version dependency and NPTL support

I found NPTL/buildd kernel mismatch problem today when I saw the s390
build log failure at

	/build/buildd/glibc-2.3.5/build-tree/s390-nptl/elf/ld.so.1 --library-path ... /build/buildd/glibc-2.3.5/build-tree/s390-nptl/timezone/zic -d /build/buildd/glibc-2.3.5/debian/tmp-nptl/usr/share/zoneinfo -L /dev/null -y ./yearistype africa
	FATAL: kernel too old
	make[3]: *** [/build/buildd/glibc-2.3.5/debian/tmp-nptl/usr/share/zoneinfo/Africa/Algiers] Error 1
	Build finished at 20050819-1021
	FAILED [dpkg-buildpackage died]

"FATAL: kernel too old" is barfed by ld.so.  It refuses to execute on
old kernel 2.4.  I guess the s390 buildd debian01 uses 2.4 kernel.
ld.so built with NPTL requires 2.6 kernel, because using NPTL requires
2.6 kernel, and ld.so checks such minimum supported kernel version
which is defined as 2.6 and decided by build time.

I don't want to use "make -k" to build glibc, we should build
glibc/s390 on 2.6 kernel.  I don't also want to modify glibc/s390
package to work on 2.4 kernel - the current ld.so refusal is natural

In future, we'll add more NPTL supported architecture.  However if
some buildd on that architectures are kernel 2.4, we can't generate
such packages.  To fix this problem, we need to choose the below two
different approaches:

  (1) All buildd should go to 2.6 kernel.

  (2) Gentoo's package has kernel version dependency, but we debian
      does not have it.  So I would like to propose that each debian
      package that depends on the environmental factor should have
      explicit specifier.  For example, glibc debian/control has
      "Build-Env-Depends: kernel-2.6".

Buildd teams, release managers, and glibc teams, how do you deal with
this problem?  Any comments are welcome.

BTW, note that I can access to kernel 2.6 s390 machine - I'll upload
glibc 2.3.5-4 on s390 by hand.

-- gotom

Reply to: