There's some sort of problem with libintl/gettext... build log attached. Note that this problem only occurs with USE="nls" - without, the build completes successfully. $ emerge --info Portage 2.2.00.15335-prefix (prefix/darwin/macos/10.6/x64, gcc-4.2.1, unavailable, 10.2.0 x86_64) ================================================================= System uname: Darwin-10.2.0-x86_64-i386-64bit Timestamp of tree: Thu, 18 Feb 2010 09:35:41 +0000 distcc 2.18.5-Apple.1 i386-apple-darwin10.0 (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.9-r1 dev-lang/python: 2.6.4 dev-python/pycrypto: 2.1.0 sys-devel/autoconf: 2.63-r01.1 sys-devel/automake: 1.10.2-r00.1, 1.11.1 sys-devel/gcc-config: 1.4.1-r00.2 sys-devel/libtool: 2.2.6b ACCEPT_KEYWORDS="x64-macos x86-macos ~amd64 ~x64-macos ~x86 ~x86-macos" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-apple-darwin10" CFLAGS="-O2 -fno-math-errno -march=core2 -msse4.1 -mfpmath=sse -pipe" CHOST="x86_64-apple-darwin10" CONFIG_PROTECT="/etc /opt/gentoo/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /opt/gentoo/etc/ca-certificates.conf /opt/gentoo/etc/env.d /opt/gentoo/etc/env.d/java/ /opt/gentoo/etc/fonts/fonts.conf /opt/gentoo/etc/gconf /opt/gentoo/etc/revdep-rebuild /opt/gentoo/etc/terminfo" CXXFLAGS="-O2 -fno-math-errno -march=core2 -msse4.1 -mfpmath=sse -pipe" DISTDIR="/opt/gentoo/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages metadata-transfer news nostrip parallel-fetch preserve-libs protect-owned sfperms splitdebug strict unmerge-logs unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="" LINGUAS="en en_GB" PKGDIR="/opt/gentoo/usr/portage/packages" PORTAGE_CONFIGROOT="/opt/gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/opt/gentoo/var/tmp" PORTDIR="/opt/gentoo/usr/portage" PORTDIR_OVERLAY="/opt/gentoo/usr/local/portage" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="X aqua ares bash-completion berkdb bzip2 cairo chroot common-lisp coreaudio cracklib cxx expat faac faad fftw flac fontconfig fts3 gdbm gmp graphviz gs gtk hpn iconv icu idea ipv6 ithreads java jbig jpeg jpeg2k lcms lzma md5sum mmap mmx mmxext modules mp3 ncurses network nls objc objc++ ogg openmp pcre perl png prefix python rar readline sasl schroedinger slang sndfile speex spell sqlite sqlite3 sse sse2 ssl svg tcl test theora threads tiff tk trace truetype unicode urandom utils vdpau vim-syntax vorbis wmf x264 x64-macos xinerama xml xpm xvid zlib" APACHE2_MODULES="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 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" ELIBC="Darwin" INPUT_DEVICES="keyboard mouse" KERNEL="Darwin" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB" RUBY_TARGETS="ruby18" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
build.log ? :)
Yes, sorry - I tried uploading five times earlier today, and got an error *every* time...
It's only a 37k attached, yet I get the following every time! "Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmaster@gentoo.org and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache Server at bugs.gentoo.org Port 80"
Created attachment 220261 [details] eix-0.20.1 build.log with USE="nls" Hmm - unless it's a Safari bug whereby it isn't reported when a file selected for uploading isn't actually readable?
Yup - looks like that's a Safari bug.
I suppose that Mac OS X has no libc containing libintl, but since you have virtual/libnintl installed this is provided by something else? However, then AM_GNU_GETTEXT([external]) should either add linkflags for the libraries or drop the support, so I do not understand why there are errors. Which was the last version of eix which built successfully? If it was eix-0.17.*/eix-0.18.*, eix might have to provide libtools again (I removed libtools support in eix-0.19,0 since from the documentation of AM_GNU_GETEXT it seemed to be unneeded). If this removal caused the breakage, the attached patch should fix the problem. Note that after the patch you must call autotools in the proper way; I attach also a corresponding patch for the ebuild which does this (the ebuild patch assumes that the other patch is in files/libtool.patch). Please report back whether this helps (and if not: which was the eix version introducing the breakage?).
Created attachment 220329 [details, diff] libtool.patch Save into files/libool.patch
Created attachment 220331 [details, diff] Patch for eix-0.20.1.ebuild
My summary.log would suggest that the last installed version was app-portage/eix-0.17.0, installed 2009-10-02 01:17:51 BST. I thought I was using 0.19.x, but that was most likely on other systems. To install the patched eix, autoconf had to be manually installed (since neither 2.64 or 2.65 are keyworded at all) - and the test-suite for this did record a couple of unexpected failures: 188: parallel autotest and signal handling FAILED (autotest.at:1300) 217: Substitute and define special characters FAILED (torture.at:919) On attempting to build the patched eix, emerge fails with: >>> Emerging (1 of 1) app-portage/eix-0.20.1 * eix-0.20.1.tar.xz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: app-portage/eix-0.20.1 * REPO: gentoo_prefix * USE: bzip2 elibc_Darwin kernel_Darwin nls prefix sqlite test tools userland_GNU x64-macos >>> Unpacking source... >>> Unpacking eix-0.20.1.tar.xz to /opt/gentoo/var/tmp/portage/app-portage/eix-0.20.1/work >>> Source unpacked in /opt/gentoo/var/tmp/portage/app-portage/eix-0.20.1/work >>> Preparing source in /opt/gentoo/var/tmp/portage/app-portage/eix-0.20.1/work/eix-0.20.1 ... * Applying libtool.patch ... [ ok ] * Running eautoreconf in '/opt/gentoo/var/tmp/portage/app-portage/eix-0.20.1/work/eix-0.20.1' ... * Running aclocal -I m4 -I martinm4 -I /opt/gentoo/usr/share/aclocal ... [ ok ] * Running glibtoolize --copy --force --install --automake ... [ ok ] * Running aclocal -I m4 -I martinm4 -I /opt/gentoo/usr/share/aclocal ... [ ok ] * Running autoconf ... [ !! ] * Failed Running autoconf ! * * Include in your bugreport the contents of: * * /opt/gentoo/var/tmp/portage/app-portage/eix-0.20.1/temp/autoconf.out * ERROR: app-portage/eix-0.20.1 failed: * Failed Running autoconf ! * * Call stack: * ebuild.sh, line 54: Called call-ebuildshell 'src_prepare' * environment, line 446: Called src_prepare * environment, line 2868: Called eautoreconf * environment, line 921: Called eautoconf * environment, line 859: Called autotools_run_tool 'autoconf' * environment, line 362: Called die * The specific snippet of code: * die "Failed Running $1 !"; ... and /opt/gentoo/var/tmp/portage/app-portage/eix-0.20.1/temp/autoconf.out reads: ***** autoconf ***** ***** PWD: /opt/gentoo/var/tmp/portage/app-portage/eix-0.20.1/work/eix-0.20.1 ***** autoconf configure.ac:85: error: possibly undefined macro: AM_SILENT_RULES If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.
(In reply to comment #9) > configure.ac:85: error: possibly undefined macro: AM_SILENT_RULES My mistake: Please add "WANT_AUTOMAKE=1.11" to the ebuild before the inherit line (or export that variable before emerging - I have it exported, that's why I did not see this mistake).
Created attachment 220555 [details] eix-0.20.1 build.log with USE="nls" and libtool patch Built as requested with libtool patch: Appears to be identical failure.
Created attachment 220573 [details, diff] Replacement for previous files/libtool.patch Thanks for trying. After comparing with eix-0.17 and rereading some docs, I remembered that LTLIBINTL must be used instead of LIBINTL to make the libtool result active for linking. It would be nice if you could retry with this new patch (it replaces the old one, since it now also uses non-obsolete libtool initialization just in case [>=libtool-2.2 is needed]). If this doesn't help either, I am afraid that I am running out of ideas...
Bump... Does the corrected libtool.patch now solve the problem?
Sorry - this slipped my mind. I'm afraid that the latest patch also makes no difference: eix-0.20.1 still compiles successfully on MacOS with USE="-nls", but with USE="nls", compilation still fails with many errors similar to "Undefined symbol: _libintl_gettext".
(In reply to comment #14) > I'm afraid that the latest patch also makes no difference I was rather hopeful that this should solve the problem: On the eix side, I cannot see any difference concerning gettext linking compared to eix-0.17.0 (after the patch). So I guess that I can summarize the experiment that the problem was *not* caused by the eix-0.19.0 removal of libtool; hence, we should forget about the previous patches, and I will not include libtool in the next release. Perhaps something from the current autotools or gettext is broken on OS X (or at least on your installation)? I admit that this appears unlikely, but I find no other explanation. There is some OS-X-specific code in autools support for gettext, so maybe something strange was changed. It might help to read/post the content of config.log [which you find in the work directory]; at least the section containing the output variables might be useful, in particular the LIBINTL, LTLIBINTL, INTL_MACOSX_LIBS variables. Can you please verify whether these are the names of the ibraries on your system installed by gettext? Is the content of INTL_MACOSX_LIBS appended to LIBINTL? Are the values different if you try the same with libtool (i.e. with the patches in this bug)? And finally: Does manually adding -Wl,-framework -Wl,CoreFoundation to your LDFLAGS make the thing compile?
Created attachment 221989 [details] eix-0.20.1 config.log This config.log was produced with LDFLAGS set to include the CoreFoundation framework - but from the looks of the *INTL* variables, this likely wasn't necessary. Any clues here?
Oh, and gettext installs the following libraries: /opt/gentoo/usr/lib/gettext/hostname* /opt/gentoo/usr/lib/gettext/project-id* /opt/gentoo/usr/lib/gettext/urlget* /opt/gentoo/usr/lib/gettext/user-email* /opt/gentoo/usr/lib/libasprintf.0.0.0.dylib* /opt/gentoo/usr/lib/libasprintf.0.dylib -> libasprintf.0.0.0.dylib* /opt/gentoo/usr/lib/libasprintf.a /opt/gentoo/usr/lib/libasprintf.dylib -> libasprintf.0.0.0.dylib* /opt/gentoo/usr/lib/libasprintf.la /opt/gentoo/usr/lib/libgettextlib-0.17.dylib* /opt/gentoo/usr/lib/libgettextlib.dylib -> libgettextlib-0.17.dylib* /opt/gentoo/usr/lib/libgettextlib.la /opt/gentoo/usr/lib/libgettextpo.0.4.0.dylib* /opt/gentoo/usr/lib/libgettextpo.0.dylib -> libgettextpo.0.4.0.dylib* /opt/gentoo/usr/lib/libgettextpo.a /opt/gentoo/usr/lib/libgettextpo.dylib -> libgettextpo.0.4.0.dylib* /opt/gentoo/usr/lib/libgettextpo.la /opt/gentoo/usr/lib/libgettextsrc-0.17.dylib* /opt/gentoo/usr/lib/libgettextsrc.dylib -> libgettextsrc-0.17.dylib* /opt/gentoo/usr/lib/libgettextsrc.la /opt/gentoo/usr/lib/libintl.8.0.2.dylib* /opt/gentoo/usr/lib/libintl.8.dylib -> libintl.8.0.2.dylib* /opt/gentoo/usr/lib/libintl.a /opt/gentoo/usr/lib/libintl.dylib -> libintl.8.0.2.dylib* /opt/gentoo/usr/lib/libintl.la
Isn't there a macro for detecting libintl stuff? There are some tricky conditions on how to check for that (as well as iconv). On OSX you only need -lintl, none of the framework stuff.
(In reply to comment #18) > Isn't there a macro for detecting libintl stuff? There is, and it is used by eix in a completely standard manner: AM_GNU_GETTEXT_VERSION([0.17]) AM_GNU_GETTEXT([external]) (and then eix_LDADD=... $(LIBINTL) in the corresponding Makefile.am). That's why I do not understand where these problems come from. Since the macro can be used in two ways (with libtool and without libtool; in the former case LIBINTL has to be replaced by LTLIBINTL), and since this and an upgrade of autotools was the only change since eix-0.17 which I can imagine to be related, I though that this libtool removal was the problem. But apparently it was not. So it appears to me that AM_GNU_GETTEXT is broken for OS X in current autotools. But then again, everything seems to be correct: > On OSX you only need -lintl, none of the framework stuff. eix does not care about it manually, it just relies on the AM_GNU_GETTEXT macro. However, I inspected this macro and it contains special code to link with the framework stuff (if possible), and this code contains a comment that this is necessary on some OS X systems. Anyway, it shouldn't hurt to link with an unneeded library (it might be inconvenient since it introduces a redundant dependency, but it should not hurt). And obviously -lintl is contained, so I do not understand why the symbols in this library are not found. The only strange thing which I see are some segfault during the linking: How can linking a library with unknown symbols cause a segfault? Maybe some of the libraries eix tries to link to are damaged? @Stuart: Just to make sure that there is not just a stupid typo I am overlooking: Please try to emerge (the original) eix-0.20.1 with either MAKEOPTS="V=1" (or alternatively EXTRA_ECONF="--disable-silent-rules"). Then you should see the full command used for linking (which crashes). Does that command contain -lintl and all the other stuff from LIBINTL? What if you go after the error manually in that directory and try the same call with reordered libraries (and/or some of the -Wl,-framework -Wl,CoreFoundation -liconv removed)? Maybe you can find out this way which one causes the segfault and why (perhaps reemerging the corresponding library fixes the problem? Or maybe you have some orphaned .a or .dylib file for the corresponding library somewhere?)
I think the segfault in the linker is caused by a missing call to unroll, as part of the linker trying to throw an error. This is a icky issue, but should only happen when an error occurs that the linker wants to die on.
Checking the logs once more, I still cannot find anything strange: Unless I made a stupid typo in src/Makefile.am, these flags are appended -L/opt/gentoo/usr/lib -lintl -liconv -lc -Wl,-framework -Wl,CoreFoundation So why is e.g. _libintl_gettext undefined? (Actually, it is not clear to me completely where this name comes from: eix uses #include <libintl.h> and then later just gettext(), not _libintl_gettext(); of course, some macros in libintl.h might cause this...). @Stuart: Since everything seemed to work with eix-0.17.0: What is the value for LTLIBINTL (in config.log) which eix-0.17.0 determined on your machine?
*** Bug 313267 has been marked as a duplicate of this bug. ***
After the comments in bug 313267, the problem should now finally be solved (I somehow did not realize that you were also using USE=tools which was the problem: I forgot to add the libraries found by configure to the linking of the versionsort binary in Makefile.am. It should have been clear from the build.log that it was not the linking of the eix binary which failed, but somehow I missed that point...). Current eix svn trunk (>=eix-0.20.4) should contain the bugfix.
Closing, since eix-0.20.4 is now in the tree which should fix the issue.
