Trying to emerge ekiga always fails with a segmentation fault during "Generating and caching the translation database". A similar case is discussed at http://www.freebsd.org/cgi/query-pr.cgi?pr=120824 and http://forums.gentoo.org/viewtopic.php?p=5184370. The ithreads USE flag is not enabled for perl and libperl. Emerging opal again does not help. Setting locales and running locale-gen does not help. file=`echo wa | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/gmsgfmt -o $file wa.po file=`echo xh | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/gmsgfmt -o $file xh.po file=`echo zh_CN | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/gmsgfmt -o $file zh_CN.po file=`echo zh_HK | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/gmsgfmt -o $file zh_HK.po file=`echo zh_TW | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/gmsgfmt -o $file zh_TW.po make[2]: Leaving directory `/var/tmp/portage/net-im/ekiga-2.0.12/work/ekiga-2.0.12/po' make[2]: Entering directory `/var/tmp/portage/net-im/ekiga-2.0.12/work/ekiga-2.0.12' LC_ALL=C ./intltool-merge -d -u -c ./po/.intltool-merge-cache ./po ekiga.desktop.in ekiga.desktop LC_ALL=C ./intltool-merge -s -u -c ./po/.intltool-merge-cache ./po ekiga.schemas.in ekiga.schemas Generating and caching the translation database Generating and caching the translation database make[2]: *** [ekiga.desktop] Segmentation fault make[2]: *** Waiting for unfinished jobs.... make[2]: *** [ekiga.schemas] Segmentation fault make[2]: Leaving directory `/var/tmp/portage/net-im/ekiga-2.0.12/work/ekiga-2.0.12' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-im/ekiga-2.0.12/work/ekiga-2.0.12' make: *** [all] Error 2 * * ERROR: net-im/ekiga-2.0.12 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2998: Called gnome2_src_compile * environment, line 2205: Called die * The specific snippet of code: * emake || die "compile failure" * The die message: * compile failure * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/net-im:ekiga-2.0.12:20080815-192727.log'. * The ebuild environment file is located at '/var/tmp/portage/net-im/ekiga-2.0.12/temp/environment'. * # emerge --info Portage 2.1.4.4 (default/linux/amd64/2008.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.17-gentoo-r4 x86_64) ================================================================= System uname: 2.6.17-gentoo-r4 x86_64 AMD Athlon(tm) 64 FX-51 Processor Timestamp of tree: Fri, 15 Aug 2008 02:15:03 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" 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="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/science /usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X acl alsa amd64 apache2 berkdb bonobo bzip2 cairo cdr cli cracklib crypt cups dbus dlloader dri firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog java jpeg kerberos lcms ldap mailwrapper midi mmx mono motif mpeg mpi mudflap multilib mysql ncurses nls nptl nptlonly opengl openmp pam pcre pdf perl png postscript pppd python readline reflection samba sdl session snmp spl sse sse2 ssl sysfs tcpd tiff truetype type1 unicode usb xml xorg zlib" 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="actions alias auth_basic auth_digest authn_anon authn_dbd 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 dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
emerge -av pwlib These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-libs/pwlib-1.10.10-r1 USE="alsa debug ipv6 ldap sasl sdl ssl xml -ieee1394 -oss -v4l -v4l2" 0 kB And I tried to emerge it again, but nothing change.
Sorry, could you erase my two answears, I have mistaken :s (In reply to comment #1) > emerge -av pwlib > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] dev-libs/pwlib-1.10.10-r1 USE="alsa debug ipv6 ldap sasl sdl > ssl xml -ieee1394 -oss -v4l -v4l2" 0 kB > > And I tried to emerge it again, but nothing change. >
I had the same problem. The problem is not with gcc, nor with glibc, but with the builtin intltool-merge that comes with ekiga, for some strange reason. To fix it, we simply hack the "configure" script to use our system intltool perl scripts. Add the following line at the end of src_unpack() in the ebuild: sed -i -e 's#$(top_builddir)/intltool-#intltool-#' configure (PS. The solution mentioned in the freebsd mailing list, http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2008-February/136275.html , that is only removing dz.po, didn't work for me.)
(I am using gcc-4.3.2 and glibc-2.8_p20080602, and had the same problem. Not that that matters :)
> Add the following line at the end of src_unpack() in the ebuild: > > sed -i -e 's#$(top_builddir)/intltool-#intltool-#' configure Thanks! It worked.
(In reply to comment #5) > > Add the following line at the end of src_unpack() in the ebuild: > > > > sed -i -e 's#$(top_builddir)/intltool-#intltool-#' configure > > Thanks! It worked. > I can't reproduce this bug. Can you give me the output of `emerge -pv perl` ? I have exactly the same gcc and glibc version and tried to compile ekiga-2.0.12 with perl emerged with +ithreads.
Very strange. [ebuild U ] dev-lang/perl-5.8.8-r5 [5.8.8-r4] USE="berkdb gdbm -build -debug -doc -ithreads -perlsuid" 0 kB For us, the problem is *definitely* in the intltool-merge script that comes with the package. (While the package is compiling, if I simply overwrite the bundled version of that script with my local /usr/bin/intltool-merge, it works.) I'll try to investigate further about what in particular is wrong with their version. A quick diff didn't show any glaring differences :|. (I don't think perl ithreads makes any difference?)
(In reply to comment #7) > (I don't think perl ithreads makes any difference?) > According to the FreeBSD team, it is linked with threaded perl. See this link : http://www.freebsd.org/cgi/query-pr.cgi?pr=120824 Better to find why this is not working even if a work-around has been found.
I sortof found the problem, though I'm missing the last piece of the puzzle--namely, why doesn't everyone have this problem? The problem was in po/as.po (with ekiga 2.0.12. i guess it was with dz.po in 2.0.11 as the freebsd thread suggests) on line 1884--which is a strange line--i'm not sure if it's actual Assamese, or a buggy po file--, specifically, the way intltool-merge 0.35.0 (which ships with ekiga) handles it. Specifically, in the perl function sub create_translation_database, in the while (<PO_FILE>) loop, that is, while it's parsing the po file, all three of the regexes are missing a "+" symbol. That's all :). intltool-0.40.5 has this. So, to handle line 1884 of po/as.po, this needs to be changed to avoid segfaulting.. < if (/^"((\\.|[^\\])*)"/) --- > if (/^"((\\.|[^\\]+)*)"/) If anyone knows why this segfaults on some machines and not others, or what is up with as.po lines 1884-1890, I'm really curious! So, I guess we could patch the bundled intltool-merge file--at least those 3 regexes, or we can just use our working version. But, if we do insist on using the older (buggy?) bundled version, we don't need intltool as a dependency, right?
(In reply to comment #9) > So, I guess we could patch the bundled intltool-merge file--at least those 3 > regexes, or we can just use our working version. But, if we do insist on using > the older (buggy?) bundled version, we don't need intltool as a dependency, > right? > I don't know why intltool is bundled because it is also required by ekiga. I tried to found out why ekiga did that but I did not found anything. But I realized ekiga-3* is not using a bundled version of intltool. I think it could be better to use system version instead of the old and buggy version bundled into ekiga.
Created attachment 180948 [details, diff] Patch to use system intltools Add the sed command from Dennis in the ebuild so the system intltools is used instead of the old buggy bundled one.
A couple further points. First of all, I'm pretty sure as.po is indeed corrupted in lines 1884-1890. Those 6 "strings" are over 227KB big, which is bigger than any of the other /complete/ po files. But, that being said, it's no excuse to segfault perl! ;b The real problem, I'm pretty sure, is that my perl is not opening that file as a utf8 file here. And, for some strange reason, I guess it is opening it properly for you. Maybe you have a newer version of perl which does a better job at guessing what encoding a file is in. Anywho, if I force it to open it as a utf8 file: open PO_FILE, "<:utf8", "as-test.po"; instead of guessing: open PO_FILE, "<as-test.po"; ...it works. I'm not really sure how having that + in the regex managed to fix it, or how reliable it would be with other broken inputs. (Getting rid of the * also would prevent the segfault here, (though it wouldn't catch lines with multiple escaped newlines like "\n\n"), as would getting rid of the OR clause entirely, though that would defeat the purpose of the regex which ensures newlines are properly formatted :b, as would making the first part of the OR clause a single character. Sigh :P) Here is the small perl script I used to test the broken po.file, which I cropped around the broken lines: ################### #!/usr/bin/perl -w open PO_FILE, "<as-test.po"; while (<PO_FILE>) { if (/^"(xy|[^z]+)*"/) { print "yes\n"; } else { print "no\n"; } } ################### To summarize, the following things would prevent the segfault: (1) open PO_FILE, "<:utf8", "as-test.po"; (2) if (/^"(xy|[^z]+)*"/) ... # + (3) if (/^"(x|[^z])*"/) ... # 1-char in 1st part of OR (4) if (/^"(xy|[^z])"/) ... # no * (5) if (/^"(xy|([^z]*))"/) ... # * INSIDE 2nd part of OR (6) if (/^"((xy)*|([^z])*)"/) ... # same as above, except functional :b (7) if (/^"([^z])*"/) ... # no OR clause The old original regex, without the +, should have been interpreted as (6), the * should have been "distributed" to each half of the OR clause, but, I guess, it screws up internally if it isn't properly represented as utf8. I'm going to go do something useful now :b.
(In reply to comment #11) > Created an attachment (id=180948) [edit] > Patch to use system intltools > > Add the sed command from Dennis in the ebuild so the system intltools is used > instead of the old buggy bundled one. > I couldn't exactly reproduce this problem either but I applied the patch to 2.0.12 because it shouldn't hurt.
