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

Re: RFH for cross-building saclib



Hi Nilesh,

I see you've expended quite a bit of mails on this already and as far as
I understand it, most of you missed the core issue. :-/

On Wed, Jul 06, 2022 at 01:30:21PM +0530, Nilesh Patra wrote:
> I was trying to make saclib cross-buildable, as per the failure in salsa-CI[1]
> it seems to stem from CC being set to build compiler rather than the host in d/rules.

Thank you!

> I went ahead and did a "include /usr/share/dpkg/buildtools.mk".
> However, while linking, it chokes at:
> 
> | /usr/bin/ld: .libs/AADV.o: Relocations in generic ELF (EM: 183)
> | /usr/bin/ld: .libs/AADV.o: Relocations in generic ELF (EM: 183)
> | /usr/bin/ld: .libs/AADV.o: Relocations in generic ELF (EM: 183)
> | /usr/bin/ld: .libs/AADV.o: Relocations in generic ELF (EM: 183)
> | /usr/bin/ld: .libs/AADV.o: Relocations in generic ELF (EM: 183)
> | /usr/bin/ld: .libs/AADV.o: error adding symbols: file in wrong format
> 
> I cross-checked, and this file is compiled with the right compiler.
> And I am not entirely sure of the cross for this error, and would appreciate hints.

On the surface, you shall spot "/usr/bin/ld" here. This is the build
architecture linker (not compiler). Since the variable for ld is not
entirely standardized, build systems occasionally fail to pick up the
right value.

In a later mail, you hint that you are using libtool. So I said
"apt-cache showsrc saclib" and it said:

| ...
| Build-Depends: debhelper-compat (= 13), libtool-bin, texlive-latex-base
| ...

libtool-bin is the thing you need to spot here. There are two ways of
using libtool in Debian.

1. "The normal way": You depend on libtool (not libtool-bin). Thus there
   is no libtool on your $PATH. To get one, you need to libtoolize and
   configure. Configure creates a libtool specifically for your build
   and this libtool knows about build architecture and host
   architecture. All is fine.
2. "The broken way": You depend on libtool-bin. This pulls a libtool on
   your path and this libtool assumes that build architecture equals
   host architecture. This is impossible to use with cross building.

So whenever you see libtool-bin in your Build-Depends, you can
immediately conclude that your package isn't cross buildable.  If you
look at https://crossqa.debian.net/src/saclib, you'll also notice
something strange. It says "missing libtool-bin" and never tried to
build it. I masked the libtool-bin dependency in the analysis to avoid a
few failing builds.  Your goal should be reducing that libtool-bin
dependency to plain libtool.  That's moving from the second way to the
first way. Quite obviously, we want to remove libtool-bin from the
archive eventually. Historically libtool-bin was part of libtool. We
split it out of libtool, because /usr/bin/libtool violates Multi-Arch:
foreign. See also #836123 for a little more background. When developing
the move from libtool-bin to libtool, you can use native building. Once
it builds natively with libtool rather than libtool-bin, you can look
into cross building.

Now as I look into saclib's git on salsa, I see that you did just that.
It was the right thing to do. Now you may have a better understanding
for why.

Helmut


Reply to: