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

Re: RFH for cross-building saclib



On 7/7/22 12:19 AM, Helmut Grohne wrote:
On the surface, you shall spot "/usr/bin/ld" here. This is the build
architecture linker (not compiler).

This was my first suspicion (since this sounded like /usr/bin/gcc sort of thing)
but I grepped similar patterns on codesearch.debian.net and found those packages
going green on crossqa.d.n and thought maybe this isn't right.

Since the variable for ld is not
entirely standardized, build systems occasionally fail to pick up the
right value.

This statement of yours is the crux here, Thanks!

In a later mail, you hint that you are using libtool. So I said
[snip]
    your path and this libtool assumes that build architecture equals
    host architecture. This is impossible to use with cross building.
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I see.

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.

Sure, I checked this earlier but since I saw it trying to build on salsa
CI, I ignored it for a bit since the dependency could be satisfied per se,
but now I see the picture. I wonder if the wording for such cases on crossqa could be made
a little clearer or maybe if there could be an explanation linked.

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.

Yep. I even saw a few BRs from you doing this.

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.

Got it.

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.

Yes, Sure, thanks a lot for nice and verbose explanation!

--
Best,
Nilesh

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: