Created attachment 645244 [details] build.log from cross compiling I'm not sure why this happens, =dev-libs/nss-3.52.1-r1 was doing just fine: true -m 775 Linux5.4_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/nsinstall ../../dist/Linux5.4_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/bin make[1]: Leaving directory '/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-libs/nss-3.53.1/work/nss-3.53.1/nss-.arm/coreconf/nsinstall' make: Leaving directory '/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-libs/nss-3.53.1/work/nss-3.53.1/nss-.arm/coreconf' make -j12 -j1 CC=armv7a-unknown-linux-gnueabihf-gcc CCC=armv7a-unknown-linux-gnueabihf-g++ 'AR=armv7a-unknown-linux-gnueabihf-ar rc $@' RANLIB=armv7a-unknown-linux-gnueabihf-ranlib OPTIMIZER= NSINSTALL=/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-libs/nss-3.53.1/work/nss-3.53.1/nss-.arm/./coreconf/nsinstall/Linux5.4_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/nsinstall -C . make: Entering directory '/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-libs/nss-3.53.1/work/nss-3.53.1/nss-.arm' coreconf/arch.mk:150: CPU_ARCH is not x86_64, disabling -mavx2 make all make[1]: Entering directory '/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-libs/nss-3.53.1/work/nss-3.53.1/nss-.arm' # no real way to encode these in any sensible way make -C coreconf/nsinstall program make[2]: Entering directory '/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/dev-libs/nss-3.53.1/work/nss-3.53.1/nss-.arm/coreconf/nsinstall' armv7a-unknown-linux-gnueabihf-gcc -o Linux5.4_x86_armv7a-unknown-linux-gnueabihf-gcc_glibc_PTH_OPT.OBJ/nsinstall.o -c -std=c99 -fPIC -Di386 -m32 -pipe -ffunction-sections -fdata-sections -DHAVE_STRERROR -DLINUX -Dlinux -Wall -Wshadow -DNSS_NO_GCC48 -DXP_UNIX -UDEBUG -DNDEBUG -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_POSIX_SOURCE -DSQL_MEASURE_USE_TEMP_DIR -D_REENTRANT -DNSS_DISABLE_AVX2 -DNSS_NO_INIT_SUPPORT -DSEED_ONLY_DEV_URANDOM -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I../../dist/Linux5.4_x86_armv7a-unknown-linux-gnueabihf-gcc_glibc_PTH_OPT.OBJ/include -I../../dist/public/coreconf -I../../dist/private/coreconf -I../../dist/Linux5.4_x86_armv7a-unknown-linux-gnueabihf-gcc_glibc_PTH_OPT.OBJ/include/dbm -O2 -pipe -I/usr/armv7a-unknown-linux-gnueabihf/usr/include/nspr nsinstall.c armv7a-unknown-linux-gnueabihf-gcc: error: unrecognized command line option ‘-m32’; did you mean ‘-mbe32’? make[2]: *** [../../coreconf/rules.mk:292: Linux5.4_x86_armv7a-unknown-linux-gnueabihf-gcc_glibc_PTH_OPT.OBJ/nsinstall.o] Error 1 but I guess this comes from a confusion of target cc and host cc, since helper tools used during install have to be build for the host, and here it's the target cross cc used for that I believe? not sure either if this has anything to do with the bumped patch. ideas, anyone?
Created attachment 645250 [details] output from cross-emerge --info
I got a different cross-compiling error when building for PowerPC where it spewed "invalid opcode bswap" messages. (Maybe I should make a separate bug.) It seemed to build successfully after appending OS_TEST=ppc to the last emake line.
(In reply to David Michael from comment #2) > I got a different cross-compiling error when building for PowerPC where it > spewed "invalid opcode bswap" messages. (Maybe I should make a separate > bug.) It seemed to build successfully after appending OS_TEST=ppc to the > last emake line. Grepping the code, I think you're right actually. Try adding OS_TEST=arm to the last emake and see if that helps.
hey, thanks for your answer, it's just that I don't understand where to add the OS_Test=arm variable. I tried a few times with different lines and version without success, so can you please post a little patch for me to test it properly?
You could just add EXTRA_EMAKE=OS_TEST=arm to the environment, which let me cross-compile it for armv7a and armv5tejl.
This is still an issue with 3.54.
It might be a good idea to switch to ninja/gyp build in the longterm. For now I can live with the workaround of pasting env EXTRA_EMAKE=OS_TEST=arm before the cross-emerge wrappers. It was lovely if the value can be dropped into /etc/portage/env/dev-libs/nss , but that didn't seem to work? p.s: for arm64 it's OS_TEST=aarch64
(In reply to tt_1 from comment #7) > before the cross-emerge wrappers. It was lovely if the value can be dropped > into /etc/portage/env/dev-libs/nss , but that didn't seem to work? It should work if you add it to /usr/$CTARGET/etc/portage/env/dev-libs/nss
no, that doesn't work: cat /usr/armv7a-unknown-linux-gnueabihf/etc/portage/env/dev-libs/nss EXTRA_EMAKE=OS_TEST=arm even though it does for EXTRA_ECONF
This is still an issue with 3.55. Can it just be added to the ebuild? --- dev-libs/nss/nss-3.55.ebuild +++ dev-libs/nss/nss-3.55.ebuild @@ -178,7 +178,7 @@ CPPFLAGS="${myCPPFLAGS}" \ XCFLAGS="${CFLAGS} ${CPPFLAGS}" \ NSPR_LIB_DIR="${T}/fakedir" \ - emake -j1 "${makeargs[@]}" -C ${d} + emake -j1 "${makeargs[@]}" -C ${d} OS_TEST="$(nssarch)" done }
This is still an issue with 3.56. Same problem, same solution. Is this going to be addressed?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f980f7e5ed5a164a8d490b34a776590f96c3b5ff commit f980f7e5ed5a164a8d490b34a776590f96c3b5ff Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-08-23 21:18:06 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-08-23 21:18:19 +0000 dev-libs/nss: fix cross-compile Closes: https://bugs.gentoo.org/728764 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> dev-libs/nss/nss-3.55.ebuild | 2 +- dev-libs/nss/nss-3.56.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
