Bug#873783: wcc: FTBFS on non-amd64 architectures

Aaron M. Ucko ucko at debian.org
Thu Aug 31 03:10:10 UTC 2017


Source: wcc
Version: 0.0.2+dfsg-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of wcc for architectures other than (Linux) amd64 have been
failing.

On non-x86 architectures, there are two considerations: the
embedded copy of openlibm under src/wsh generally has no
$(ARCH)/Make.files, and GCC doesn't support -masm=intel regardless.
You could sidestep the former by building against separately packaged
libopenlibm-dev (as called for by Policy 4.13), but the latter may be
more of a problem.

On non-Linux architectures (kFreeBSD and presumably also the Hurd if
and when clang becomes installable there), there's no <linux/elf-em.h>
for arch.h to include.

On i386, wsh somehow winds up compiled for the wrong architecture,
leading to link errors:

  /usr/bin/ld: skipping incompatible /usr/lib/gcc/i686-linux-gnu/7/../../../i386-linux-gnu/libiberty.a when searching for -liberty
  /usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu/libiberty.a when searching for -liberty
  /usr/bin/ld: cannot find -liberty

On x32 (admittedly not a release architecture), wcc is still in the
Needs-Build queue; I'm not sure what will happen there.

At any rate, I'm reporting this as a single bug because I suspect you
may just want to declare Architecture: amd64 (with the possible
addition of x32) and be done with it.  That said, you're certainly
welcome to address any or all of these portability issues if feasible.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu



More information about the Pkg-security-team mailing list