Re: Bug#717557: gcc-4.8: can't compile working 64bit kernel with 32bit userspace gcc-4.8

2013-10-20 Thread Matthias Klose
Am 20.10.2013 22:58, schrieb Ben Hutchings:
 On Sun, 2013-10-20 at 22:21 +0200, Matthias Klose wrote:
 Am 20.10.2013 00:25, schrieb Ben Hutchings:
 On Sat, 2013-10-19 at 23:38 +0200, Matthias Klose wrote:
 Control: severity -1 important Control: tags -1 + moreinfo
 
 In file included from command-line:0:0: 
 /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h:
 No such file
 or directory
 #include bits/predefs.h ^
 compilation terminated.
 
 It looks like I can avoid this by changing the compile tests to
 use the -nostdinc option.  But this change may possibly cause
 other problems, and neither the pre-included header nor the fact
 that -nostdinc disables it seem to be documented.
 
 please attach the test program and the command line options used for
 this test case.  I think the issue is within the kernel build system
 not being prepared for multiarch and -nostdinc.
 
 gcc-4.8 -m64 -x c -c /dev/null
 
 works for me on a current sid/i386. I assume that gcc-4.8-multilib is
 installed?
 
 No, it works if that's installed.  But gcc-X.Y-multilib was previously only
 needed for building with a 64-bit C library, not for building a 64-bit
 kernel.
 
 If this kernel configuration was actually failing to build without 
 gcc-4.8-multilib, I wouldn't mind so much.  The problem is that it's built
 wrongly now.  Maybe some later version of the kernel will be changed to
 detect or work around this problem, but we have to assume people will still
 try to build older versions not using -nostdinc for some time to come.

Is this due to the missing /usr/include/asm symlink shipped in gcc-multilib?
It's not ideal, and I think I did file a bug report that this should be
shipped in one of the glibc packages, but can't find it anymore.

 The options to deal with this include: 1. Make missing headers non-fatal
 while pre-including stdc-predef.h.

that would be the responsibility of those packages using non-standard options
like -nostdinc.

 2. Disable pre-inclusion of stdc-predef.h.

no, done upstream to conform to standards.

 3. Make 32-bit gcc fail to compile anything with -m64 if gcc-X.Y-multilib
 is not installed, even if -nostdinc is used.

welcome to multiarch, and thanks for upstreaming patches to fix these issues.

 4. Make gcc-X.Y depend on gcc-X.Y-multilib on architectures where it 
 exists.

well, then you can merge these again. the whole point to have them separate
were bug reports about being forced to install the non-defaults multilibs by
default.

5. Install the whole glibc headers into the multiarch header path. Would fix
some other things too, like allowing multiarch configurations for non-glibc
based triplets. And I assume it would allow your build to fail.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52644ed0.60...@debian.org



Re: Bug#717557: gcc-4.8: can't compile working 64bit kernel with 32bit userspace gcc-4.8

2013-10-20 Thread Ben Hutchings
On Sun, 2013-10-20 at 23:44 +0200, Matthias Klose wrote:
 Am 20.10.2013 22:58, schrieb Ben Hutchings:
  On Sun, 2013-10-20 at 22:21 +0200, Matthias Klose wrote:
  Am 20.10.2013 00:25, schrieb Ben Hutchings:
  On Sat, 2013-10-19 at 23:38 +0200, Matthias Klose wrote:
  Control: severity -1 important Control: tags -1 + moreinfo
  
  In file included from command-line:0:0: 
  /usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h:
  No such file
  or directory
  #include bits/predefs.h ^
  compilation terminated.
  
  It looks like I can avoid this by changing the compile tests to
  use the -nostdinc option.  But this change may possibly cause
  other problems, and neither the pre-included header nor the fact
  that -nostdinc disables it seem to be documented.
  
  please attach the test program and the command line options used for
  this test case.  I think the issue is within the kernel build system
  not being prepared for multiarch and -nostdinc.
  
  gcc-4.8 -m64 -x c -c /dev/null
  
  works for me on a current sid/i386. I assume that gcc-4.8-multilib is
  installed?
  
  No, it works if that's installed.  But gcc-X.Y-multilib was previously only
  needed for building with a 64-bit C library, not for building a 64-bit
  kernel.
  
  If this kernel configuration was actually failing to build without 
  gcc-4.8-multilib, I wouldn't mind so much.  The problem is that it's built
  wrongly now.  Maybe some later version of the kernel will be changed to
  detect or work around this problem, but we have to assume people will still
  try to build older versions not using -nostdinc for some time to come.
 
 Is this due to the missing /usr/include/asm symlink shipped in gcc-multilib?
 It's not ideal, and I think I did file a bug report that this should be
 shipped in one of the glibc packages, but can't find it anymore.

The /usr/include/bits symlink in libc6-dev-amd64 is what makes this work
again (which is disgusting, really...).  Without that, stdc-predef.h can
be found but not bits/predefs.h.

  The options to deal with this include: 1. Make missing headers non-fatal
  while pre-including stdc-predef.h.
 
 that would be the responsibility of those packages using non-standard options
 like -nostdinc.

Well the problem occurs because Linux uses -nostdinc only in the real
compiles (so they succeed) but not the test compiles (so they fail).

  2. Disable pre-inclusion of stdc-predef.h.
 
 no, done upstream to conform to standards.
 
  3. Make 32-bit gcc fail to compile anything with -m64 if gcc-X.Y-multilib
  is not installed, even if -nostdinc is used.
 
 welcome to multiarch, and thanks for upstreaming patches to fix these issues.
 
  4. Make gcc-X.Y depend on gcc-X.Y-multilib on architectures where it 
  exists.
 
 well, then you can merge these again. the whole point to have them separate
 were bug reports about being forced to install the non-defaults multilibs by
 default.

Indeed, I didn't say any of those options were good.

 5. Install the whole glibc headers into the multiarch header path. Would fix
 some other things too, like allowing multiarch configurations for non-glibc
 based triplets. And I assume it would allow your build to fail.

I don't think this would help.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.


signature.asc
Description: This is a digitally signed message part