First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 57349
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: GCC Porting Team <gcc-porting@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Sudrien <sudrien@fusemail.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 57349 depends on: Show dependency tree
Show dependency graph
Bug 57349 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-07-16 19:01 0000
im-ja-1.1 has a runtime error when compile with gcc 3.4.0, the fix shown at
http://sourceforge.net/mailarchive/forum.php?thread_id=4928258&forum_id=29602

A bug with similar symptoms shows up in im-ja-1.2, described at
http://sourceforge.net/mailarchive/forum.php?thread_id=5115378&forum_id=29602

Reproducible: Always
Steps to Reproduce:
1.emerge gcc-3.4.0
2.emerge im-ja
3.im-ja-conf (segfaults)

------- Comment #1 From Denis Dupeyron 2004-09-20 00:41:26 0000 -------
Confirmed here.

I recently duplicated my root partition, updated to gcc 3.4 on the copy and re-compiled everything. im-ja-conf would give me the exact same error.

The funny thing is when I changed the profile back to gcc-3.3.4 and re-emerged im-ja, it wouldn't work either. No segfault, but japanese input didn't work and im-ja-conf would give me a "GConf-CRITICAL error" when trying to apply changes (even if there were none). I'm not on that machine right now, so I can't provide the exact output, but I will if you need it. I tried re-emerging im-ja with USE="debug" and it wasn't more explicit. For info, the /home partition containing the user settings for gnome, im-ja and so on was the same.

So, my point is that there could also be a gcc-3.4 issue in one of im-ja dependencies. I'm not sure about that though, as I'm far from an expert at such things. I'll keep this experimental root partition for a while in cas it's needed for testing.

------- Comment #2 From Denis Dupeyron 2004-09-27 11:33:52 0000 -------
I redid the whole thing (duplicated root partition, updated to gcc-3.4,
re-emerged system and world), just for testing. There were a few things to fix,
but im-ja now works when compiled with gcc-3.3 in an otherwise full gcc-3.4
setup. Some package was surely updated, and I'm ashamed I couldn't find out
which one was the culprit.

A fix for the gcc-3.4 compilation issue is in the im-ja CVS, but no patch
exists that I know of, so I guess we'll have to wait for the next release.

So, my interim solution is:
1. gcc-config i686-pc-linux-gnu-3.3.4 (or whatever your gcc-3.3 version is)
2. emerge im-ja
3. gcc-config i686-pc-linux-gnu-3.4.2 (or whatever your gcc-3.4 version is)
4. restart your gnome session if you were in gnome

------- Comment #3 From Mamoru KOMACHI (RETIRED) 2004-10-01 02:01:23 0000 -------
k, I added a patch extracted from CVS. Please test.

------- Comment #4 From Sudrien 2004-10-01 12:14:43 0000 -------
Sorry, 1.2.0-r1 did not seem to work. Perhaps a CVS snapshot? Documentation
doesn't currently build from CVS, but the main program is fine.

-Sud.

------- Comment #5 From Denis Dupeyron 2004-10-05 14:49:24 0000 -------
im-ja-1.2.0-r1 doesn't solve the issue here either. When compiled with gcc 3.3
it runs OK, though.

------- Comment #6 From Mamoru KOMACHI (RETIRED) 2004-10-06 01:24:45 0000 -------
Yes, it was taken from im-ja CVS, as of 20041001. Charun,
could you confirm that the issue is fixed in the im-ja CVS 
but is not fixed in im-ja-0.12-r1? They should be identical though...

------- Comment #7 From Denis Dupeyron 2004-10-06 14:14:51 0000 -------
OK, I've found something.

I just did a cvs extraction. In order to be able to uninstall cleanly I decided to copy the 1.2-r1 ebuild to 1.2-r2, create a patch from my cvs directory, and edit my newly created ebuild to adapt it to the new patch. And it wouldn't work. I was puzzled so I went back to the original 1.2-r1 ebuild, and tried to install it step-by-step using the ebuild command. Here's what I get:

vortex im-ja # ebuild im-ja-1.2-r1.ebuild unpack
>>> md5 src_uri ;-) im-ja-1.2.tar.gz
>>> md5 src_uri ;-) im-ja-1.2-20041001.diff.gz
>>> Unpacking source...
>>> Unpacking im-ja-1.2.tar.gz to /var/tmp/portage/im-ja-1.2-r1/work
/usr/portage/app-i18n/im-ja/im-ja-1.2-r1.ebuild: line 42: epatch: command not found
>>> Source unpacked.

The patch is not applied. That's why 1.2-r1 behaves exactly the same way as 1.2. Instead of fixing the ebuild, I went ahead and patched manually, like this:

vortex im-ja # cd /var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/
vortex im-ja-1.2 # gzcat /usr/portage/distfiles/im-ja-1.2-20041001.diff.gz | patch -p0
patching file ChangeLog
patching file TODO
patching file configure.in
patching file po/ja.po
patching file src/conf.c
patching file src/conf.h
patching file src/error.h
patching file src/im-ja.c
patching file src/im-ja.h
patching file src/preeditwin.c
patching file src/statuswin.c
patching file src/iiimf/Makefile.am
patching file src/im-ja-conf/about-box.c
patching file src/wnn/wnn.c
patching file src/xim/xim-server.c

It worked. Then I tried compiling, but it failed:

vortex im-ja-1.2 # cd /usr/portage/app-i18n/im-ja/
vortex im-ja # ebuild im-ja-1.2-r1.ebuild compile

[...configures OK, starts compiling OK, but...]

gcc -Os -march=athlon-xp -fomit-frame-pointer -pipe -ffast-math -ftracer -o kpengine kpengine-kpengine.o kpengine-scoring.o kpengine-util.o kpengine-error.o -Wl,--export-dynamic  /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangoxft-1.0.so /usr/lib/libpangox-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so
make[3]: Leaving directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/src/kanjipad'
make[3]: Entering directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/src'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/src'
make[2]: Leaving directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/src'
Making all in gnome
make[2]: Entering directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/gnome'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/gnome'
Making all in data
make[2]: Entering directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/data'
LC_ALL=C ../intltool-merge -s -u -c ../po/.intltool-merge-cache ../po im-ja.schemas.in im-ja.schemas
Found cached translation database
Merging translations into im-ja.schemas.
make[2]: Leaving directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/data'
Making all in po
make[2]: Entering directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/po'
file=./`echo ja | sed 's,.*/,,'`.gmo \
  && rm -f $file && /usr/bin/gmsgfmt -o $file ja.po
/usr/bin/gmsgfmt: error while loading shared libraries: libgettextlib-0.12.1.so: cannot open shared object file: No such file or directory
make[2]: *** [ja.gmo] Error 127
make[2]: Leaving directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2/po'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/im-ja-1.2-r1/work/im-ja-1.2'
make: *** [all] Error 2

!!! ERROR: app-i18n/im-ja-1.2-r1 failed.
!!! Function src_compile, Line 59, Exitcode 2
!!! emake im-ja failed
!!! If you need support, post the topmost build error, NOT this status message.

If I look back in the configure phase, I can see this:

checking for xgettext... /usr/bin/xgettext
found xgettext program is not GNU xgettext; ignore it

I hope this can help. I have to give up for today. I'll check back on this tomorrow.

------- Comment #8 From Denis Dupeyron 2004-10-06 14:35:23 0000 -------
Sorry, I forgot 2 things. The first one is that if I configure and make
manually in the cvs directory, it produces the exact same error. Second thing
is more annoying:

vortex im-ja-20041006 # locate libgettextlib-0.12.1.so
/usr/lib/libgettextlib-0.12.1.so

So why can't gmsgfmt find it ? No idea... Now I'm off to put my eyes to sleep.

------- Comment #9 From Mamoru KOMACHI (RETIRED) 2004-10-06 23:07:23 0000 -------
Oh, sorry. epatch issue (inherit eutils is missing; sorry for sucn a simple
mistake :/)
was fixed by lv on 6 Oct, so if you haven't got the update, please run `emerge
sync`.

Botond, could you take a look at this problem? 

------- Comment #10 From Botond Botyanszki 2004-10-07 05:02:28 0000 -------
The compilation error is a gettext issue.  Try `ldd /usr/bin/gmsgfmt` to see
what is linked to it.

Back to the topic, there are many fixes in the CVS tree, including the gcc-3.4
segfault fix. I'm not sure when I'll release the new version, so I think a CVS
snapshot as 1.2-r2 ebuild with the diff against the 1.2 release would be the
best.

------- Comment #11 From Denis Dupeyron 2004-10-07 05:19:26 0000 -------
I re-emerged gettext and a few of its reverse dependencies, so now im-ja
compiles and works with gcc-3.4.

Thanks Mamoru and Botond for looking into this.

------- Comment #12 From Mamoru KOMACHI (RETIRED) 2004-10-13 15:37:59 0000 -------
Thanks Botond and thanks Charun for testing.
im-ja-1.2-r1 failed because it isn't patched up to CVS-20041001
(and is fixed now).

I'm closing the bug.

First Last Prev Next    No search results available      Search page      Enter new bug