Summary: | net-im/ekiga-2.0.12 won't emerge with gcc 4.1.2 and glibc-2.6.1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Bleszynski <bleszynski> |
Component: | Current packages | Assignee: | voip herd (OBSOLETE) <voip+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dennisn, volkmar |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to use system intltools |
Description
Peter Bleszynski
2008-08-15 20:03:32 UTC
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. |