Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 584052 - dev-libs/libgpg-error-1.22: cross-compiling fails with "src/syscfg/lock-obj-pub.<tuple>.h': No such file or directory"
Summary: dev-libs/libgpg-error-1.22: cross-compiling fails with "src/syscfg/lock-obj-p...
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Crypto team
URL: https://bugs.gnupg.org/gnupg/issue2370
Whiteboard:
Keywords: PATCH, UPSTREAM
: 593484 653912 670202 680526 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-05-25 02:15 UTC by Peter Levine
Modified: 2019-03-16 11:28 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
dev-libs:libgpg-error-1.22:20160525-020039.log (dev-libs:libgpg-error-1.22:20160525-020039.log,17.20 KB, text/x-log)
2016-05-25 02:17 UTC, Peter Levine
Details
emerge-armv7a-hardfloat-linux-gnueabi --info (emerge-armv7a-hardfloat-linux-gnueabi-info.txt,14.81 KB, text/plain)
2016-05-25 02:18 UTC, Peter Levine
Details
Patch for libgpg-error-1.22.ebuild (libgpg-error-1.22.ebuild.patch,1.62 KB, patch)
2016-05-25 02:25 UTC, Peter Levine
Details | Diff
libgpg-error-1.22-fix-mkheader.patch (libgpg-error-1.22-fix-mkheader.patch,3.56 KB, patch)
2016-05-26 05:31 UTC, Peter Levine
Details | Diff
libgpg-error-link-valid-header.patch (libgpg-error-link-valid-header.patch,3.26 KB, patch)
2016-06-08 04:33 UTC, Peter Levine
Details | Diff
libgpg-error-1.22.ebuild.patch (libgpg-error-1.22.ebuild.patch,597 bytes, patch)
2016-08-23 22:28 UTC, Peter Levine
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Levine 2016-05-25 02:15:56 UTC
Cross-compiling dev-libs/libgpg-error-1.22 (CBUILD="x86_64-pc-linux-gnu" and CHOST="armv7a-hardfloat-linux-gnueabi") fails with:

/usr/armv7a-hardfloat-linux-gnueabi/var/tmp/portage/dev-libs/libgpg-error-1.22/work/libgpg-error-1.22/src/gpg-error.h.in:432: error including `/usr/armv7a-hardfloat-linux-gnueabi/var/tmp/portage/dev-libs/libgpg-error-1.22/work/libgpg-error-1.22/src/syscfg/lock-obj-pub.linux-gnueabi.h': No such file or directory


This is because libgpg-error expects "${S}"/src/syscfg/lock-obj-pub.linux-gnueabi.h to be a copy of, or symlink to, a valid target arch specific header file in "${S}"/src/syscfg/ (eg., lock-obj-pub.arm-unknown-linux-gnueabi.h).
Comment 1 Peter Levine 2016-05-25 02:17:24 UTC
Created attachment 435306 [details]
dev-libs:libgpg-error-1.22:20160525-020039.log
Comment 2 Peter Levine 2016-05-25 02:18:47 UTC
Created attachment 435308 [details]
emerge-armv7a-hardfloat-linux-gnueabi --info
Comment 3 Peter Levine 2016-05-25 02:25:37 UTC
Created attachment 435310 [details, diff]
Patch for libgpg-error-1.22.ebuild

A patch for libgpg-error-1.22.ebuild (and potentially other versions) to enable proper cross-compiling by adding the correct symlink to "${S}"/src/syscfg/lock-obj-pub.linux-gnueabi.h.
Comment 4 Kristian Fiskerstrand gentoo-dev Security 2016-05-25 12:10:26 UTC
(In reply to Peter Levine from comment #3)
> Created attachment 435310 [details, diff] [details, diff]
> Patch for libgpg-error-1.22.ebuild
> 
> A patch for libgpg-error-1.22.ebuild (and potentially other versions) to
> enable proper cross-compiling by adding the correct symlink to
> "${S}"/src/syscfg/lock-obj-pub.linux-gnueabi.h.

This was discussed upstream and the [proposed way to fix it] is changes to config.{guess,sub}. If you're using it, would you be interested in working with upstream to get it solved properly?


[proposed way to fix it] https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029403.html
Comment 5 Alon Bar-Lev gentoo-dev 2016-05-25 12:32:05 UTC
Upstream response is[1].

Please help to push a correct cross compile support into upstream.

We should not maintain such conversion for upstream if upstream claims that there may be issues with this setup.

[1] https://bugs.gnupg.org/gnupg/issue1744
Comment 6 SpanKY gentoo-dev 2016-05-25 15:43:05 UTC
(In reply to Kristian Fiskerstrand from comment #4)

the chances of getting these kind of changes into config.{sub,guess} is extremely low imo.  gnupg is just using them wrong.  but considering the project's general approach to doing whatever-they-want-and-screw-the-wider-consensus, i suspect we'll have to carry a patch to make libgpg-error sane.
Comment 7 Peter Levine 2016-05-26 01:37:59 UTC
(In reply to Kristian Fiskerstrand from comment #4)
> (In reply to Peter Levine from comment #3)
> > Created attachment 435310 [details, diff] [details, diff] [details, diff]
> > Patch for libgpg-error-1.22.ebuild
> > 
> > A patch for libgpg-error-1.22.ebuild (and potentially other versions) to
> > enable proper cross-compiling by adding the correct symlink to
> > "${S}"/src/syscfg/lock-obj-pub.linux-gnueabi.h.
> 
> This was discussed upstream and the [proposed way to fix it] is changes to
> config.{guess,sub}. If you're using it, would you be interested in working
> with upstream to get it solved properly?
> 
> 
> [proposed way to fix it]
> https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029403.html

I'm not very familiar with config.{guess,sub} so correct me if I'm wrong but it seems to be working just fine.  They're drop-ins from http://savannah.gnu.org/projects/config. It looks like config.guess gives the canonical build triplet from a series of 'uname' commands and config.sub is used to parse it from the HOST.  When I run `config.sub armv7a-hardfloat-linux-gnueabi` it prints "armv7a-hardfloat-linux-gnueabi" which is correct.  It doesn't look like it was designed to dumb down the name into something like "arm-unknown-linux-gnueabi" just because they don't want to include a header file for every host name under the sun.

The problem is that, in src/Makefile there exists this:

>	./mkheader $(host_os) $(host_triplet)  $(srcdir)/gpg-error.h.in \
>                   ../config.h $(PACKAGE_VERSION) $(VERSION_NUMBER) >$@

For an ordinary build on my x64 this comes out to be:

>./mkheader linux-gnu x86_64-pc-linux-gnu  /var/tmp/portage/dev-libs/libgpg-error-1.22/work/libgpg-error-1.22/src/gpg-error.h.in \
>                   ../config.h 1.22 0x011600 >gpg-error.h

There is hardcoded logic in src/mkheader.c which is used to find the header "src/syscfg/lock-obj-pub.$(host_triplet).h".  This works for x86_64-pc-linux-gnu since there is a header "src/syscfg/lock-obj-pub.x86_64-pc-linux-gnu.h".  It fails for armv7a-hardfloat-linux-gnueabi since there is no "src/syscfg/lock-obj-pub.armv7a-hardfloat-linux-gnueabi.h".

Furthermore, there exists a mapping table in mkheader.c for mapping to correct hostnames, but only supports the following:

i486-pc-linux-gnu -> i686-pc-linux-gnu
i486-pc-gnu -> i686-pc-gnu
i486-pc-kfreebsd-gnu -> i686-pc-kfreebsd-gnu
x86_64-pc-linux-gnuhardened1 -> x86_64-pc-linux-gnu
powerpc-unknown-linux-gnuspe -> powerpc-unknown-linux-gnu

There is no easy solution.  Either take all logic out of mkheader.c, put it into configure.ac/m4 and add to it so it can guess the right header hostname to use with mkheader.  Or put even more crappy c coded "guessing game" logic into mkheader.c and hope for the best.  Either solution is no quick fix.
Comment 8 Peter Levine 2016-05-26 05:31:16 UTC
Created attachment 435416 [details, diff]
libgpg-error-1.22-fix-mkheader.patch

(In reply to Alon Bar-Lev from comment #5)
> Upstream response is[1].
> 
> Please help to push a correct cross compile support into upstream.
> 
> We should not maintain such conversion for upstream if upstream claims that
> there may be issues with this setup.
> 
> [1] https://bugs.gnupg.org/gnupg/issue1744

I'll submit it upstream in the next few days. Fingers crossed.
Comment 9 SpanKY gentoo-dev 2016-05-26 13:53:12 UTC
(In reply to Peter Levine from comment #8)

not sure if there's a preference, but you could use fnmatch instead, and then all the patterns would be globs rather than regexes.  that'd better align with how shell scripts often match tuples.
Comment 10 Peter Levine 2016-05-26 20:58:36 UTC
(In reply to SpanKY from comment #9)
> (In reply to Peter Levine from comment #8)
> 
> not sure if there's a preference, but you could use fnmatch instead, and
> then all the patterns would be globs rather than regexes.  that'd better
> align with how shell scripts often match tuples.

That would probably be better.  I'm also going to make it less liberal in pigeonholing so as not to not force an incompatible header file, i.e. "(arm*linux-gnueabi) -> arm-unknown-linux-gnueabi", instead of "(arm*) -> arm-unknown-linux-gnueabi".
Comment 11 Peter Levine 2016-05-27 03:00:36 UTC
Filed upstream: https://bugs.gnupg.org/gnupg/issue2370
Comment 12 Peter Levine 2016-06-04 06:25:45 UTC
So I admit I'm still a little confused as to what comprises a valid GNU triplet but I am much less sure that crossdev and gentoo howtos are conforming to it.

I emailed the dev of gnuconfig.  As to whether or not "armv7a-hardfloat-linux-gnueabi" was a valid GNU triplet, he said:

> I would say "no".  hardfloat is not a manufacturer.  The idea that
> whether hardfloat should be encoded in the triplet is somewhat crazy
> to me -- what else should we include in the triplet?  ;-)

According to https://wiki.debian.org/Multiarch/Tuples:

> Historical note: On ARM, the canonical GNU triplet for EABI systems,
> whether using hard-float or soft-float, was arm-linux-gnueabi,
> despite the fact that hard-float and soft-float libraries use different
> calling conventions and can't be intermixed. The advice given by
> upstream GCC developers was to use the vendor field in the GNU triplet
> to express this difference1; however, the vendor field is private by
> design, making this unreliable for cross-distribution use. Work finally
> succeeded to push the arm-linux-gnueabihf triplet upstream, but there
> may still be some broken packages around for a while.

`crossdev -t help` still incorrectly suggests using "softfloat" in the vendor field.

I chose "armv7a-hardfloat-linux-gnueabi" because of https://wiki.gentoo.org/wiki/Raspberry_Pi.  As I haven't seen other distros encode the name of the subarch in the arch field, I should ask.

Is there a particular reason that Gentoo specific howtos suggest the subarch in the host triplet?
It's not like I have ever seen x86_64_core7-linux-gnu or x86_64_haswell-linux-gnu.

Running  `config.sub arm-linux-gnueabi` does indeed echo "arm-unknown-linux-gnueabi".  So without any any further information I would have to conclude that such names that use the subarch in the arch field or the floatabi in the vendor field are, at best, unnecessarily unconventional and, at worst, not GNU conformant.

Ideally, stricter logic should be built in to crossdev and howtos should be corrected.
Comment 13 Alon Bar-Lev gentoo-dev 2016-06-04 06:44:51 UTC
As far as I know the 2nd component can be anything that does not change the ABI, so it should be ignored by components like gpg-error.

In gentoo you should either use unknown (or pc or anything) or append _softfloat to enable softfloat. As far as I remember the hardfloat is the default for all.
Comment 14 Peter Levine 2016-06-04 20:13:43 UTC
(In reply to Alon Bar-Lev from comment #13)

> In gentoo you should either use unknown (or pc or anything) or append
> _softfloat to enable softfloat. As far as I remember the hardfloat is the
> default for all.

Actually, with regards to armgnueabi hostnames, softfloat is the default.
From what I can tell, there exists a grey area between what is a canonical GNU host triplet and what is a host name that can be accepted and parsed by GCC.  It was originally GCC's suggestion that "hardfloat", and I assume by extension "softfloat", be used in the vendor field.  Though I have seen the field being described as "freeform" it is also "private by design".  Such unwarranted use of the vendor field, from GNU's perspective, will now invalidate the hostname (even if it is still accepted and parsed by GCC).

GNU treats the following as valid host triplets for armeabi (with an optional "unknown" in the vendor field):

arm-linux-gnueabi          (softfloat,little-endian)
arm-linux-gnueabihf        (hardfloat,little-endian)
armeb-linux-gnueabi        (softfloat,big-endian)
armeb-linux-gnueabihf      (hardfloat,big-endian)

Even though config.sub will not technically invalidate non-GNU conforming hostnames, that doesn't mean that upstream GNU devs have an obligation to accept them, as much as I would like it if they did.

The burden falls on Gentoo to either declare such non-conforming hostnames as unsupported or maintain ugly, long-winded case statements in ebuilds for packages with stubborn GNU devs.  If the former is chosen, crossdev should ideally forbid non-conformant names by default, but include a "--non-gnu-hostname" switch for backward compatibility and experimental use.

Just my 2 cents.
Comment 15 Alon Bar-Lev gentoo-dev 2016-06-04 20:21:38 UTC
I like Gentoo as it does not prevent one to do whatever you like.
It is up to you to specify the right tuples or any other information such as CFLAGS, LDFLAGS or CC.
Unless you know what you are doing, best you acquire these from designated upstream documentation.
Comment 16 Peter Levine 2016-06-04 21:01:11 UTC
(In reply to Alon Bar-Lev from comment #15)
> I like Gentoo as it does not prevent one to do whatever you like.
> It is up to you to specify the right tuples or any other information such as
> CFLAGS, LDFLAGS or CC.

I am not suggesting taking away that freedom, just force the end-user to make their intent and understanding of potential non-conformance more explicit.  There are ebuilds in the toolchain overlay, for instance, that force the user to put "I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS=1" in make.conf.

> Unless you know what you are doing, best you acquire these from designated
> upstream documentation.

If crossdev and wiki.gentoo.org are going to suggest unintentionally non-conformant  hostnames, then Gentoo shouldn't expect the end-user to preemptively research upstream documentation.
Comment 17 Alon Bar-Lev gentoo-dev 2016-06-04 21:04:20 UTC
"freedom" != "just force"

We do not expect anything, the tuple you specify is used as is in toolchain and all other usages.

If you do not know what you are doing, please avoid using a cross compiler.
Comment 18 Peter Levine 2016-06-04 22:08:56 UTC
(In reply to Alon Bar-Lev from comment #17)
> "freedom" != "just force"
> 
> We do not expect anything, the tuple you specify is used as is in toolchain
> and all other usages.

As long as the tuple contains "*gnu*" it should be gnu-conformant or expect the possibility of eventual breakage with GNU packages.  You seem to equate the explicit requirement of a program argument with force.  Would a warning be better? In the end, I'm going to recompile my cross toolchain as "arm-linux-gnueabihf", confirm that libgpg-error-1.22 installs, look to see what I can possibly do about editing https://wiki.gentoo.org/wiki/Raspberry_Pi, and possibly propose a fix for crossdev's flawed advice. But I am not a dev.  This problem will just remain in limbo.

> If you do not know what you are doing, please avoid using a cross compiler.

You and I didn't know that the use of a floating-point ABI in the vendor field of a host name violated GNU convention, and if you're stubborn enough you still don't know it.  But neither of us are Ben Elliston of gnuconfig and he says it so it must be true.  Either come up with a way to aid users of crossdev into selecting more conventional host names or continue to suffer more entirely justifiable but unfortunate bug reports that remain in the limbo between downstream's necessity for unmitigated freedom and upstream's rejection of the slightest non-conformity.
Comment 19 SpanKY gentoo-dev 2016-06-05 19:09:15 UTC
(In reply to Peter Levine from comment #14)

the vendor field is free form.  how we choose to use it or stick info in it is none of the business of tools.  the gnu config project does not care, nor gcc, nor any other correctly behaving project.  putting "hardfloat" or "softfloat" or "gentoo" or "catsocks" or anything else is irrelevant.  there is no bug on Gentoo's side, nor are the tuples we're using invalid.
Comment 20 Peter Levine 2016-06-05 21:03:53 UTC
(In reply to SpanKY from comment #19)
> (In reply to Peter Levine from comment #14)
> 
> the vendor field is free form.  how we choose to use it or stick info in it
> is none of the business of tools.  the gnu config project does not care, nor
> gcc, nor any other correctly behaving project.  putting "hardfloat" or
> "softfloat" or "gentoo" or "catsocks" or anything else is irrelevant.  there
> is no bug on Gentoo's side, nor are the tuples we're using invalid.

Since I have not found any definitive, authoritative, and standardized description of a valid tuple, I have to take you at your word.

But since there is an impasse between what you and libgpg-error/gnuconfig upstream consider valid, if libgpg-error is going to be offered at all shouldn't the onus be on Gentoo to maintain compatibility?

If "hardfloat" in the vendor field is OK then shouldn't you put your weight behind supporting it when upstream won't?
Comment 21 SpanKY gentoo-dev 2016-06-06 03:30:00 UTC
(In reply to Peter Levine from comment #20)

the gnupg guys are the only ones that don't work.  the gnuconfig project isn't relevant, and even if it was, they already correctly parse these tuples.

none of this is Gentoo specific.  i don't know why you think it is.  nothing is stopping anyone out there from using the vendor field for their vendor info.  it often has been too for things like "pc" or "redhat".

there is no gnu "upstream" for us to get "hardfloat" accepted.  i don't know why you're focusing on that either: i already said the vendor portion can be anything.  the fact that we might use hardfloat sometimes is entirely irrelevant.

i don't waste time on the gnupg project anymore because they have 0 interest being interoperable with the wider community.  if they don't understand how to properly parse a tuple, then they should learn to RTFM.  the autoconf manual already explains this stuff in depth and provides helpers to parse out the relevant bits.
Comment 22 Peter Levine 2016-06-06 17:37:04 UTC
(In reply to SpanKY from comment #21)
> (In reply to Peter Levine from comment #20)
> 
> the gnupg guys are the only ones that don't work.  the gnuconfig project
> isn't relevant
> and even if it was, they already correctly parse these
> tuples.

I agree but one of the arguments given by the gnupg devs was that the problem needed to be addressed in config.sub.  Their's is a drop-in from gnuconfig. That is why the focus shifted to gnuconfig.

> none of this is Gentoo specific.  i don't know why you think it is.

It was my understanding, correctly or incorrectly, that it's GNU specific.  I never said Gentoo specific.  I just assumed that since Gentoo supports GNU/Linux on most platforms, it had some obligation to either conform to GNU or to patch where it doesn't. If I was incorrectly misrepresenting such GNUPG/gnuconfig notions of conformance as GNU then I apologize.

> nothing is stopping anyone out there from using the vendor field for their vendor
> info.  it often has been too for things like "pc" or "redhat".

In terms of what the aforementioned shitty gnuconfig/gnupg folks say, it was my understanding that those two examples were already accepted as valid options for the vendor field. But yes, it otherwise has a long history of being freeform.

> there is no gnu "upstream" for us to get "hardfloat" accepted.  i don't know
> why you're focusing on that either: i already said the vendor portion can be
> anything.  the fact that we might use hardfloat sometimes is entirely
> irrelevant.

Since last comment I have tried to shift my focus as to whether Gentoo will maintain a fix to support such hostnames or ignore the problem like gnupg.

I agree it's not such a huge deal.  It's just one package (so far on my end), but this has been a problem for quite some time.  I could continue maintaining my own patched ebuild in my own private overlay or Gentoo could maintain it for everyone who uses crossdev and decides not to use a Debianesque hostname.
Comment 23 Alon Bar-Lev gentoo-dev 2016-06-06 17:53:51 UTC
OK, I think we discuss this enough.
This is a problem for upstream to solve.

The suggested patch is too complex to maintain.

Probably a better approach will be to symlink to the lock header with current CHOST which is good for downstream.

Or patch the src/mkheader.c::canon_host_triple() to replace the subarch with the "unknown", the later may have a chance to be accepted by upstream.
Comment 24 Peter Levine 2016-06-06 20:32:31 UTC
(In reply to Alon Bar-Lev from comment #23)
> OK, I think we discuss this enough.
> This is a problem for upstream to solve.
> 
> The suggested patch is too complex to maintain.
> 
> Probably a better approach will be to symlink to the lock header with
> current CHOST which is good for downstream.
> 
> Or patch the src/mkheader.c::canon_host_triple() to replace the subarch with
> the "unknown", the later may have a chance to be accepted by upstream.

Upstream has made it abundantly if not directly clear that they will not accept any changes that do not adhere to their host naming scheme.  They're not interested in aiding distros into selecting the proper header.  Either accept something like https://bugs.gentoo.org/attachment.cgi?id=435310 or match their stubbornness and mark WONTFIX.
Comment 25 SpanKY gentoo-dev 2016-06-07 04:56:46 UTC
(In reply to Peter Levine from comment #24)

exactly, gnupg upstream has a long history of being arrogant (and perhaps purposefully ignorant) and forcing people to adhere to their invalid standards.

if we're going to patch, i don't think we want that ebuild change.  it's too inflexible and requires too much upkeep.  instead, fix their asinine build system to DTRT in the first place and ignore the vendor field.  autoconf already provides split out $host_os/$host_cpu fields that can be recombined.
Comment 26 Alon Bar-Lev gentoo-dev 2016-06-07 05:02:00 UTC
(In reply to SpanKY from comment #25)
> (In reply to Peter Levine from comment #24)
> if we're going to patch, i don't think we want that ebuild change.  it's too
> inflexible and requires too much upkeep.  instead, fix their asinine build
> system to DTRT in the first place and ignore the vendor field.  autoconf
> already provides split out $host_os/$host_cpu fields that can be recombined.

I provided two options I had in mind at comment#23.
But since upstream is not going to merge it, I did not actually invested effort in this.

Simple patches are welcomed.
Comment 27 Peter Levine 2016-06-08 04:33:43 UTC
Created attachment 436842 [details, diff]
libgpg-error-link-valid-header.patch

Note: It is necessary to replace elibtoolize with eautoreconf in the ebuild.

How about this?

All the logic is now in configure.ac.  At configure time, if the host matches one of the case patterns, a link is made in the build directory. A link in the source directory wouldn't have been multilib friendly (i.e., a link to the header for x86_64 would have been overwritten by the one for i686).  This required a one-line change to src/mkheader.c. During compile time, if the hostname happens to directly match the hostname part of a header then that source header is used directly.  Otherwise, it defaults to src/syscfg/lock-obj-pub.${host_os}.h in the build directory which is where the correct link resides.

Attempts to patch configure directly without eautoreconf failed as, I assume, libtoolize would just overwrite the changes.
Comment 28 Peter Levine 2016-06-08 04:48:42 UTC
Submitted upstream, not that I expect a miracle.
Comment 29 Alon Bar-Lev gentoo-dev 2016-06-08 06:33:55 UTC
(In reply to Peter Levine from comment #28)
> Submitted upstream, not that I expect a miracle.

this is not how upstream designed its build system.
once again... I suggest you look into modifying the src/mkheader.c::canon_host_triple(), if it can ignore the subarch then you have a solution that has a minor chance to be simple and accepted.
Comment 30 Peter Levine 2016-06-08 07:31:52 UTC
(In reply to Alon Bar-Lev from comment #29)
> (In reply to Peter Levine from comment #28)
> > Submitted upstream, not that I expect a miracle.
> 
> this is not how upstream designed its build system.
> once again... I suggest you look into modifying the
> src/mkheader.c::canon_host_triple(), if it can ignore the subarch then you  
> have a solution that has a minor chance to be simple and accepted.


Didn't I do that already? It was rejected.

https://bugs.gnupg.org/gnupg/file839/libgpg-error-1.22-fix-mkheader.patch
Comment 31 Alon Bar-Lev gentoo-dev 2016-06-08 07:35:44 UTC
(In reply to Peter Levine from comment #30)
> Didn't I do that already? It was rejected.
> 
> https://bugs.gnupg.org/gnupg/file839/libgpg-error-1.22-fix-mkheader.patch

No, I asked if this will be acceptable.
Then understood it won't be merged because of misinterpretation of what subarch is, so I gave it up.
This is the best approach for a solution in the spirit of what upstream had in mind for aliasing.
Comment 32 Peter Levine 2016-06-08 18:45:41 UTC
(In reply to Alon Bar-Lev from comment #31)
> (In reply to Peter Levine from comment #30)
> > Didn't I do that already? It was rejected.
> > 
> > https://bugs.gnupg.org/gnupg/file839/libgpg-error-1.22-fix-mkheader.patch
> 
> No, I asked if this will be acceptable.
> Then understood it won't be merged because of misinterpretation of what
> subarch is, so I gave it up.
> This is the best approach for a solution in the spirit of what upstream had
> in mind for aliasing.


OK. I guess I am unclear about what you mean "ignore the subarch".  In a glob pattern like "mips*linux-gnu", the arch is "mips".  The point of the "*" is to ignore the subarch (and the vendor field).(In reply to Alon Bar-Lev from comment #29)
> (In reply to Peter Levine from comment #28)
> > Submitted upstream, not that I expect a miracle.
> 
> this is not how upstream designed its build system.
> once again... I suggest you look into modifying the
> src/mkheader.c::canon_host_triple(), if it can ignore the subarch then you
> have a solution that has a minor chance to be simple and accepted.

(In reply to Alon Bar-Lev from comment #31)
> (In reply to Peter Levine from comment #30)
> > Didn't I do that already? It was rejected.
> > 
> > https://bugs.gnupg.org/gnupg/file839/libgpg-error-1.22-fix-mkheader.patch
> 
> No, I asked if this will be acceptable.
> Then understood it won't be merged because of misinterpretation of what
> subarch is, so I gave it up.
> This is the best approach for a solution in the spirit of what upstream had
> in mind for aliasing.


OK. I guess I am unclear about what you mean "ignore the subarch".  In a glob pattern like "mips*linux-gnu", the arch is "mips".  The point of the "*" is to ignore the subarch (and the vendor field).  Please correct me if I'm wrong.
Comment 33 Alon Bar-Lev gentoo-dev 2016-06-08 19:02:24 UTC
Current aliasing algorithm enables to specify alias for a specific tuple. This is insufficient for most use cases as sumarch can be anything.

What we need is to modify this aliasing algorithm to modify \1-\2-\3-\4 into \1-unknown-\3-\4 and hopefully find in tree configuration for that tuple.
Comment 34 Peter Levine 2016-06-08 20:12:54 UTC
(In reply to Alon Bar-Lev from comment #33)
> Current aliasing algorithm enables to specify alias for a specific tuple.
> This is insufficient for most use cases as sumarch can be anything.
> 
> What we need is to modify this aliasing algorithm to modify \1-\2-\3-\4 into
> \1-unknown-\3-\4 and hopefully find in tree configuration for that tuple.

OK. There is a misunderstanding here https://bugs.gnupg.org/gnupg/issue1744.

From the first comment it's clear they're referring to the vendor field (2nd field) as "sub architecture". I was referring to the "v7a" part of armv7a-hardfloat-linux-gnueabi.  Assuming we're patching for Gentoo hostname compliance, the implication of what they want still implies a generic arch field (i.e., "arm-" instead of "armv7a-").  Even mapping something like "arm-softfloat-linux-gnueabi" to "arm-unknown-linux-gnueabi" would not work for "armv7a-hardfloat-linux-gnueabi". What they want is a contained, finite set of acceptable hostnames, even after ignoring the 2nd field.  Gentoo hostname are not bound to such a constrained set.  And by repeatedly and falsely claiming that "armv7a-hardfloat-linux-gnueabi" is not a valid hostname for config.sub and that config.sub needs to be patched (even though config.sub clearly parses it just fine and returns 0 to the shell) they're basically saying no.  Their problem with such hostnames is broader than just the 2nd field.
Comment 35 Alon Bar-Lev gentoo-dev 2016-06-09 04:18:30 UTC
Generic arch is exactly what upstream suggest to avoid, as without explicit test, nobody may guarantee that the settings are correct.
Comment 36 Peter Levine 2016-06-11 00:17:56 UTC
(In reply to Alon Bar-Lev from comment #35)
> Generic arch is exactly what upstream suggest to avoid, as without explicit
> test, nobody may guarantee that the settings are correct.

Again, you are confusing arch (1st field) for thevendor-field (2nd field), what you called "subarch" here: https://bugs.gnupg.org/gnupg/issue1744

All of their header files use generic arch (such as "arm") and require converting "armv7a" to "arm".

Modifying  \1-\2-\3-\4 into \1-unknown-\3-\4 does nothing to help change armv7a-hardfloat-linux-gnueabi into arm-unknown-linux-gnueabi (nor into it's correct header form arm-unknown-linux-gnueabihf).
Comment 37 Sven Müller 2016-08-23 21:25:14 UTC
(In reply to Peter Levine from comment #27)
> Created attachment 436842 [details, diff] [details, diff]
> libgpg-error-link-valid-header.patch
> 
> Note: It is necessary to replace elibtoolize with eautoreconf in the ebuild.


Doing so I got the error: 
/var/tmp/portage/dev-libs/libgpg-error-1.24/temp/environment: line 2765: eautoreconf: command not found

Please, can you provide a diff for the ebuild to get that lib compiled. 

Maybe to whole discussion is important, but for me it's just one problem more (of the many existing) to get Gentoo on my NAS running. I'm also using armv7a-hardfloat-linux-gnueabi.
Comment 38 Peter Levine 2016-08-23 22:28:33 UTC
Created attachment 443990 [details, diff]
libgpg-error-1.22.ebuild.patch

(In reply to Sven Müller from comment #37)
> Please, can you provide a diff for the ebuild to get that lib compiled.
Comment 39 Sven Müller 2016-08-24 16:19:03 UTC
Thanks, works in host-environment when cross-compiling. So at least I got this package installed and can continue. 

If I try to compile libgpg-error from inside the chroot (qemu-arm) it still fails:

>>> Compiling source in /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24 ...
 * .arm: running multilib-minimal_abi_src_compile
make -j13 
/usr/bin/make  all-recursive
make[1]: Entering directory '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24-.arm'
Making all in m4
make[2]: Entering directory '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24-.arm/m4'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24-.arm/m4'
Making all in src
make[2]: Entering directory '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24-.arm/src'
gawk -f /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/mkerrnos.awk /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/errnos.in >code-to-errno.h
gawk -f /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/mkerrcodes1.awk /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/errnos.in >_mkerrcodes.h
gawk -f /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/mkstrtable.awk -v textidx=2 -v nogettext=1 \
	/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/err-sources.h.in >err-sources-sym.h
gawk -f /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/mkstrtable.awk -v textidx=2 -v nogettext=1 \
	/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/err-codes.h.in >err-codes-sym.h
gawk -f /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/mkstrtable.awk -v textidx=2 -v nogettext=1 \
	-v prefix=GPG_ERR_ -v namespace=errnos_ \
	/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/errnos.in >errnos-sym.h
x86_64-pc-linux-gnu-gcc -g -O0 -I. -I/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src -o mkheader /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/mkheader.c
make[2]: x86_64-pc-linux-gnu-gcc: Command not found
make[2]: *** [Makefile:1322: mkheader] Error 127
make[2]: *** Waiting for unfinished jobs....
armv7a-hardfloat-linux-gnueabi-gcc -E   -P _mkerrcodes.h | grep GPG_ERR_ | \
               gawk -f /var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24/src/mkerrcodes.awk >mkerrcodes.h
rm _mkerrcodes.h
make[2]: Leaving directory '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24-.arm/src'
make[1]: *** [Makefile:488: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24-.arm'
make: *** [Makefile:420: all] Error 2
 * ERROR: dev-libs/libgpg-error-1.24::local-overlay failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/libgpg-error-1.24::local-overlay'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/libgpg-error-1.24::local-overlay'`.
 * The complete build log is located at '/var/tmp/portage/dev-libs/libgpg-error-1.24/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/libgpg-error-1.24/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24-.arm'
 * S: '/var/tmp/portage/dev-libs/libgpg-error-1.24/work/libgpg-error-1.24'

>>> Failed to emerge dev-libs/libgpg-error-1.24, Log file:
Comment 40 Sven Müller 2016-08-24 17:02:21 UTC
(In reply to Sven Müller from comment #39)

Please ignore my comment above. After setting HOSTCC and CBUILD to armv7a-hardfloat-linux-gnueabi-gcc it worked in the chroot environment too.

It's strange, some packages seem use differenct compiler aliases in the compiling process within one package.
Comment 41 Leno Hou 2016-09-12 05:40:57 UTC
*** Bug 593484 has been marked as a duplicate of this bug. ***
Comment 42 Sergei Trofimovich gentoo-dev 2017-07-02 08:04:48 UTC
Found out today dev-libs/libgpg-error-1.27-r1 fails with even simpler
and less magic triplets like:
    --build=x86_64-pc-linux-gnu --host=ia64-unknown-linux-gnu
Comment 43 Alon Bar-Lev gentoo-dev 2017-07-02 11:31:33 UTC
(In reply to Sergei Trofimovich from comment #42)
> Found out today dev-libs/libgpg-error-1.27-r1 fails with even simpler
> and less magic triplets like:
>     --build=x86_64-pc-linux-gnu --host=ia64-unknown-linux-gnu

The list of available cross compile tuples is available [1] [2], feel free to contribute upstream.

[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=tree;f=src/syscfg;hb=HEAD
[2] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/mkheader.c;hb=HEAD#l73
Comment 44 Alon Bar-Lev gentoo-dev 2018-04-24 05:04:54 UTC
*** Bug 653912 has been marked as a duplicate of this bug. ***
Comment 45 Alon Bar-Lev gentoo-dev 2018-11-04 12:50:32 UTC
*** Bug 670202 has been marked as a duplicate of this bug. ***
Comment 46 tt_1 2019-03-16 09:47:08 UTC
*** Bug 670202 has been marked as a duplicate of this bug. ***
Comment 47 Alon Bar-Lev gentoo-dev 2019-03-16 11:14:25 UTC
*** Bug 680526 has been marked as a duplicate of this bug. ***
Comment 48 Alon Bar-Lev gentoo-dev 2019-03-16 11:27:30 UTC
*** Bug 680526 has been marked as a duplicate of this bug. ***