Re: [gentoo-amd64] Can not compile gcc

[Mansour Al Akeel]

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               /               ext3            noatime         0 1
/dev/sda5               none            swap            sw              0 0
/dev/cdrom              /mnt/cdrom      auto            noauto,ro       0 0
#/dev/fd0               /mnt/floppy     auto            noauto          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/shm        tmpfs
nodev,nosuid,noexec     0 0




On Fri, Nov 14, 2008 at 5:16 PM, Tonko Mulder <tonko.mulder@×××××.com> 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 <mansour.alakeel@×××××.com>:
>> 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 <1i5t5.duncan@×××.net> wrote:
>>>
>>> "Mansour Al Akeel" <mansour.alakeel@×××××.com> posted
>>> 2a21586d0811141002p735a3839h74ec70ff8dd7f524@××××××××××.com, 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 versions too often, on whatever partition you decide to
>>> store them on.  The default storage location is $PORTDIR/packages, IIRC,
>>> but you can point portage at a different location by setting PKGDIR in
>>> make.conf as appropriate.
>>>
>>> --
>>> 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
>>>
>>>
>>
>>
>
> --
> Verzonden vanaf mijn mobiele apparaat
>
> Tonko
>
>