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

[Philippe Thierry]

Le 31/08/2017 à 21:58, Aaron M. Ucko a écrit :

> Great, thanks for looking into all of these subissues!
>
Well... sorry for the false positive news but wsh needs big update to
support other arches.
It is based on a ldscript used to map relocated content which is arch
specific. This ldscript has been made only for amd64.
I can try to make one or two more, but not for all the arches !

I will push an issue to Jonathan in mainstream to discuss this with him.
It would be great to have at least arm* & powerpc (personal choice of
course :) )

In the meantime, I've updated to amd64 only. it should work on
hurd/kfreebsd now.

-- 
 OPhilippe Thierry.
/Y\/  Hardened embedded systems
o#o   GPG: 7010 9A3C E210 763E 6341  4581 C257 B91B CDAF C1EA




signature.asc
Description: OpenPGP digital signature

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

[Aaron M. Ucko]

Philippe Thierry  writes:

> I will make some more tests on various arches including CI). If
> everything is okay I update the package.

Great, thanks for looking into all of these subissues!

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

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

[Philippe Thierry]

Le 31/08/2017 à 05:10, Aaron M. Ucko a écrit :
> 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.
Should be corrected by last update using libopenlibm-dev from Debian.
For non-Linux, I've updated to Architecture: linux-any by  now. I'll
check for Freebsd & Hurd in the meantime.
>
> On non-Linux architectures (kFreeBSD and presumably also the Hurd if
> and when clang becomes installable there), there's no 
> 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.
I will make some more tests on various arches including CI). If
everything is okay I update the package.

Cheers,

-- 
 OPhilippe Thierry.
/Y\/  Hardened embedded systems
o#o   GPG: 7010 9A3C E210 763E 6341  4581 C257 B91B CDAF C1EA




signature.asc
Description: OpenPGP digital signature

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

[Philippe Thierry]

Le 31 août 2017 05:10:10 GMT+02:00, "Aaron M. Ucko"  a écrit :
>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 
>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!

Hello Aaron, 

Thanks for the report ! 

I'll update the package to use the packaged libopenlibm-dev.
For the elf-em.h, I'll check for the corresponding file in Freebsd and Hurd and 
add some preprocessing to support all of them. 

I'll test on arm, but I dunno if there is a debomatic for others arches than 
amd64. If you know if there is such testbed, it would be great. 
-- 
 O   Philippe Thierry. 
/Y\/   GPG: 7010 9a3c e210 763e 6341 4581 c257 b91b cdaf c1ea
o#o   (sent from my smartphone)

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

[Aaron M. Ucko]

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 
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/?a...@monk.mit.edu