Summary: | dev-libs/libgpg-error-1.15 ignores CC when cross-compiling | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | gentoo-bugs |
Component: | [OLD] Library | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | alonbl, vincent.cadet |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.g10code.com/gnupg/issue1744 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
gentoo-bugs
2014-10-20 20:43:38 UTC
Created attachment 387086 [details]
build.log
CC=/bin/false ebuild libgpg-error-1.15.ebuild clean install uses /bin/false Please attach config.log from: /usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15 use of cc in this case is intentional as this program should work on build machine. Error is: /usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/gpg-error.h.in:320: error including `/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/syscfg/lock-obj-pub.linux-gnueabi.h': No such file or directory From README """ Cross-Compiling --------------- Libgpg-error needs to figure out some platform specific properties. These are used to build the platform specific gpg-error.h file. The detection is done during build time but can't be done when cross-compiling. Thus if you run into an error during building you need to figure out these values. You may use these commands: build="$(build-aux/config.guess)" ./configure --prefix=TARGETDIR --host=TARGET --build=$build cd src make gen-posix-lock-obj scp gen-posix-lock-obj TARGET: ssh TARGET ./gen-posix-lock-obj >tmp.h mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)" If you are using a VPATH build adjust accordingly. If this all works for you (make sure to run the test programs on the target platform), please send the generated file to the gnupg-devel mailing list so that we can include it in the next release. """ I guess your problem is that the TARGET is not pre-built at src/syscfg. Nothing we can actually do if the above is the sequence. Please also try to use armv6j-unknown-linux-gnueabi instead of armv6j-hardfloat-linux-gnueabi, it will use hardware float control anyway and probably will work. Also note that the notation of armv6j-unknown_hardfloat-linux-gnueabi is better. *** Bug 560134 has been marked as a duplicate of this bug. *** CANTFIX? This bug has been around for about one year and NO solution has been implemented. I took it up for a couple of hours and I came up with a fix that might be temporary but still I could at least cross-compile. Look, I've read about doing the mapping between platforms in canon_host_triplet but here are my facts: - this code targets Linux - I've created symbolic links for the mapping and it *just works* with crossdev - won't induce regressions since it's a basic file-based mapping - mapping with symbolic links is the most straightforward way, no change in makefiles, source files, nothing. Obviously lock-obj-pub.arm-unknown-linux-gnueabihf.h and lock-obj-pub.armv7a-hardfloat-linux-gnueabi.h are strictly equivalent, right? So why not doing that until the final fix is implemented? This case can be solved quickly using symbolic links at least for the ARM platform, whether it be upstream or here on Gentoo. I do like splitting hairs at times (I really do) but one year *without* anything that works is not going to make it. Better a few working cases than none at all. (In reply to Vince C. from comment #8) > Obviously lock-obj-pub.arm-unknown-linux-gnueabihf.h and > lock-obj-pub.armv7a-hardfloat-linux-gnueabi.h are strictly equivalent ... meaning arm-unknown-linux-gnueabihf and armv7a-hardfloat-linux-gnueabi are obviously equivalent triplets, of course. Anyway, if the supplied lot of triplet-depending files is exhaustive, there's a good reason a file-mapping can be done regardless of how Gentoo names its triplets. Gentoo is not upstream, please contact upstream. Upstream does not provide any sensible solution, see $URL. (In reply to Alon Bar-Lev from comment #10) > Gentoo is not upstream, please contact upstream. > Upstream does not provide any sensible solution, see $URL. Not because Gentoo is not upstream (which I don't need to reminded) is no reason to stubbornly stagnate, all camps. It only takes one good-willing person to make the schmilblick progress. Shall we decide there will be none? I've see so many discussions about distro maintainers making their own patches without feeding upstream being far from uncommon. Now no one should want to make a patch because upstream wouldn't make a sensible solution...!? C'm'on, let's be smarter than that. I'm just an average idiot yet I did something to make it work. So, yes, we can and I'm not just paraphrasing. |