[gentoo-amd64] System freezes when dragging programs
Hello list, I have the weird problem that when I want to move a program around the screen the system kind of freezes. The only thing that works (if you can call it working) is my mouse which remains in the move-things-around-state and it can move around the screen but that's it, no clicking no dragging. The *lock key stop working and gkrellm graphs stop. Has anybody seen this before? And if you did, did you solve it? emerge --info : www.xs4all.nl/~mtonko/emerge.info kernel config : www.xs4all.nl/~mtonko/kernel-config -- Regards, Tonko Mulder
[gentoo-amd64] Can not compile gcc
Hello all, I have updated my use flags.
USE=X aac aiglx alsa aoss asf bzip2 cairo dbus dvd emerald fam firefox gif
glitz gnome gstreamer gtk hal java jpeg mad mp3 mp4 new-login nptl
nptlonly nsplugin opengl pdf png samba spell sqlite svg symlink threads
tiff truetype unicode x264 xcomposite xinerama xml xorg xscreensaver xv
xvid -arts -eds -esd -fortran -ipv6 -kde -qt3 -qt4
And then tried :
emerge -vuD --newuse world
It failed with the error:
=
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-target-libstdc++-v3] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make: *** [profiledbootstrap] Error 2
*
* ERROR: sys-devel/gcc-4.1.2 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 4646: Called toolchain_src_compile
* environment, line 5164: Called gcc_src_compile
* environment, line 2972: Called gcc_do_make
* environment, line 2795: Called die
* The specific snippet of code:
* emake LDFLAGS=${LDFLAGS} STAGE1_CFLAGS=${STAGE1_CFLAGS}
LIBPATH=${LIBPATH} BOOT_CFLAGS=${BOOT_CFLAGS} ${GCC_MAKE_TARGET} || die
emake failed with ${GCC_MAKE_TARGET};
* The die message:
* emake failed with profiledbootstrap
*
* If you need support, post the topmost build error, and the call stack if
relevant.
* A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/environment'.
*
* Messages for package app-editors/nano-2.1.5:
* More helpful info about nano, visit the GDP page:
* http://www.gentoo.org/doc/en/nano-basics-guide.xml
* Messages for package sys-devel/gcc-4.1.2:
*
* ERROR: sys-devel/gcc-4.1.2 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 4646: Called toolchain_src_compile
* environment, line 5164: Called gcc_src_compile
* environment, line 2972: Called gcc_do_make
* environment, line 2795: Called die
* The specific snippet of code:
* emake LDFLAGS=${LDFLAGS} STAGE1_CFLAGS=${STAGE1_CFLAGS}
LIBPATH=${LIBPATH} BOOT_CFLAGS=${BOOT_CFLAGS} ${GCC_MAKE_TARGET} || die
emake failed with ${GCC_MAKE_TARGET};
* The die message:
* emake failed with profiledbootstrap
*
* If you need support, post the topmost build error, and the call stack if
relevant.
* A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/environment'.
*
* Regenerating GNU info directory index...
* Processed 132 info files.
* IMPORTANT: 3 config files in '/etc' need updating.
* See the CONFIGURATION FILES section of the emerge
* man page to learn how to update config files.
=
The log file:
checking for x86_64-pc-linux-gnu-gcc...
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-target-libstdc++-v3] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make: *** [profiledbootstrap] Error 2
*
* ERROR: sys-devel/gcc-4.1.2 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 4646: Called toolchain_src_compile
* environment, line 5164: Called gcc_src_compile
* environment, line 2972: Called gcc_do_make
* environment, line 2795: Called die
* The specific snippet of code:
* emake LDFLAGS=${LDFLAGS} STAGE1_CFLAGS=${STAGE1_CFLAGS}
LIBPATH=${LIBPATH} BOOT_CFLAGS=${BOOT_CFLAGS} ${GCC_MAKE_TARGET} || die
emake failed with ${GCC_MAKE_TARGET};
* The die message:
* emake failed with profiledbootstrap
*
* If you need support, post the topmost build error, and the call stack if
relevant.
* A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
* The ebuild environment file is located at
Re: [gentoo-amd64] Can not compile gcc
Mansour Al Akeel [EMAIL PROTECTED] skribis: Any idea ? If you use ccache, try emptying it.
Re: [gentoo-amd64] Can not compile gcc
Barry Schwartz schrieb: Mansour Al Akeel [EMAIL PROTECTED] skribis: Any idea ? If you use ccache, try emptying it. I think there is something else wrong, because it fails in the configure phase. Send us an emerge --info output, please. signature.asc Description: OpenPGP digital signature
Re: [gentoo-amd64] Can not compile gcc
Justin wrote: Barry Schwartz schrieb: Mansour Al Akeel [EMAIL PROTECTED] skribis: Any idea ? If you use ccache, try emptying it. I think there is something else wrong, because it fails in the configure phase. Send us an emerge --info output, please. I'm not an expert, but it seems that it was trying to compile 64-bit test code with -m32 flag: The log file: checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 Perhaps he should check his make.conf for CHOST and CLAGS ?
Re: [gentoo-amd64] Can not compile gcc
Branko Badrljica schrieb: Justin wrote: Barry Schwartz schrieb: Mansour Al Akeel [EMAIL PROTECTED] skribis: Any idea ? If you use ccache, try emptying it. I think there is something else wrong, because it fails in the configure phase. Send us an emerge --info output, please. I'm not an expert, but it seems that it was trying to compile 64-bit test code with -m32 flag: The log file: checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 Perhaps he should check his make.conf for CHOST and CLAGS ? Sharp eyed guy!! signature.asc Description: OpenPGP digital signature
Re: [gentoo-amd64] Can not compile gcc
I have already initiated the build again after I modified the USE flags to
the defaults that came with the installation cd. Here's the dfaults:
==
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /etc/make.conf.example for a more detailed example.
CFLAGS=-O2 -pipe
CXXFLAGS=-O2 -pipe
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before
changing.
CHOST=x86_64-pc-linux-gnu
# These are the USE flags that were used in addition to what is provided by
the
# profile used for building.
USE=mmx sse sse2
=
I am still waiting to see the results. When the error occured I was using
the following make.conf:
==
CFLAGS=-march=athlon64 -O2 -pipe
CXXFLAGS=${CFLAGS}
CHOST=x86_64-pc-linux-gnu
MAKEOPT=-j2
FEATURES=ccache
USE=X aac aiglx alsa aoss asf bzip2 cairo dbus dvd emerald fam firefox gif
glitz gnome gstreamer gtk hal java jpeg mad mp3 mp4 new-login nptl
nptlonly nsplugin opengl pdf png samba spell sqlite svg symlink threads
tiff truetype unicode x264 xcomposite xinerama xml xorg xscreensaver xv
xvid -arts -eds -esd -fortran -ipv6 -kde -qt3 -qt4
VIDEO_CARDS=NVIDIA
===
I should have kept a back up of the build.log but if anyone needs it, I can
do emerge again, and send you the file, as I have this strong feeling that
the build I am doing now will fail as well.
Thank you all.
On Fri, Nov 14, 2008 at 2:40 PM, Justin [EMAIL PROTECTED] wrote:
Branko Badrljica schrieb:
Justin wrote:
Barry Schwartz schrieb:
Mansour Al Akeel [EMAIL PROTECTED] skribis:
Any idea ?
If you use ccache, try emptying it.
I think there is something else wrong, because it fails in the configure
phase.
Send us an emerge --info output, please.
I'm not an expert, but it seems that it was trying to compile 64-bit
test code with -m32 flag:
The log file:
checking for x86_64-pc-linux-gnu-gcc...
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/
-isystem /usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include -m32
Perhaps he should check his make.conf for CHOST and CLAGS ?
Sharp eyed guy!!
[gentoo-amd64] Re: Can not compile gcc
Mansour Al Akeel [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 14 Nov 2008 14:02:19 -0400: checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 First, please kill the HTML. There's enough old fogies like me that don't like it, on most Linux related lists at least, that it's really not a good idea. We have a choice as to whether to reply or not, and some of the guys that have been around the longest and therefore tend to have the most wisdom to apply to a problem, may not reply to HTML posts at all -- or even see them in some cases, if they filter them out, as I do for regular mail. Do you really want to potentially kill the single reply that might have otherwise been the only one with a working fix? Anyway, back to your question. See that -m32? That's telling the new gcc it just built while bootstrapping itself and is there testing, to compile the test in 32-bit mode. It (I think) builds the 64-bit stuff first, and is then failing on the 32-bit stuff. IOW, it's an issue related to the 32-bit aspect of the compile for both 64-bit and 32-bit support, that you get when you are running a multilib profile. Personally, since I don't do the proprietaryware that's the biggest reason to do 32-bit compatibility in the first place, and all the freedomware I run has long since been 64-bit, I didn't have any reason to stay with multilib. And, since it gave me headaches like this every so often, and even when it was working, both gcc and glibc, which are both already fairly long merges, took effectively double the time to build because they were being built for both 64-bit and 32-bit, I had lots of reason NOT to stay with multilib. So I switched to the no-multilib profile and simplified my life with faster and more trouble-free gcc and glibc compiles, and have been VERY happy I did so. Of course if you're still held captive by some proprietaryware or other that's only available in 32-bit, that's not going to be an option for you. There are several possible triggers for this problem. The first one is a broken 32-bit sandbox. For that, try turning it off and remerging sandbox. If it works, you should then be able to remerge gcc without issue and remerge sandbox normally. FEATURES=-sandbox emerge sandbox If that doesn't work, one thing that has been a problem in the past but one would hope doesn't apply any more, is if you had eselect-compiler and gcc-config-2.0 merged at some point. If you did, there's a bug on it you should look at. If you didn't, this one doesn't apply. There are various other possibilities due to various broken configs and etc relating to the 32-bit side of the multilib toolchain. Often the simplest solution to these is to remerge a known working usually older gcc, hopefully overwriting whatever's wrong with your current setup, after which you can normally rebuild the newer gcc using the working old one, and be back on track. If you've been running FEATURES=buildpkg for some time, you may have several older versions of gcc in your binary package archive and can just remerge one of them, temporarily downgrading gcc to fix the problem, then use it to merge a current gcc. This of course is one of the benefits of running with that feature enabled. If you have NOT been running with FEATURES=buildpkg enabled, you have a choice. If you have another working gentoo/amd64 machine available, you can quickpkg it's gcc, copy it over and emerge -K it onto the affected machine. Otherwise you'll have to choose between trusting a version someone else may offer you and grabbing one off the latest gentoo/amd64 install stages. This would involve downloading a stage tarball, untarring it somewhere temporary, chrooting into it, doing a quickpkg of the gcc therein, then from outside the chroot, doing an emerge -K of the binpkg built by the quickpkg. When you get your system working correctly again (but before you go back to your system/world rebuild), you may wish to consider FEATURES=buildpkg. If you turn it on, you can then do your system/world rebuild and will have binpkgs of everything, available if you need them. After awhile, you'll have a couple older versions of most packages as well, in case you need to revert to an older one for some reason. It's a quite handy thing to have available, and can sure save a lot of needless recompiling at times, even if you /don't/ ever use it to get out of another hole like a busted gcc. Spacewise, a full FEATURES=buildpkg system and world set, with what I have merged here, runs about a gig, but you'll want at least 2 gigs available for binpkgs and preferably 4 gigs or so, so you don't have to clean out old
Re: [gentoo-amd64] Re: Can not compile gcc
First of all, I apologies for the HTML formatting. On my fedora, I use
Thunderbird, and have the emails sent in plain text automatically.
Since My system is being UPGRADED to gentoo, I am stuck with the web
interface, and totally forgot the plain text requirement.
Back again to my problem, I have modified my make.conf to this one:
===
CFLAGS=-march=athlon64 -O2 -pipe
CXXFLAGS=${CFLAGS}
CHOST=x86_64-pc-linux-gnu
MAKEOPT=-j2
#FEATURES=ccache
FEATURES=-sandbox emerge sandbox
USE=X aac aiglx alsa aoss asf bzip2 cairo dbus dvd emerald fam firefox gif
glitz gnome gstreamer gtk hal java jpeg mad mp3 mp4 new-login nptl
nptlonly nsplugin opengl pdf png samba spell sqlite svg symlink threads
tiff truetype unicode x264 xcomposite xinerama xml xorg xscreensaver xv
xvid -arts -eds -esd -fortran -ipv6 -kde -qt3 -qt4
VIDEO_CARDS=NVIDIA
===
And trying the emerge again. I will report the results. I am not stuck
with any 32 bit properiatory softwares, but you never know, I may need
it. I will keep the option of getting rid of the 32 bit as the last
option.
Thank you.
On Fri, Nov 14, 2008 at 3:30 PM, Duncan [EMAIL PROTECTED] wrote:
Mansour Al Akeel [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Fri, 14 Nov 2008 14:02:19 -0400:
checking for x86_64-pc-linux-gnu-gcc...
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include -m32
First, please kill the HTML. There's enough old fogies like me that
don't like it, on most Linux related lists at least, that it's really not
a good idea. We have a choice as to whether to reply or not, and some of
the guys that have been around the longest and therefore tend to have the
most wisdom to apply to a problem, may not reply to HTML posts at all --
or even see them in some cases, if they filter them out, as I do for
regular mail. Do you really want to potentially kill the single reply
that might have otherwise been the only one with a working fix?
Anyway, back to your question. See that -m32? That's telling the new
gcc it just built while bootstrapping itself and is there testing, to
compile the test in 32-bit mode. It (I think) builds the 64-bit stuff
first, and is then failing on the 32-bit stuff. IOW, it's an issue
related to the 32-bit aspect of the compile for both 64-bit and 32-bit
support, that you get when you are running a multilib profile.
Personally, since I don't do the proprietaryware that's the biggest
reason to do 32-bit compatibility in the first place, and all the
freedomware I run has long since been 64-bit, I didn't have any reason to
stay with multilib. And, since it gave me headaches like this every so
often, and even when it was working, both gcc and glibc, which are both
already fairly long merges, took effectively double the time to build
because they were being built for both 64-bit and 32-bit, I had lots of
reason NOT to stay with multilib.
So I switched to the no-multilib profile and simplified my life with
faster and more trouble-free gcc and glibc compiles, and have been VERY
happy I did so.
Of course if you're still held captive by some proprietaryware or other
that's only available in 32-bit, that's not going to be an option for you.
There are several possible triggers for this problem. The first one is a
broken 32-bit sandbox. For that, try turning it off and remerging
sandbox. If it works, you should then be able to remerge gcc without
issue and remerge sandbox normally.
FEATURES=-sandbox emerge sandbox
If that doesn't work, one thing that has been a problem in the past but
one would hope doesn't apply any more, is if you had eselect-compiler and
gcc-config-2.0 merged at some point. If you did, there's a bug on it you
should look at. If you didn't, this one doesn't apply.
There are various other possibilities due to various broken configs and
etc relating to the 32-bit side of the multilib toolchain. Often the
simplest solution to these is to remerge a known working usually older
gcc, hopefully overwriting whatever's wrong with your current setup,
after which you can normally rebuild the newer gcc using the working old
one, and be back on track.
If you've been running FEATURES=buildpkg for some time, you may have
several older versions of gcc in your binary package archive and can just
remerge one of them, temporarily downgrading gcc to fix the problem, then
use it to merge a current gcc. This of course is one of the benefits of
running with that feature enabled.
If you have NOT been running with FEATURES=buildpkg enabled, you have a
choice. If you have another working gentoo/amd64 machine available, you
can
Re: [gentoo-amd64] Can not compile gcc
I got the same error because I had the noexec option in my fstab file.
The option was set on my swap file bus affected my whole system.
my 2c
2008/11/14, Mansour Al Akeel [EMAIL PROTECTED]:
First of all, I apologies for the HTML formatting. On my fedora, I use
Thunderbird, and have the emails sent in plain text automatically.
Since My system is being UPGRADED to gentoo, I am stuck with the web
interface, and totally forgot the plain text requirement.
Back again to my problem, I have modified my make.conf to this one:
===
CFLAGS=-march=athlon64 -O2 -pipe
CXXFLAGS=${CFLAGS}
CHOST=x86_64-pc-linux-gnu
MAKEOPT=-j2
#FEATURES=ccache
FEATURES=-sandbox emerge sandbox
USE=X aac aiglx alsa aoss asf bzip2 cairo dbus dvd emerald fam firefox gif
glitz gnome gstreamer gtk hal java jpeg mad mp3 mp4 new-login nptl
nptlonly nsplugin opengl pdf png samba spell sqlite svg symlink threads
tiff truetype unicode x264 xcomposite xinerama xml xorg xscreensaver xv
xvid -arts -eds -esd -fortran -ipv6 -kde -qt3 -qt4
VIDEO_CARDS=NVIDIA
===
And trying the emerge again. I will report the results. I am not stuck
with any 32 bit properiatory softwares, but you never know, I may need
it. I will keep the option of getting rid of the 32 bit as the last
option.
Thank you.
On Fri, Nov 14, 2008 at 3:30 PM, Duncan [EMAIL PROTECTED] wrote:
Mansour Al Akeel [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Fri, 14 Nov 2008 14:02:19 -0400:
checking for x86_64-pc-linux-gnu-gcc...
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include -m32
First, please kill the HTML. There's enough old fogies like me that
don't like it, on most Linux related lists at least, that it's really not
a good idea. We have a choice as to whether to reply or not, and some of
the guys that have been around the longest and therefore tend to have the
most wisdom to apply to a problem, may not reply to HTML posts at all --
or even see them in some cases, if they filter them out, as I do for
regular mail. Do you really want to potentially kill the single reply
that might have otherwise been the only one with a working fix?
Anyway, back to your question. See that -m32? That's telling the new
gcc it just built while bootstrapping itself and is there testing, to
compile the test in 32-bit mode. It (I think) builds the 64-bit stuff
first, and is then failing on the 32-bit stuff. IOW, it's an issue
related to the 32-bit aspect of the compile for both 64-bit and 32-bit
support, that you get when you are running a multilib profile.
Personally, since I don't do the proprietaryware that's the biggest
reason to do 32-bit compatibility in the first place, and all the
freedomware I run has long since been 64-bit, I didn't have any reason to
stay with multilib. And, since it gave me headaches like this every so
often, and even when it was working, both gcc and glibc, which are both
already fairly long merges, took effectively double the time to build
because they were being built for both 64-bit and 32-bit, I had lots of
reason NOT to stay with multilib.
So I switched to the no-multilib profile and simplified my life with
faster and more trouble-free gcc and glibc compiles, and have been VERY
happy I did so.
Of course if you're still held captive by some proprietaryware or other
that's only available in 32-bit, that's not going to be an option for you.
There are several possible triggers for this problem. The first one is a
broken 32-bit sandbox. For that, try turning it off and remerging
sandbox. If it works, you should then be able to remerge gcc without
issue and remerge sandbox normally.
FEATURES=-sandbox emerge sandbox
If that doesn't work, one thing that has been a problem in the past but
one would hope doesn't apply any more, is if you had eselect-compiler and
gcc-config-2.0 merged at some point. If you did, there's a bug on it you
should look at. If you didn't, this one doesn't apply.
There are various other possibilities due to various broken configs and
etc relating to the 32-bit side of the multilib toolchain. Often the
simplest solution to these is to remerge a known working usually older
gcc, hopefully overwriting whatever's wrong with your current setup,
after which you can normally rebuild the newer gcc using the working old
one, and be back on track.
If you've been running FEATURES=buildpkg for some time, you may have
several older versions of gcc in your binary package archive and can just
remerge one of them, temporarily downgrading gcc to fix the problem, then
use it to merge a current gcc. This of course is
Re: [gentoo-amd64] Can not compile gcc
I don't know what you mean by swap file bus. The only noexec I have is
on /dev/shm. I jam still waiting for gcc to finish building, no
problems so far, but again, issue may occur any time. Here's my fstab.
If you see anything wrong please let me know.
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/sda3 / ext3noatime 0 1
/dev/sda5 noneswapsw 0 0
/dev/cdrom /mnt/cdrom autonoauto,ro 0 0
#/dev/fd0 /mnt/floppy autonoauto 0 0
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
# use almost no memory if not populated with files)
shm /dev/shmtmpfs
nodev,nosuid,noexec 0 0
On Fri, Nov 14, 2008 at 5:16 PM, Tonko Mulder [EMAIL PROTECTED] wrote:
I got the same error because I had the noexec option in my fstab file.
The option was set on my swap file bus affected my whole system.
my 2c
2008/11/14, Mansour Al Akeel [EMAIL PROTECTED]:
First of all, I apologies for the HTML formatting. On my fedora, I use
Thunderbird, and have the emails sent in plain text automatically.
Since My system is being UPGRADED to gentoo, I am stuck with the web
interface, and totally forgot the plain text requirement.
Back again to my problem, I have modified my make.conf to this one:
===
CFLAGS=-march=athlon64 -O2 -pipe
CXXFLAGS=${CFLAGS}
CHOST=x86_64-pc-linux-gnu
MAKEOPT=-j2
#FEATURES=ccache
FEATURES=-sandbox emerge sandbox
USE=X aac aiglx alsa aoss asf bzip2 cairo dbus dvd emerald fam firefox gif
glitz gnome gstreamer gtk hal java jpeg mad mp3 mp4 new-login nptl
nptlonly nsplugin opengl pdf png samba spell sqlite svg symlink threads
tiff truetype unicode x264 xcomposite xinerama xml xorg xscreensaver xv
xvid -arts -eds -esd -fortran -ipv6 -kde -qt3 -qt4
VIDEO_CARDS=NVIDIA
===
And trying the emerge again. I will report the results. I am not stuck
with any 32 bit properiatory softwares, but you never know, I may need
it. I will keep the option of getting rid of the 32 bit as the last
option.
Thank you.
On Fri, Nov 14, 2008 at 3:30 PM, Duncan [EMAIL PROTECTED] wrote:
Mansour Al Akeel [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on Fri, 14 Nov 2008 14:02:19 -0400:
checking for x86_64-pc-linux-gnu-gcc...
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include -m32
First, please kill the HTML. There's enough old fogies like me that
don't like it, on most Linux related lists at least, that it's really not
a good idea. We have a choice as to whether to reply or not, and some of
the guys that have been around the longest and therefore tend to have the
most wisdom to apply to a problem, may not reply to HTML posts at all --
or even see them in some cases, if they filter them out, as I do for
regular mail. Do you really want to potentially kill the single reply
that might have otherwise been the only one with a working fix?
Anyway, back to your question. See that -m32? That's telling the new
gcc it just built while bootstrapping itself and is there testing, to
compile the test in 32-bit mode. It (I think) builds the 64-bit stuff
first, and is then failing on the 32-bit stuff. IOW, it's an issue
related to the 32-bit aspect of the compile for both 64-bit and 32-bit
support, that you get when you are running a multilib profile.
Personally, since I don't do the proprietaryware that's the biggest
reason to do 32-bit compatibility in the first place, and all the
freedomware I run has long since been 64-bit, I didn't have any reason to
stay with multilib. And, since it gave me headaches like this every so
often, and even when it was working, both gcc and glibc, which are both
already fairly long merges, took effectively double the time to build
because they were being built for both 64-bit and 32-bit, I had lots of
reason NOT to stay with multilib.
So I switched to the no-multilib profile and simplified my life with
faster and more trouble-free gcc and glibc compiles, and have been VERY
happy I did so.
Of course if you're still held captive by some proprietaryware or other
that's only available in 32-bit, that's not going to be an option for you.
There are several possible triggers for this problem. The first one is a
broken 32-bit sandbox. For that, try turning it off and remerging
sandbox. If it works, you should then be able to remerge gcc
Re: [gentoo-amd64] Can not compile gcc
On Fri, 14 Nov 2008 14:02:19 -0400 Mansour Al Akeel [EMAIL PROTECTED] wrote: Any idea ? Enable IA32_EMULATION in your kernel -- Christoph Mende Gentoo/AMD64 Operational Lead and Release Engineering GPG: EE2A 454A 6A3B A2D8 E43B FF45 2A19 C3B3 6DA0 C1AF signature.asc Description: PGP signature
Re: [gentoo-amd64] Can not compile gcc
OK, that's it. I have this in my make.conf, and emerged gcc with:
emerge -vuD --newuse gcc
--
CFLAGS=-march=athlon64 -O2 -pipe
CXXFLAGS=${CFLAGS}
CHOST=x86_64-pc-linux-gnu
MAKEOPT=-j2
#FEATURES=ccache
FEATURES=-sandbox emerge sandbox
USE=X aac aiglx alsa aoss asf bzip2 cairo dbus dvd emerald fam firefox gif
glitz gnome gstreamer gtk hal java jpeg mad mp3 mp4 new-login nptl
nptlonly nsplugin opengl pdf png samba spell sqlite svg symlink threads
tiff truetype unicode x264 xcomposite xinerama xml xorg xscreensaver xv
xvid -arts -eds -esd -fortran -ipv6 -kde -qt3 -qt4
VIDEO_CARDS=NVIDIA
--
Now, that's what I am getting.
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for x86_64-pc-linux-gnu-gcc...
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/
-isystem /usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run
C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-target-libstdc++-v3] Error 1
make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.1.2/work/build'
make: *** [profiledbootstrap] Error 2
*
* ERROR: sys-devel/gcc-4.1.2 failed.
* Call stack:
* ebuild.sh, line 49: Called src_compile
* environment, line 4638: Called toolchain_src_compile
* environment, line 5156: Called gcc_src_compile
* environment, line 2964: Called gcc_do_make
* environment, line 2787: Called die
* The specific snippet of code:
* emake LDFLAGS=${LDFLAGS} STAGE1_CFLAGS=${STAGE1_CFLAGS}
LIBPATH=${LIBPATH} BOOT_CFLAGS=${BOOT_CFLAGS} ${GCC_MAKE_TARGET}
|| die emake failed with ${GCC_MAKE_TARGET};
* The die message:
* emake failed with profiledbootstrap
*
* If you need support, post the topmost build error, and the call
stack if relevant.
* A complete build log is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/sys-devel/gcc-4.1.2/temp/environment'.
*
I just enabled IA32_EMULATION and recompiling my kernel. I downloaded
the latest kernel form kernel instead of the one that comes with
gentoo. I will report the results.
Just out of curiosity, how did you know that IA32_EMULATION is not
enabled? Which message told you this ?
On Fri, Nov 14, 2008 at 5:48 PM, Christoph Mende [EMAIL PROTECTED] wrote:
On Fri, 14 Nov 2008 14:02:19 -0400
Mansour Al Akeel [EMAIL PROTECTED] wrote:
Any idea ?
Enable IA32_EMULATION in your kernel
--
Christoph Mende
Gentoo/AMD64 Operational Lead and Release Engineering
GPG: EE2A 454A 6A3B A2D8 E43B FF45 2A19 C3B3 6DA0 C1AF
Re: [gentoo-amd64] Can not compile gcc
Mansour Al Akeel wrote: Just out of curiosity, how did you know that IA32_EMULATION is not enabled? Which message told you this ? He probably just suspected. Kernel's inability to run 32-bit code could be one of the reasons why the test code run failed. Other reason might be some linking error or somesuch...
Re: [gentoo-amd64] Can not compile gcc
I am not gentoo expert and no idea about profiles. However that's what I got: lrwxrwxrwx 1 root root50 Nov 13 17:22 make.profile - ../usr/portage/profiles/default/linux/amd64/2008.0 -rw-r--r-- 1 root root 2141 Jun 16 22:51 profile -rw-r--r-- 1 root root 815 Nov 14 16:12 profile.env I am emerging gcc again. I will see how things will go. In the mean while I am looking into disabling multilib and remove it. I just don't know how, and googling a bit while the emerge process is running. On Fri, Nov 14, 2008 at 6:31 PM, Beso [EMAIL PROTECTED] wrote: 2008/11/14 Branko Badrljica [EMAIL PROTECTED]: Mansour Al Akeel wrote: Just out of curiosity, how did you know that IA32_EMULATION is not enabled? Which message told you this ? He probably just suspected. Kernel's inability to run 32-bit code could be one of the reasons why the test code run failed. Other reason might be some linking error or somesuch... the ability to compile other stuff tells that you're having problems with the multilib profile. i suspect that you're working on a no-multilib profile, instead. try a ls -l /etc | grep profile and see where the actual profile is poiting. -- dott. ing. beso
[gentoo-amd64] Re: Can not compile gcc
Mansour Al Akeel [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 14 Nov 2008 15:54:28 -0400: FEATURES=-sandbox emerge sandbox I'm sorry, I didn't make myself clear on this. If you change the feature in make.conf, you'd use your normal features only change sandbox to -sandbox. What I was suggesting there was to go on the command line (not make.conf). You set FEATURES to -sandbox for just a single command, which is emerge sandbox. So combining that with the ccache suggestion, now for both gcc and sandbox, it would be this (after setting the FEATURES line in make.conf back to normal): First command: FEATURES=-ccache -sandbox emerge sandbox Second command: FEATURES=-ccache -sandbox emerge gcc If you are lucky, after those two commands, you should be back to normal and can remerge gcc without anything funny in either make.conf or on the command line. -- 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
