the has_m64 flag doesn't really work. not all 64bit targets accept -m64, and some 32bit targets which support multilib can accept -m64. in reading the xalan-c code, it doesn't seem like the bitstobuild= configure flag is even useful. when it has a value of "32", it doesn't add any flags, and when it is "64", it adds hardcoded flags for some targets. all of that should be taken care of already by the user's toolchain. i would just set bitstobuild=32 since that code path seems to not do anything
Any progress here? This appears to be the last ebuild blocking removal of the has_m64 function in flag-o-matic.eclass (and therefore, removal of the eutils inherit in that eclass). (In reply to SpanKY from comment #0) > in reading the xalan-c code, it doesn't seem like the bitstobuild= configure > flag is even useful. when it has a value of "32", it doesn't add any flags, > and when it is "64", it adds hardcoded flags for some targets. Especially, it doesn't add any flags at all for platform=linux. > i would just set bitstobuild=32 since that code path seems to not do anything It's the default, so can be removed altogether.
Created attachment 463188 [details, diff] Patch for xalan-c-1.11.0_pre1153059.ebuild Proposed patch. The build.log on amd64 with this patch differs only by one line from the one without (which verifies that the bitstobuild option is a no-op): - * has_m64: don't use this anymore So should be safe to do this in place without a revbump.
commit e919ffe0bd16d9e6dcfe7ed82c3b18e2c67a6051 Author: Ulrich Müller <ulm@gentoo.org> Date: Sun Feb 12 10:20:28 2017 +0100 dev-libs/xalan-c: Drop has_m64 usage. Remove the bitstobuild option which has no effect on Linux. Non-maintainer commit, acked by soap. Bug: 398855 Package-Manager: Portage-2.3.3, Repoman-2.3.1
