Nam ebuild fails badly on amd64, this new ebuild and patch should fix it, it just changes the ints to long long, because 64 bit is the expected size for void*. Portage 2.1.2_pre2-r1 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r4, 2.6.18-rc5-mm1 x86_64) ================================================================= System uname: 2.6.18-rc5-mm1 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Gentoo Base System version 1.13.0_alpha1 Last Sync: Mon, 02 Oct 2006 16:30:01 +0000 ccache version 2.4 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=nocona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlays/nspluginwrapper /usr/local/overlays/checkgmail /usr/local/overlays/exaile /usr/local/overlays/themes /usr/portage/local/layman/portage-xgl /usr/portage/local/layman/vmware" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X a52 aac aalib acpi alsa animation apache2 audiofile bash-completion bcmath berkdb bitmap-fonts bluetooth bzip2 cdb cdparanoia cdr cjk cli crypt cscope ctype cups curl curlwrappers dbus dlloader dri dv dvd dvdr dvdread elibc_glibc emul-linux-x86 encode esd fam ffmpeg firefox flac flash fortran ftp gdbm geoip gif glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 hal ieee1394 imagemagick imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog ithreads java jpeg jpeg2k kernel_linux libcaca libg++ lirc lm_sensors mad mono mp3 msn mysql ncurses nls no-seamonkey nptl nptlonly nsplugin ogg oggvorbis opengl pam pcre pdf perl png posix ppds pppd python qt3 qt4 readline reflection ruby sdl session spl ssl startup-notification svg tcl tcpd theora threads truetype truetype-fonts type1-fonts udev unicode usb userland_GNU vcd video_cards_nvidia vnc vorbis wxwindows xine xinerama xml xorg xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 98617 [details] nam-1.11-r1.ebuild
Created attachment 98618 [details, diff] nam-amd64-intsize.patch
Comment on attachment 98618 [details, diff] nam-amd64-intsize.patch This will break 32bit arches, as long long is 64bit there too. What you want is just 'long'.
(In reply to comment #3) > (From update of attachment 98618 [details, diff] [edit]) > This will break 32bit arches, as long long is 64bit there too. What you want is > just 'long'. > Did you even read the ebuild? You are right, but it wouldn't break 32bit archs because it was being applied only to amd64..
(In reply to comment #4) > Did you even read the ebuild? You are right, but it wouldn't break 32bit archs > because it was being applied only to amd64.. > Which is a bad method to apply patches :)
No, I didn't read the ebuild (you marked it as application/octet-stream, was simply too much of an effort for me, and as I know how to apply patches I didn't bother anyway). However, we prefer to apply patches unconditionally whenever possible, which is the case here.
Created attachment 99082 [details] nam-1.11-r1.ebuild
Created attachment 99083 [details, diff] nam-1.11-fix-address-size.patch
(In reply to comment #6) > No, I didn't read the ebuild (you marked it as application/octet-stream, was > simply too much of an effort for me, and as I know how to apply patches I > didn't bother anyway). However, we prefer to apply patches unconditionally > whenever possible, which is the case here. > Ok, sorry for submitting bad stuff, does it look good now?
Comment on attachment 99083 [details, diff] nam-1.11-fix-address-size.patch I'm sorry, but this patch doesn't fix the issue either, it only makes nam compile fine. Fex the chunk in group.cc:81 casts it to long, but mbrs[] is a int[] array, so it will just get truncated at the next occation. Plus, the arguments to that function are given as int, then casted into a (const char *). The chunks in netmodel.cc cast a void * to a int/long, but I wonder why it is doing it in the first place. Also, the function is defined with return type int instead of long, but I really wonder why it is even casted to an int when it deals with pointers anyway. In short, this app is a mess, and requires a bit more work. It probably should have never gotten the ~amd64 keyword in the first place. As nothing depends on it, i marked it -amd64 for the time being. Patches are still welcome though :)
Created attachment 102189 [details, diff] x86_64 and GCC 4.1.1 patch This seems to be a TCL issue and nam just inherits it. If you declare NO_VOID for the nam compile everything works fine. As for the (const char*) typecast, I dont know why it is done that way but I see a lot of TCL/Tk code do that. Attached is a patch that cleans up for AMD and should work for i386 platforms also though I haven't tested it. I will post the patch in the nam-developers list. It is diff'd against the latest CVS code of nam. Can we please set it to ~amd64 if the patch works :)
Please reopen this bug once upstream has incorporated the patches. Sadly we don't have enough manpower to focus on packages that are not even marked ~amd64.