i don't want to chroot to another profile just to use a 32bit double firefox.... i'm using 64bit firefox with wrapper and 32bit apps and it runs quite well. i don't want to use a double thing. there are lesser apps that go only on 32bit so i hope that i won't need the multilib profile for long.... anyway the find would remove me some crosscompilers, fact that i don't want.... and now i don't what the heck has happened since i can't compile anymore.... it gives me errors on gcc compiler.... i'll try reemerging it and see if i can do it.... i can't do it what should i do?!
2007/10/17, Duncan <[EMAIL PROTECTED]>: > > Beso <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted > below, on Wed, 17 Oct 2007 10:12:43 +0200: > > > when i try to upgrade to glibc-2.6.1 from gentoo stable repo i get this > > error: > > > > ../include/sys/socket.h:21: warning: 'stdcall' attribute ignored > >> make[2]: *** [/var/tmp/paludis/sys-libs/glibc-2.6.1 > >> /work/build-x86-x86_64-pc-linux-gnu-nptl/tcb-offsets.h] Error 1 > >> make[2]: *** Waiting for unfinished jobs.... > >> ../sysdeps/generic/initfini.c:1: error: CPU you selected does not > >> support x86-64 instruction set ../sysdeps/generic/initfini.c:1: error: > >> CPU you selected does not support x86-64 instruction set > > Did you ever have the eselect-compiler module, aka gcc-config-2.0, > installed? Presumably you've removed it now if you did, but the unmerge > left some files behind that triggered frustrating errors such as this at > times. Let's see if I can find the bug, which has a command that can be > run to trace down and remove these files (be sure to read my comment on > the bug, as the initial form of the command as posted caused problems for > a number of people, removing too much stuff due to bad quoting)... > > OK, here we are: http://bugs.gentoo.org/show_bug.cgi?id=133209 > > Pay particular attention to comments 25,35,39. > > That may or may not be your problem, but if it is, it's a fairly easy fix > for what can be an otherwise extremely frustrating problem. > > FWIW, a few months ago I finally decided to switch to the 64-bit only no- > multilib profile here, since I won't merge binary-only stuff here anyway > out of principle, and that's mainly why one would need 32-bit > compatibility as virtually any commonly used freedomware is long since > ported. Less problems, and compiling gcc and glibc take MUCH less time > now, since only the 64-bit stuff has to be compiled, not the 32-bit stuff > as well. If I did do 32-bit, I'd now go the 32-bit chroot route, > installing from a full 32-bit stage-3 thus keeping 32-bit and 64-bit > separate, instead of fooling with the multilib stuff. Less problems that > way, and when there /is/ a problem, it's far more likely to be limited to > one bitness or the other, not some weird combination of both. Those dual- > bitness problems aren't common, but they are sure frustrating to try to > figure out and solve, so eliminating that entire class of problem was at > least for me a good choice; one I'd have made much earlier if I had it to > do over again. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > -- > [EMAIL PROTECTED] mailing list > > -- dott. ing. beso
