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

Bug#872891: gcc-multilib conflicts with GCC cross toolchains



Hi, 

in 2017, Matthias Klose marked this bug as wontfix, and explained the
problem like this:

> because the cross toolchain has /usr/include on it's include path,
> which has incompatible header files: /usr/include/asm.

Is that still the case, a few years later? I have an x86_64 machine with
debian buster + gcc-10 and cross compilers from "bullseye" (testing),
and no /usr/include/asm at all. I have the following gcc packages
installed:

ii  gcc                                   4:10.1.0-1     amd64        GNU C compiler
ii  gcc-10                                10.2.0-7       amd64        GNU C compiler
ii  gcc-10-arm-linux-gnueabihf            10.2.0-3cross2 amd64        GNU C compiler (cross compiler for armhf architecture)
ii  gcc-10-arm-linux-gnueabihf-base:amd64 10.2.0-3cross2 amd64        GCC, the GNU Compiler Collection (base package)
ii  gcc-10-base:amd64                     10.2.0-7       amd64        GCC, the GNU Compiler Collection (base package)
ii  gcc-10-base:armhf                     10.2.0-7       armhf        GCC, the GNU Compiler Collection (base package)
ii  gcc-10-cross-base                     10.2.0-3cross2 all          GCC, the GNU Compiler Collection (library base package)
ii  gcc-10-i686-linux-gnu                 10.2.0-3cross2 amd64        GNU C compiler (cross compiler for i386 architecture)
ii  gcc-10-i686-linux-gnu-base:amd64      10.2.0-3cross2 amd64        GCC, the GNU Compiler Collection (base package)
ii  gcc-10-multilib                       10.2.0-7       amd64        GNU C compiler (multilib support)
ii  gcc-10-multilib-i686-linux-gnu        10.2.0-3cross2 amd64        GNU C compiler (multilib support) (cross compiler for i386 architecture)
ii  gcc-8                                 8.4.0-4        amd64        GNU C compiler
ii  gcc-8-base:amd64                      8.4.0-4        amd64        GCC, the GNU Compiler Collection (base package)
ii  gcc-9-base:amd64                      9.3.0-18       amd64        GCC, the GNU Compiler Collection (base package)
ii  gcc-arm-linux-gnueabihf               4:10.1.0-1     amd64        GNU C compiler for the armhf architecture
ii  gcc-i686-linux-gnu                    4:10.1.0-1     amd64        GNU C compiler for the i386 architecture
ii  gcc-mingw-w64                         10.1.0-3+23    all          GNU C compiler for MinGW-w64
ii  gcc-mingw-w64-base                    10.1.0-3+23    amd64        GNU Compiler Collection for MinGW-w64 (base package)
ii  gcc-mingw-w64-i686                    10.1.0-3+23    all          GNU C compiler for MinGW-w64 targeting Win32
ii  gcc-mingw-w64-i686-posix              10.1.0-3+23    amd64        GNU C compiler for MinGW-w64, Win32/POSIX
ii  gcc-mingw-w64-i686-posix-runtime      10.1.0-3+23    amd64        GNU Compiler Collection for MinGW-w64, i686/posix
ii  gcc-mingw-w64-i686-win32              10.1.0-3+23    amd64        GNU C compiler for MinGW-w64, Win32/Win32
ii  gcc-mingw-w64-i686-win32-runtime      10.1.0-3+23    amd64        GNU Compiler Collection for MinGW-w64, i686/win32
ii  gcc-mingw-w64-x86-64                  10.1.0-3+23    all          GNU C compiler for MinGW-w64 targeting Win64
ii  gcc-mingw-w64-x86-64-posix            10.1.0-3+23    amd64        GNU C compiler for MinGW-w64, Win64/POSIX
ii  gcc-mingw-w64-x86-64-posix-runtime    10.1.0-3+23    amd64        GNU Compiler Collection for MinGW-w64, x86-64/posix
ii  gcc-mingw-w64-x86-64-win32            10.1.0-3+23    amd64        GNU C compiler for MinGW-w64, Win64/Win32
ii  gcc-mingw-w64-x86-64-win32-runtime    10.1.0-3+23    amd64        GNU Compiler Collection for MinGW-w64, x86-64/win32
ii  gcc-multilib-i686-linux-gnu           4:10.1.0-1     amd64        GNU C compiler for the i386 architecture
ii  lib32gcc-10-dev                       10.2.0-7       amd64        GCC support library (32 bit development files)
ii  lib32gcc-s1                           10.2.0-7       amd64        GCC support library (32 bit Version)
ii  lib64gcc-10-dev-i386-cross            10.2.0-3cross2 all          GCC support library (64bit development files)
ii  lib64gcc-s1-i386-cross                10.2.0-3cross2 all          GCC support library (i386) (64bit)
ii  libgcc-10-dev:amd64                   10.2.0-7       amd64        GCC support library (development files)
ii  libgcc-10-dev-armhf-cross             10.2.0-3cross2 all          GCC support library (development files)
ii  libgcc-10-dev-i386-cross              10.2.0-3cross2 all          GCC support library (development files)
ii  libgcc-8-dev:amd64                    8.4.0-4        amd64        GCC support library (development files)
ii  libgcc-s1:amd64                       10.2.0-7       amd64        GCC support library
ii  libgcc-s1:armhf                       10.2.0-7       armhf        GCC support library
ii  libgcc-s1-armhf-cross                 10.2.0-3cross2 all          GCC support library (armhf)
ii  libgcc-s1-i386-cross                  10.2.0-3cross2 all          GCC support library (i386)
ii  libx32gcc-10-dev                      10.2.0-7       amd64        GCC support library (x32 development files)
ii  libx32gcc-10-dev-i386-cross           10.2.0-3cross2 all          GCC support library (x32 development files)
ii  libx32gcc-s1                          10.2.0-7       amd64        GCC support library (x32)
ii  libx32gcc-s1-i386-cross               10.2.0-3cross2 all          GCC support library (i386) (x32)

I'm trying to compile the following hello.c program:

  #include <stdio.h>
  #include <errno.h>
  int main(int argc, char **argv) { printf("foo\n"); return 0; }

It works fine to compile it using 

  $ i686-linux-gnu-gcc hello.c

and that produces a 32-bit executable. However, with gcc -m32 I get

  $ gcc -m32 hello.c
  In file included from /usr/include/bits/errno.h:26,
                   from /usr/include/errno.h:28,
                   from hello.c:2:
  /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file
  or directory
      1 | #include <asm/errno.h>
        |          ^~~~~~~~~~~~~
  compilation terminated.

(If I delete the errno.h include, it works, so it seems to only be a
problem with certain system header files missing). If I attempt to
solve the problem by installing gcc-multilib using

  # apt-get install -t testing gcc-multilib

it wants to remove the arm and i686 cross compilers (but not the mingw
cross compilers),

  The following packages will be REMOVED:
    gcc-10-arm-linux-gnueabihf gcc-10-i686-linux-gnu gcc-10-multilib-i686-linux-gnu
    gcc-arm-linux-gnueabihf gcc-i686-linux-gnu gcc-multilib-i686-linux-gnu

Regarding the mentioned conflict over /usr/include/asm, I don't have that
directory at all on this machine. Related existing directories are

  /usr/include/asm-generic/ (package linux-libc-dev:amd64)
  /usr/include/x86_64-linux-gnu/asm (also package linux-libc-dev:amd64)
  /usr/i686-linux-gnu/include/asm/ (linux-libc-dev-i386-cross)
  /usr/arm-linux-gnueabihf/include/asm (linux-libc-dev-armhf-cross)

So the files belonging to the cross compiler packages shouldn't be in
the way, as far as I can tell. And I guess the proper location for the
missing asm/errno.h would be in /usr/include/i386-linux-gnu/asm/, but I
haven't been able to find what's the proper package to install to get
that directory (maybe linux-libc-dev:i386, but it's a bit unexpected to
have to add i386 as a foreign architecture just to get gcc -m32 to
work)?

Vagely related, I have duplicate, but not interfering, copies of some
foreign libc library files, e.g, I have both

  /lib/arm-linux-gnueabihf/libc-2.31.so (package libc6:armhf)
  /usr/arm-linux-gnueabihf/lib/libc-2.31.so (package libc6-armhf-cross)

I think the latter is needed by the cross compiler, and the former for
running arm binaries using qemu-arm. That's slightly annoying and a bit
wasted disk usage, but not causing any errors once I realized that both
packages are needed.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.


Reply to: