As a result, any 32bit app using the conversion facility (e.g. new Acroread-7.0 beta) will crash. Binary patching the library eliminates the crashes. Reproducible: Always Steps to Reproduce: # strings /lib32/libc.so.6 | grep '/usr/.*/gconv' Actual Results: /usr/lib/gconv /usr/lib/gconv/gconv-modules.cache Expected Results: /usr/lib32/gconv /usr/lib32/gconv/gconv-modules.cache
Looks like this is the cause of bug #72030 also. It is interesting to note that this is still a problem with the locally compiled glibc used in the 2005.0 profile (sys-libs/glibc-2.3.4.20050125). A simple workaround is to set GCONV_PATH="/usr/lib32/gconv" prior to running the app.
> A simple workaround is to set GCONV_PATH="/usr/lib32/gconv" Indeed; I wasn't aware of this. Thanks!
added toolchain@g.o to the CC as this appears to be a glibc problem.
No toolchain problem... Either me of eradicator forgot to patch glibc for the emul package.
This is also causing the new acroread 7.0 to abort.
> This is also causing the new acroread 7.0 to abort. That's what was said in the original post, wasn't it?
looking at the glibc ebuild it seems that the 32bit glibc is compiled with --libdir=lib export LIBDIR_x86="lib" and the files get moved to lib32: mv ${D}/lib ${D}/$(get_libdir) Some nasty sed lines are later called to correct some hardcoded paths (but clearly not all of them): dosed "s:/lib/:/$(get_libdir)/:g" /usr/$(get_libdir)/lib{c,pthread}.so Is there any reason that it is compiled in this way? why not just compile the 32bit glibc with libdir=lib32 in the first place?
Fixed as of sys-libs/glibc-2.3.4-20050125-r1. *** This bug has been marked as a duplicate of 86861 ***
