In 'libjava/classpath/lib/Makefile.gcj' it wants to use '$(GCJ) -Wno-deprecated --encoding=UTF-8' which fails on parsing files. It cannot read '~' signs. A diff to workaround this will be attached. Reproducible: Always Steps to Reproduce: 1. USE="gcj gtk" emerge =gcc-4.1.0_beta20051125 Actual Results: 'make -f /var/tmp/portage/gcc-4.1.0_beta20051125/work/gcc-4.1-20051125/libjava/classpath/lib/Makefile.gcj' produces a SIGCHLD and gets killed. Expected Results: finish install nb work # emerge info Portage 2.0.53_rc7 (default-linux/x86/2005.1, gcc-4.1.0-beta20051125, glibc-2.3.6-r1, 2.6.14-gentoo-r3 i686) ================================================================= System uname: 2.6.14-gentoo-r3 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.12.0_pre11 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.91.0.4 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi alsa berkdb cairo cdr cups dvd dvdr dvdread firefox gif gnome gtk2 jpeg mmx mmxext nls pam png readline sse sse2 ssl tiff unicode usb utf8 x86 xml2 zlib linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
Created attachment 73761 [details, diff] change encoding from UTF-8 to iso8859-15
i think it may be because you're using de_DE as your LANG/LC_ALL ... if you set them to "C", do you still need that patch ? psm pointed out a while ago that Fedora has some de_DE specific funk in their gcc.spec files ...
'LANG="C" LC_ALL="C" emerge gcc' That fixed the issue. How is the planned solution?
i wonder if having LANG/LC_ALL does anything useful for gcc or if we should just force it to C for everyone
I talked to one OOo developer and this issue is fixed in OOo source. There were some non-utf8 characters in the source. Remember, it wants '--encoding=UTF-8'. I check gcj source for some non-utf8 characters.
I did 'LANG="en_US.utf8" LC_ALL="en_US.utf8" emerge gcc' to test. It merged fine. You may do some 'LANG = *.utf8' and 'LC_ALL = *.utf8' checks and change them to en_US.utf8. That is better than forcing LANG/LC_ALL to 'C'. If de_DE.utf8 is known to break you may only do checks for that. Alternative: Set this bug to INVALID. People will find this bug and see its cause. A broken locale set.
I would propose following, independently of the user set locales, we do not know for sure if those locales really exist on the system. One way to overcome this on glibc is to read the env, create a subdir and create the needed locales in that subdir w/ localedef -f ISO-8859-1 -i de_DE locale/de_DE. Haven't checked current gcc, but earlier it had LOCPATH, that we could define to export LOCPATH="`pwd`/locale:/usr/lib/locale". So we are sure that we really have the user set locales installed, before we try to make use of them
I merged gcc-4.1.0_beta20051202 just fine with de_DE.utf8 locale. Is there anything related to this issue done in that version?
(In reply to comment #8) > I merged gcc-4.1.0_beta20051202 just fine with de_DE.utf8 locale. > Is there anything related to this issue done in that version? Not by me. Upstream? Possibly :)
sounds fixed then :)
