lib-gpgerror cross compile ignore 2nd component of host for lock header?
Closed, ResolvedPublic

Description

Hello,

As far as I can see when building using cross compile the
src/syscfg/lock-obj-pub.@HOST@.h is included for platform specific declaration.

I understand that out of @HOST@ the arch(1), os(3) and libc(4) are important.

But what about making the sub architecture? the 2nd part, maybe it can be
ignored, for example unknown_softfloat or pc vs unknown or ibm.

This will enable higher chance of successfully build package using a cross
compiler using the already generated includes.

Thanks,

Details

alonbl set Version to 1.15.Oct 21 2014, 12:26 AM
alonbl added projects: Bug Report, Gentoo, gpgrt.
alonbl added a subscriber: alonbl.
werner added a subscriber: werner.Oct 25 2014, 2:54 PM

But that also introduces a new class of bugs. I think it is easier to simply
add a new file. If it eventually turns out that we have too many identical
files, we can change that by adding a mapping table to mkheader.

I try to imagine where the subarch can cause an issue, maybe a big fat warning
when mapping should be sufficient at this point?

For now I will add a note for everyone that opens a bug for this reason to
duplicate the unknown subarch into his own, package will not be compiled
automatically for these.

Thanks!

FWIW, meanwhile there is a mapping table in src/mkheader.c:canon_host_triplet.

werner closed this task as Resolved.Aug 26 2015, 8:24 AM
werner claimed this task.

Thanks, but I do not understand the comment, do you suggest to patch this file
with every subarch out there? I still trying to understand why subarch is
important for the processing, it is a generic string.

alonbl reopened this task as Open.Aug 29 2015, 8:15 PM

Yes.
I doubt that the subarch always uses the same ABI.

Maybe add configure parameter to ignore subarch for 99% of cases in which it
does not matter? This will avoid patching in most of the cases.

alonbl closed this task as Resolved.Aug 30 2015, 9:56 PM
alonbl set External Link to https://bugs.gentoo.org/show_bug.cgi?id=526146.Sep 11 2015, 9:02 PM