| View previous topic :: View next topic |
| Author |
Message |
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
 Posted: Tue Apr 05, 2011 11:32 am Post subject: |
 |
|
I switched to gcc-4.6.0 and lto are far more usable than on previous version.
Anyway, there still are few packages that do not compile with lto.
The error code are very similar between them:
| Code: | /usr/include/bits/fcntl2.h: In function 'os_file_create_simple_no_error_handling':
/usr/include/bits/fcntl2.h:51:24: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/x86_64-pc-linux-gnu-g++ returned 1 exit status
|
The profile is hardened/linux/amd64/no-multilib
@wolf550e:
In make.conf I have:
| Code: | GRAPHITE="-floop-block -floop-interchange -floop-strip-mine"
CFLAGS="-O2 -pipe -march=native -mtune=native -ftree-vectorize -flto -w ${GRAPHITE}"
CXXFLAGS="${CFLAGS} -fpermissive"
LDFLAGS="-Wl,-O1,--sort-common,--warn-once,--hash-style=gnu,--as-needed,-flto" |
I probably miss understand you. If I set CC or CXX variable in make.conf many packages fail to compile.
In my case, is lto working properly ? Is -O2 flag respected ? If not, what should I do ?
Thank you!
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
 |
duncanphilipnorman
n00b
Joined: 05 Apr 2011
Posts: 13
|
| Posted: Tue Apr 05, 2011 8:42 pm Post subject: |
|
|
| ecko wrote: | I just tried the gcc 4.6.0 ebuild now in portage, on amd64.
...snip...
Any idea ? Thanks,
ecko. |
I have the same error with the gcc-4.6.0.ebuild in portage, but I'm compiling with gcc-4.4.5. Dies when comparing stage2 and stage3.
Here's the top line of emerge --info:
| Code: |
Portage 2.2.0_alpha28 (default/linux/amd64/10.0/desktop/kde, gcc-4.4.5, glibc-2.11.3-r0, 2.6.36-gentoo-r8-vennsa-dev-em64t x86_64)
|
Here are some relevant flags:
| Code: |
CFLAGS="-O2 -march=nocona -pipe"
CBUILD="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
USE="doc fortran gtk mudflap (multilib) nls nptl openmp"
|
I tried adding "-frandom-seed=1" to CFLAGS and setting BOOT_CFLAGS, but it didn't make a difference.
Here's a bit more from the build.log in case that helps someone.
| Code: |
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/lto/lto.o differs
gcc/c-typeck.o differs
gcc/build/gengtype-lex.o differs
gcc/ira-build.o differs
gcc/cgraph.o differs
gcc/lto-streamer-out.o differs
gcc/fortran/trans.o differs
gcc/cfghooks.o differs
gcc/opts.o differs
gcc/omega.o differs
gcc/cfgloopmanip.o differs
gcc/except.o differs
gcc/var-tracking.o differs
gcc/plugin.o differs
libiberty/pic/cplus-dem.o differs
libiberty/cplus-dem.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.6.0/work/build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.6.0/work/build'
make: *** [bootstrap-lean] Error 2
|
What's the policy on filing bugs at this point?
Edit: I just retried with -O1 instead of -O2 (in case new additions to -O2 broke this), but the build still fails in the same place.
Last edited by duncanphilipnorman on Tue Apr 05, 2011 9:33 pm; edited 1 time in total |
|
| Back to top |
|
|
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
| Posted: Tue Apr 05, 2011 9:30 pm Post subject: |
|
|
| costel78 wrote: |
@wolf550e:
In make.conf I have:
| Code: | GRAPHITE="-floop-block -floop-interchange -floop-strip-mine"
CFLAGS="-O2 -pipe -march=native -mtune=native -ftree-vectorize -flto -w ${GRAPHITE}"
CXXFLAGS="${CFLAGS} -fpermissive"
LDFLAGS="-Wl,-O1,--sort-common,--warn-once,--hash-style=gnu,--as-needed,-flto" |
I probably miss understand you. If I set CC or CXX variable in make.conf many packages fail to compile.
In my case, is lto working properly ? Is -O2 flag respected ? If not, what should I do ?
Thank you! |
No.
| Code: | #include <stdio.h>
#include <inttypes.h>
int main () {
double d = 1;
int64_t i;
for (i = 0; i < 0xfffffff; i++) {
switch (i % 4) {
case 0:
d += i;
break;
case 1:
d -= i;
break;
case 2:
d /= i;
break;
default:
d *= i;
}
}
printf ("%lf\n", d);
}
|
Tests:
| Code: | % rm test test.o && gcc -c test.c -o test.o && gcc test.o -o test && time ./test
-0.333333
./test 1.54s user 0.00s system 99% cpu 1.539 total
% rm test test.o && gcc -flto -O2 -pipe -ggdb -march=native -msahf -mcx16 -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftree-loop-im -fsched-pressure -fsched-spec-load -c test.c -o test.o && gcc -flto test.o -o test && time ./test
-0.333333
./test 1.55s user 0.00s system 99% cpu 1.552 total
% rm test test.o && gcc -O2 -pipe -ggdb -march=native -msahf -mcx16 -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftree-loop-im -fsched-pressure -fsched-spec-load -c test.c -o test.o && gcc test.o -o test && time ./test
-0.333333
./test 0.83s user 0.00s system 99% cpu 0.829 total
% rm test test.o && gcc -flto -O2 -pipe -ggdb -march=native -msahf -mcx16 -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftree-loop-im -fsched-pressure -fsched-spec-load -c test.c -o test.o && gcc -flto -O2 -pipe -ggdb -march=native -msahf -mcx16 -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -ftree-loop-im -fsched-pressure -fsched-spec-load test.o -o test && time ./test
-0.333333
./test 0.82s user 0.00s system 99% cpu 0.823 total
|
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
|
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
| Posted: Tue Apr 05, 2011 9:59 pm Post subject: |
|
|
@Uzytkownik
Ok, I think I understand now. For now, libtool do not pass all arguments during linking and the presence of optimization flags during link phase does matter. It will need future work to full support lto. It also seems that lto speed improvement it's not significant. I'll disable it for a while.
Thank you!
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
| Posted: Tue Apr 05, 2011 10:10 pm Post subject: |
|
|
| costel78 wrote: | @Uzytkownik
Ok, I think I understand now. For now, libtool do not pass all arguments during linking and the presence of optimization flags during link phase does matter. It will need future work to full support lto. It also seems that lto speed improvement it's not significant. I'll disable it for a while.
Thank you! |
The last statement about speed improvement might not be true. Please note that test was trivial and does not correspond to any real-life program (I wrote it just to have 2 different numbers - with and without optimalisation). Additionally it contained one file (glibc was not compilled with LTO) therefore LTO couldn't make any difference (optimizing one file does not differ from optimizing the same file).
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
|
bingyuan
n00b
Joined: 20 Feb 2011
Posts: 13
|
| Posted: Wed Apr 06, 2011 4:23 am Post subject: |
|
|
| Code: | CFLAGS="${CFLAGS} -flto -fwhole-program"
LDFLAGS="${LDFLAGS} -Wl,-flto" |
results in HUGE binaries, and some pkgs fail to be built, so I remove those lto related flags |
|
| Back to top |
|
|
ecko
Tux's lil' helper
Joined: 04 Jul 2010
Posts: 102
|
| Posted: Wed Apr 06, 2011 7:59 am Post subject: gcc bug |
|
|
I found the gcc devs are aware there is a bootstrap problem and corrected the bug few days ago. Are the patches going to enter portage ? gcc trunk is broken, that's not fun.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 |
|
| Back to top |
|
|
duncanphilipnorman
n00b
Joined: 05 Apr 2011
Posts: 13
|
| Posted: Wed Apr 06, 2011 2:23 pm Post subject: Re: gcc bug |
|
|
I think that bootstrap failure is unrelated to 4.6.0. They tracked it down to a trunk commit from April 1st, while 4.6.0 was released at the end of March. Regardless, I tried applying the patches they mention in that PR, but they didn't apply because they modify the use of a static variable that doesn't yet exist. |
|
| Back to top |
|
|
costel78
Guru
Joined: 20 Apr 2007
Posts: 402
|
| Posted: Wed Apr 06, 2011 7:39 pm Post subject: |
|
|
Bootstrap error it's not related to gcc, at least not to gcc-4.6.0
I tried to emerge gcc-4.6.0 using stage3 which come with gcc-4.4.2. Of course, compile of gcc-4.6.0 failed.
Then I updated glibc binutils and libtool and compiled gcc-4.5.2
Using latest glibc binutils and libtool and gcc-4.5.2 I was able to compile gcc-4.6.0
Maybe there are some steps that can be removed, but seems that stable tree of gentoo is to old for gcc-4.6.0
| Code: | emerge -pv portage linux-headers gcc-config mpfr binutils libtool dev-libs/mpc ppl cloog-ppl glibc gcc
These are the packages that would be merged, in order:
Calculating dependencies ... done!
[ebuild R ] sys-devel/gcc-config-1.4.1 0 kB
[ebuild R ] sys-kernel/linux-headers-2.6.38 0 kB
[ebuild R ] dev-libs/mpfr-3.0.1 0 kB
[ebuild R ] dev-libs/ppl-0.11.2 USE="pch -doc -lpsol -test -watchdog" 0 kB
[ebuild R ] dev-libs/mpc-0.9 0 kB
[ebuild R *] sys-devel/binutils-2.21.51.0.7 USE="nls -multislot -multitarget -test -vanilla" 0 kB
[ebuild R ] sys-devel/libtool-2.4-r1 USE="-vanilla" 0 kB
[ebuild R ] dev-libs/cloog-ppl-0.15.10 USE="-static-libs" 0 kB
[ebuild R #] sys-devel/gcc-4.6.0 USE="graphite gtk mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -go (-hardened) (-libffi) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" 0 kB
[ebuild R ] sys-libs/glibc-2.13-r2 USE="(multilib) nls -debug -gd -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 0 kB
[ebuild R *] sys-apps/portage-2.2.0_alpha29 USE="(ipc) -build -doc -epydoc -python2 -python3 (-selinux)" LINGUAS="-pl" 0 kB
Total: 11 packages (11 reinstalls), Size of downloads: 0 kB
|
_________________
Sorry for my English. I'm still learning this language. |
|
| Back to top |
|
|
duncanphilipnorman
n00b
Joined: 05 Apr 2011
Posts: 13
|
| Posted: Wed Apr 06, 2011 7:47 pm Post subject: |
|
|
| costel78 wrote: | Bootstrap error it's not related to gcc, at least not to gcc-4.6.0
I tried to emerge gcc-4.6.0 using stage3 which come with gcc-4.4.2. Of course, compile of gcc-4.6.0 failed.
Then I updated glibc binutils and libtool and compiled gcc-4.5.2
Using latest glibc binutils and libtool and gcc-4.5.2 I was able to compile gcc-4.6.0
Maybe there are some steps that can be removed, but seems that stable tree of gentoo is to old for gcc-4.6.0
|
Thanks for the hint... maybe I'll try updating binutils or libtool (hopefully that does the trick). Unfortunately, I don't want to update past the stable glibc. I'm using gcc-4.6.0 for development; I don't want to screw with my toolchain too much.
Edit: tried with unstable binutils and libtools, and it still didn't work. I may try the "**" binutils tomorrow. |
|
| Back to top |
|
|
cruzki123
Apprentice
Joined: 16 May 2008
Posts: 262
|
| Posted: Wed Apr 06, 2011 10:31 pm Post subject: |
|
|
| duncanphilipnorman wrote: | | costel78 wrote: | Bootstrap error it's not related to gcc, at least not to gcc-4.6.0
I tried to emerge gcc-4.6.0 using stage3 which come with gcc-4.4.2. Of course, compile of gcc-4.6.0 failed.
Then I updated glibc binutils and libtool and compiled gcc-4.5.2
Using latest glibc binutils and libtool and gcc-4.5.2 I was able to compile gcc-4.6.0
Maybe there are some steps that can be removed, but seems that stable tree of gentoo is to old for gcc-4.6.0
|
Thanks for the hint... maybe I'll try updating binutils or libtool (hopefully that does the trick). Unfortunately, I don't want to update past the stable glibc. I'm using gcc-4.6.0 for development; I don't want to screw with my toolchain too much.
Edit: tried with unstable binutils and libtools, and it still didn't work. I may try the "**" binutils tomorrow. |
Have you tried glibc in ~amd64? I am not ussing ** and I was able to compile gcc-4.6. |
|
| Back to top |
|
|
justXi
Tux's lil' helper
Joined: 01 Aug 2007
Posts: 85
|
| Posted: Thu Apr 07, 2011 7:51 am Post subject: |
|
|
Hi,
I emerged gcc-4.5.2 and glibc-2.13-r2 and now I am able to emerge gcc-4.6. |
|
| Back to top |
|
|
ecko
Tux's lil' helper
Joined: 04 Jul 2010
Posts: 102
|
| Posted: Thu Apr 07, 2011 9:09 am Post subject: |
|
|
| costel78 wrote: | | seems that stable tree of gentoo is to old for gcc-4.6.0 |
Now using same parameters as costel78, and gcc-4.6 it builds. Thank to all those who made suggestions!
With USE="go", it says:
| Quote: |
* QA Notice: The following files contain writable and executable sections
* Files with such sections will not work properly (or at all!) on some
* architectures/operating systems. A bug should be filed at
* https://bugs.gentoo.org/ to make sure the issue is fixed.
* For more information, see http://hardened.gentoo.org/gnu-stack.xml
* Please include the following list of files in your report:
* Note: Bugs should be filed for the respective maintainers
* of the package in question and not hardened@g.o.
* RWX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/32/libgo.so.0.0.0
* RWX --- --- usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/libgo.so.0.0.0
|
(I am NOT using hardened) So when building a hello world in go, it compiles but does not link.
| Code: |
package main ; import "fmt" ; func main() { mt.Printf("hello, world\n") }
|
| Quote: |
$ gcc test.go
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/tmp/ccoE3nck.o: In function `main.main':
test.go:(.text+0x64): undefined reference to `libgo_fmt.fmt.Printf'
/tmp/ccoE3nck.o: In function `__go_init_main':
test.go:(.text+0x8c): undefined reference to `libgo_math.math..import'
test.go:(.text+0x91): undefined reference to `libgo_runtime.runtime..import'
test.go:(.text+0x96): undefined reference to `libgo_unicode.unicode..import'
test.go:(.text+0x9b): undefined reference to `libgo_utf8.utf8..import'
test.go:(.text+0xa0): undefined reference to `libgo_syscalls.syscall..import'
test.go:(.text+0xa5): undefined reference to `libgo_os.os..import'
test.go:(.text+0xaa): undefined reference to `libgo_io.io..import'
test.go:(.text+0xaf): undefined reference to `libgo_strconv.strconv..import'
test.go:(.text+0xb4): undefined reference to `libgo_reflect.reflect..import'
test.go:(.text+0xb9): undefined reference to `libgo_fmt.fmt..import'
collect2: ld returned 1 exit status
|
***
EDIT: One uses gccgo, it just works. |
|
| Back to top |
|
|
duncanphilipnorman
n00b
Joined: 05 Apr 2011
Posts: 13
|
| Posted: Thu Apr 07, 2011 2:27 pm Post subject: |
|
|
| cruzki123 wrote: |
Have you tried glibc in ~amd64? I am not ussing ** and I was able to compile gcc-4.6. |
I'm not so comfortable with ~amd64 for glibc, since it's impossible (or at least inadvisable) to downgrade. I just did a search for glibc-2.13 and I can't find any info on when it'll go stable, if ever (I figure most issues have been fixed by r2, but I'm still wary). |
|
| Back to top |
|
|
Ormaaj
Guru
Joined: 28 Jan 2008
Posts: 319
|
| Posted: Thu Apr 07, 2011 9:24 pm Post subject: |
|
|
It looks like at least the live ebuild attempts to delete the lib which afaict lives entirely under:
| Quote: | | \! -path 'third_party/tcmalloc/*' \ |
However dev-util/google-perftools isn't actually made a dependency of chromium so I'm not really sure what's going on here. |
|
| Back to top |
|
|
wrc1944
Advocate
Joined: 15 Aug 2002
Posts: 3435
Location: Gainesville, Florida
|
| Posted: Thu Apr 07, 2011 9:29 pm Post subject: |
|
|
What's the bottom line for those running ~x86 systems, and have successfully compiled gcc-4.6.0 with no problems?
What's the current thinking on recommended flags after switching from 4.5.2? Enable graphite and lto, or just graphite and the -floop-block -floop-interchange -floop-strip-mine flags are no longer required?
Forget lto for the present, and whether -O2 or -O1 is best?
There's so much contradictory discussion (and has been for months) it's hard to really understand what's the best procedure. One would assume that since the devs have unmasked 4.6.0 for ~ARCH, they must have a basic recommendation for what to put in make.conf regarding flags. 
Do we need to rebuild the toolchain, and then rebuild world after making the correct adjustments.?
More feedback and/or a little documentation summary from devs would sure be helpful.
Man:gcc is good, but I for one would like to know what the consensus of the Gentoo gcc devs is regarding the various new make.conf options.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11 |
|
| Back to top |
|
|
Ormaaj
Guru
Joined: 28 Jan 2008
Posts: 319
|
| Posted: Fri Apr 08, 2011 12:32 am Post subject: |
|
|
@wrc1944 It's pretty usual for an n.n+1.0 release. Most things compile fine, and a few don't due to the usual assortment of depreciated things. most packages should be fine by *.1. I always recompile everything but nothing should break if you don't.
As far as flags nothing changes. lto is basically worthless because it can't really be used for reasons mentioned in this thread without hacks that probably won't work globally. The graphite flags are still required if you want to use it. -O2 is probably always better than -O1. -O3 is probably better on average than -O2 on newer processors. fwiw, my flags: http://ormaaj.org/pages/gentoo/index.xhtml
Though the same corner case considerations for the various unsafe FP optimizations apply. They added -Ofast since there are a lot of packages out there which could be taking advantages of them that don't. Gentoo doesn't work around runtime problems i'm guessing because it would be impossible to know when new versions of packages introduce problems when upstream isn't taking them into account, so they just never use them with a few exceptions where they are known to work and supported by upstream (though not always... i'm sure they don't look in every makefile to see if ffast-math would be applied). |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Fri Apr 08, 2011 7:36 am Post subject: |
|
|
If I'd upgrade to GCC 4.6, what packages break? Any accurate list by now at least regarding @system?
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
| Posted: Fri Apr 08, 2011 8:15 am Post subject: |
|
|
I have rebuild @world. I had a 10 failers although not all are gcc fault:
- dev-db/libdbi: Unrelated Gentoo bug
- dev-libs/libusb: Unrelated Gentoo bug
- dev-util/systemtap: -Werror is set and new warning appeared
- sys-fs/lvm2: Problems with static libraries (unrelated?)
- x11-libs/cairo: Problems with static libraries (unrelated?)
- dev-cpp/eigen: ICE
- dev-db/libdbi-drivers: Unrelated Gentoo bug
- media-gfx/splashutils: configure: error: C compiler cannot create executables
- media-libs/gst-plugins-bad: Problem with GNOME 3
- net-libs/webkit-gtk x 2: configure: error: C compiler cannot create executables
- dev-java/icedtea-web: cannot create regular file `/var/tmp/paludis/dev-java-icedtea-web-1.0.2-r7/image//usr/lib64/icedtea7/jre/lib': No such file or directory (unrelated?)
- media-libs/libdc1394 x 2: dc1394_vloopback.c:71:28: fatal error: linux/videodev.h: No such file or directory (unrelated?)
- media-gfx/blender: [ 42%] Built target bf_gpu
make: *** [all] Error 2 (???)
- www-client/epiphany-extensions: Unrelated version mismatch
- dev-util/monodevelop-boo: Unrelated
The error in configure:
| Code: | configure:4017: checking whether the C compiler works
configure:4039: x86_64-pc-linux-gnu-gcc -O2 -pipe -ggdb -march=native -msahf -mc
x16 -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -floop-interchange -floop-
strip-mine -floop-block -ftree-loop-distribution -ftree-loop-im -fsched-pressure
-fsched-spec-load -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=both -Wl,--sort-com
mon -Wl,-fwhopr -Wl,--no-keep-memory conftest.c >&5
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld: -
f may not be used without -shared
collect2: ld returned 1 exit status
|
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
|
ToeiRei
Veteran
Joined: 03 Jan 2005
Posts: 1191
Location: Austria
|
| Posted: Fri Apr 08, 2011 9:10 am Post subject: |
|
|
I did run into this one while compiling cpio:
| Code: |
CC makepath.o
CC userspec.o
CCLD cpio
../gnu/libgnu.a(progname.o):(.bss+0x0): multiple definition of `program_name'
global.o:(.bss+0x10): first defined here
collect2: ld returned 1 exit status
make[2]: *** [cpio] Error 1
make[2]: Leaving directory `/var/tmp/portage/app-arch/cpio-2.11/work/cpio-2.11/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/app-arch/cpio-2.11/work/cpio-2.11'
make: *** [all] Error 2
emake failed
|
Flags as follow (ldflags commented out for trying if that's the problem)
| Code: |
CHOST="x86_64-pc-linux-gnu"
GRAPHITE="-floop-block -floop-interchange -floop-strip-mine"
CFLAGS="-march=native -O2 -pipe -ftree-vectorize -fno-common -w ${GRAPHITE}"
CXXFLAGS="${CFLAGS} -fpermissive"
# LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,now -Wl,--sort-common"
|
_________________
Please stand by - The mailer daemon is busy burning your messages in hell... |
|
| Back to top |
|
|
billydv
l33t
Joined: 22 Dec 2006
Posts: 911
Location: Mount Vernon, NY
|
| Posted: Fri Apr 08, 2011 11:24 am Post subject: |
|
|
I am really wanting to upgrade because of the new built in native support for I7 but seeing the packages that won't compile and looking at the amount of open bugs on gentoo bugzilla makes me glad that I'm waiting!!
_________________
Billy DeVincentis |
|
| Back to top |
|
|
cruzki123
Apprentice
Joined: 16 May 2008
Posts: 262
|
| Posted: Fri Apr 08, 2011 12:23 pm Post subject: |
|
|
| Uzytkownik wrote: | I have rebuild @world. I had a 10 failers although not all are gcc fault:
|
This is a little odd. eigen is a headers library, so there is no need to compile anything. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Apr 09, 2011 5:14 pm Post subject: |
|
|
I am now getting desparate, since I never succeeded to compile gcc4-6: I always get bootstrap failure at stage comparison.
I have installed gcc-4.5.2 libtool-2.2.10 binutils-2.20.1-r1 glibc-2.11.3 and also tried upgrading to libtool-2.4-r1 and/or binutils-2.21 (all four combinations) with safe CFLAGS (-march=native -O2 -pipe), no LDFLAGS on intel core2 (on amd64 system).
I also stripped down USE flags to a bare minimum (trying also various combinations).
Did anybody of you succeed with these libs, i.e. without upgrading to glibc-2.13-r2 or is that really an unavoidable upgrade for the compilation of gcc-4.6? |
|
| Back to top |
|
|
duncanphilipnorman
n00b
Joined: 05 Apr 2011
Posts: 13
|
| Posted: Sat Apr 09, 2011 6:12 pm Post subject: |
|
|
| mv wrote: | I am now getting desparate, since I never succeeded to compile gcc4-6: I always get bootstrap failure at stage comparison.
I have installed gcc-4.5.2 libtool-2.2.10 binutils-2.20.1-r1 glibc-2.11.3 and also tried upgrading to libtool-2.4-r1 and/or binutils-2.21 (all four combinations) with safe CFLAGS (-march=native -O2 -pipe), no LDFLAGS on intel core2 (on amd64 system).
I also stripped down USE flags to a bare minimum (trying also various combinations).
Did anybody of you succeed with these libs, i.e. without upgrading to glibc-2.13-r2 or is that really an unavoidable upgrade for the compilation of gcc-4.6? |
I tried the same stuff (although I didn't switch to gcc-4.5.2 and I used -march=nocona), also on intel core2 amd64, and it didn't work. I think you need glibc-2.13-r2... which, given all the problems people are having with it, I'm not willing to upgrade to yet.
I'm actually quite surprised that I can't install gcc-4.6.0 as a secondary compiler without the latest glibc... was there an important bug in 2.11.3 that gcc-4.6.0 exposes, or does gcc rely on bleeding edge glibc features? |
|
| Back to top |
|
|
billydv
l33t
Joined: 22 Dec 2006
Posts: 911
Location: Mount Vernon, NY
|
| Posted: Sat Apr 09, 2011 7:40 pm Post subject: |
|
|
Okay, I gave it a try but I am now reverting my system back. Although most packages are compilable, I could not get my sytem to boot again. First, grub spit out an error and would not boot my system. After starting with a live cd and trying to reinstall grub, it failed complaining of mismatched versions. After recompiling it with 4.5.2 and reinstalling grub, I booted. Upon actually starting my system kde wouldn't start. That was enough for me. gcc-4.6.0 is still too problematic!!!
_________________
Billy DeVincentis |
|
| Back to top |
|
|
|
Unsupported Software
