Summary: | libgfortran in sys-devel/gcc-4.3.1 failed: emake failed with profiledbootstrap | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hongjiu Zhang <voidprayer> |
Component: | [OLD] GCC Porting | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | lonicerae |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log.tar.bz2
build.log.bz2 wanted selected_int_kind.inc |
Description
Hongjiu Zhang
2008-06-14 14:07:45 UTC
Created attachment 156749 [details]
build.log.tar.bz2
Created attachment 157313 [details]
build.log.bz2
bzip2 good, tar bad :)
same problem google says this error comes up when the generation step failed and so the resulting file is corrupt post the "selected_int_kind.inc" file as an attachment, and try running this command to see if you get any errors: /bin/sh /var/tmp/portage/sys-devel/gcc-4.3.1/work/gcc-4.3.1/libgfortran/mk-sik-inc.sh '/var/tmp/portage/sys-devel/gcc-4.3.1/work/build/./gcc/gfortran -B/var/t mp/portage/sys-devel/gcc-4.3.1/work/build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -g -O2' > selected_int_kind.inc I could not reproduce this bug. I am changing resolution to INVALID. Thanks. Bug reproduced. Now in gcc-4.3.3-r2. Following SpanKY's direction. Created attachment 192461 [details]
wanted selected_int_kind.inc
Completely same emerge --info and get the same error in the build.log (s/gcc-4.3.1/gcc-4.3.3-r2) I can't reproduce this, and it seems you have problems reproducing it as well. I'd recommend running memtest to check your RAM. *** Bug 302440 has been marked as a duplicate of this bug. *** May I ask a stupid question? Can this be caused by some source files not written in UTF-8 locale? If it is so, how can I write a script to check which locale is the file written in? Maybe I can iconv it to UTF-8 and then build after that? In fact, this is not the only package affected by this problem. Formerly I reported a bug about dev-lang/ghc (#292217). Since my knowledge is still limited to "locale is the way of storing text characters in a file", I can only guess in this way. Thanks for any response. usually it isnt encoding issues but collation issues, but anything is possible. typically the files only contain ASCII sequences though and the 7bit encoding should be portable in all unicode sequences by design. the problem here is that people cant seem to reproduce it reliably. it works fine on my system when using a chinese unicode locale for example. |