IcedTea fails to build on the x32 ABI (x86_64-pc-linux-gnux32), because its configure script sees the x86_64 machine type and adds -m64 to compile commands, resulting in it compiling for the wrong ABI and failing. The x32 ABI needs -mx32 instead. In dev-java/icedtea-7.2.3.8 the flag seems to be set in both the main configure script and a number of the sub-packages. Reproducible: Always
Portage 2.1.11.62 (default/linux/amd64/13.0/x32, gcc-4.7.1, glibc-2.16.0, 3.8.13-gentoo x86_64) ================================================================= System uname: Linux-3.8.13-gentoo-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-2.2 KiB Mem: 764852 total, 66204 free KiB Swap: 1048572 total, 1044080 free Timestamp of tree: Tue, 21 May 2013 00:15:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.10.2-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.10.3, 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.7.1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnux32" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnux32" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.mdfnet.se/gentoo" LDFLAGS="-Wl,-O1 -Wl,--as-needed" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X acl amd64 apng bash-completion berkdb bzip2 cli cracklib crypt cups cxx dri fortran gcj gdbm gif gpm graphite gtk iconv ipv6 jpeg lto lzma lzo mmx mmxext modules mudflap multilib ncurses nls nptl openmp pam pcre python readline session sse sse2 sse3 ssl tcpd tiff unicode zlib" ABI_X86="x32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="vmware" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Ok, it took more than just that to get it to compile, but configuring with --enable-zero, then editing the Makefile and changing -m64 to -mx32 and the zero bitness from 64 to 32 seems to work. At least, I think that's all it took. Spent a while messing around with it to get it to work, but I think that was the minimal changes. It does work, though, albeit very slowly.
Meanwhile a new version of icedtea is released. Could you try that out ? Have you reported the problem upstream ? In any case, I think this bug should depend on the x32 tracker (#393673).
- I haven't reported it upstream as it's fairly obvious from the code they've made no effort at all to support x32, so they probably wouldn't care. - Unfortunately, I also gave up on Gentoo after assorted other issues, so can't really test out the new version. I doubt it's any different though. - You are probably right about the dependency.
Why would you want it on x32? That would require a whole new JIT port and I don't see anyone creating one when you can just use the existing x86_64 port.
At the time, I was experimenting with a full x32 system (in a virtual machine), more or less just to see if it were possible. It did try to build a x64 version, but failed messily as the compiler and libraries were set up for x32. Ideally yes, it would benefit from a full JIT port. It should, in theory be faster than x64 provided you don't actually need > 4 GB of address space per process. Probably more than average for Java code, as it's rather pointer-heavy. While this should be easier than most architecture ports, as it's essentially just x64 code with minor pointer size changes. But yes, I do agree it's not likely someone is going to spend the effort. However failing that, it should at least be possible to build in Zero mode, and probably Zero Shark mode as LLVM appears to be available on x32. This would be significantly slower than the x64 version, but at least it would compile and function on a x32 system. With some configure/makefile edits I was able to get it to build in Zero mode, so the code does work, it's just set up assuming the Intel-like platform can only be x86 or x64. I wasn't able to get Zero Shark to build since it requires an older version of LLVM than what's currently included with Gentoo, and at that point I was too tired to fight with it any more.
Reopening as Debian are also trying to support this too. I still don't see why anyone would want a slow Zero build on x86_64 x32 over a native x86_64 x64 port, but we should at least build.
*** Bug 517558 has been marked as a duplicate of this bug. ***
Package removed.
