LinuxQuestions.org - Which GCC is the Best for Slackware 10.2?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Which GCC is the Best for Slackware 10.2? (https://www.linuxquestions.org/questions/slackware-14/which-gcc-is-the-best-for-slackware-10-2-a-480130/)

Which GCC is the Best for Slackware 10.2?

I'm wondering: Which is the best version of GCC to go with Slackware 10.2?

The version that comes with Slack 10.2 is 3.3.5.

I once successfully upgraded to GCC 4.0.3 and it worked fine, except that some apps wouldn't compile with GCC 4.x.

So, is 3.3.5 the best choice? Which compiles the most apps and is stable and bug-free enough even in the optimizer department?

Well, applying some basic logic along with knowing that PV strives to ensure a stable release, and the release was compiled with the version that ships with it, I'd say that the one that ships with the release would be the best one.

Is it possible to recompile the entire release? I wondered about that a couple of times.

I had Kernel 2.6.16 recompiled with GCC 4.0.3, and it seemed much faster somehow. When I compared the disassembly of one of my own programs, it showed that 4.0.3 generates much shorter, better code. When I wanted to compile the latest versions of KDE or GNOME, I had no luck, however; then I briefly migrated to SuSE Linux 10.1 to see Xgl/Compiz in action, and I noticed they had GCC 4.1.0. Weird!! But I'm back to Slackware 10.2 now, because it's my pair of shoes! :)

I'm using KDE instead of GNOME, because when I used XFCE and installed FRG from Linuxpackages, some things in XFCE stopped working, so with my new install, I decided to use only KDE for a while.

So you think I should not tamper with the system, and leave it just as it is?

Do any people here have experience with customizing their system with the latest and greatest stuff?

Is that even possible?

If you don't want GCC 3.3, 10.2 has GCC 3.4 in testing/ (it's now the default compiler for -current and in turn, will be for 11.0)

Slackware sticks to GCC 3.x because it is tried and tested - there is nothing to stop you switching to GCC 4 if you are prepared to build it yourself.

And yes, it is quite possible to then rebuild the entire release from scratch if you really want to.

Quote:

when I used XFCE and installed FRG from Linuxpackages, some things in XFCE stopped working

Freerock, although not as intrusive as other Gnome's, does still replace some Slackware packages with its own versions. I would imagine that some of these replaced libraries XFCE depends upon, hence why it is likely breaking.

The new gentoo uses GCC 4.1.0 as default option so it should be relatively safe to use it to compile KDE. Atleast I just compiled it with no problems :)

Thanks, you two! :)

I'll give GCC 4.1.0 a try; perhaps it's more compatible to the 3.x version than 4.0.3. :)

Well, that is the whole idea behind Linux as well as Slackware. It's your system so do what you want with it.

It would be nice if you can post your results. And if possible a description how you compiled gcc-4.X for Slackware, maybe I can (with help from others) write a slackbuild-file.

regards Thorsten

OK, so here goes:
1. Download the full "gcc-4.1.1" source package from gcc.gnu.org (ca. 38 MB).
2. As a normal user (not root), enter the untarred directory (e.g. "gcc-4.1.1")
3. Run the command:

Code:

configure --prefix=/usr

4. Run make:

Code:

make

5. After a couple of hours ;) -- after make is done, become root, enter the directory, and type

Code:

make install

6. Et voila! ;)

I just compiled a bunch of stuff with 4.1.1, and things are looking very good indeed!! My kernel 2.6.16 compiled with 4.1.1 runs about 5-10 times faster than the old version that was compiled with 3.3.5 (subjective impression).

I built the dependencies for KDE 3.5.4 (from linuxpackages.net) and installed everything, and now I'm running KDE 3.5.4! :) (btw, I have to tell the maintainer of that package that is package list is incomplete).

The reason for me to upgrade to GCC 4.1.1 was that compiling "liboil" caused a GCC 3.3.5 crash with internal compiler error while compiling optimized SSE2 code. With GCC 4.1.1, no problem!! :)

Quote:

Originally Posted by aspartat

It would be nice if you can post your results. And if possible a description how you compiled gcc-4.X for Slackware, maybe I can (with help from others) write a slackbuild-file.

Oh that'd be really great, i'm saving a 4gb partition to trash and experiment, i'll try it for sure

I also upgraded my gentoo to gcc-4.1.1 and i'm done with it, i had to recompile every single package, working fine, no noticeable improvement in anything. I'll replace it with crux soon.

Can't beat Slackware to get out of the way and let you experiment, do whatever you want, trash it all, reinstall in 20 min and keep on having fun :)

Quote:

Originally Posted by byte weaver

OK, so here goes:
My kernel 2.6.16 compiled with 4.1.1 runs about 5-10 times faster than the old version that was compiled with 3.3.5 (subjective impression).

Just curious!

How du you measure the speed of your running kernel?
And 5-10 times - isn't it too much, even for subjective impression? :)

Like, for instance, the NVidia driver installer took a couple of minutes before, and a couple of seconds afterwards (going thru the same stages). :)
Or the kernel boots more quickly, ReiserFS accesses the hard drive much faster, and during mounting, I hear a noise that sounds like WAV file from the hard drive! ;)
Not so before that, everything was much slower.

I have a Pentium 4 processor with hyperthreading. Perhaps using the GCC 4.1.1 had some benefits in that regard.

Quote:

Originally Posted by aspartat

It would be nice if you can post your results. And if possible a description how you compiled gcc-4.X for Slackware, maybe I can (with help from others) write a slackbuild-file.

regards Thorsten

Here's my build script if anyone is interested. I don't agree with dicing packages up so it's monolithic unlike Pat's. If you build for i486 make sure you change the fomit sed. I use /usr/lib for libexecdir, don't employ TARGET/HOST, hate docs and don't compress info.. ;-) All in all, it's diff than the official slackbuild. With some minor tweaking, it can be slackware standardized.

Code:

#!/bin/sh

#

# $CFLAGS are set globaly in /etc/bashrc



CWD=`pwd`

TMP=/tmp

PKGNAME=gcc

PKG=$TMP/package-$PKGNAME

VERSION=4.1.1

PKGVER=${VERSION}

ARCH=i686

BUILD=1



rm -rf $PKG

mkdir -p $PKG/install



cd $TMP

echo

echo "$PKGNAME-$VERSION source is now extracting..."

rm -rf $PKGNAME-$VERSION

rm -rf $PKGNAME-build

tar xjf $CWD/$PKGNAME-$VERSION.tar.bz2

mkdir $PKGNAME-build

cd $PKGNAME-$VERSION

chown -R root.root .

find . -perm 777 -exec chmod 755 {} \;

find . -perm 775 -exec chmod 755 {} \;

find . -perm 754 -exec chmod 755 {} \;

find . -perm 664 -exec chmod 644 {} \;

# Use libiberty.a from Binutils:

sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in

# Prevent the fixincludes script from running & delete debug ref

sed -i.bak \

        -e 's,\./fixinc\.sh,-c true,' \

        -e '/^LIBGCC2_DEBUG/d' gcc/Makefile.in

# Add `-fomit-frame-pointer' for x86

[[ $VERSION == 4.* && $ARCH == i686 ]] && \

        sed -i.bak2 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in

# Increase the timeouts on 2 libmudflap tests to avoid spurious failures

[[ $VERSION == 4.* ]] && \

        sed -i.bak '/dg-timeout/s/3\|10/20/' libmudflap/testsuite/libmudflap.cth/*.c



cd ../$PKGNAME-build

  ../$PKGNAME-$VERSION/configure --prefix=/usr \

        --libexecdir=/usr/lib \

        --enable-shared \

        --enable-languages=c,c++ \

        --enable-clocale=gnu \

        --enable-threads=posix \

        --enable-__cxa_atexit



# See if we should bootstrap or not:

if gcc -dumpversion | grep $VERSION 2>/dev/null 1>/dev/null ;then

  make LDFLAGS="-s"

else

  make LDFLAGS="-s" bootstrap

fi



# Ask the user if they want to run the test suite:

echo

echo "Compilation of $PKGNAME-$VERSION is now done. You might want"

echo "to take the time to review the above output and make sure"

echo "it completed with no errors..."

echo

echo "The GCC test suite is very comprehensive and is almost guaranteed"

echo "to generate a few failures. It also takes quite some time to run..."

echo

echo "Do you wish to test the results? ([y], [n])"

if [ ! "$RESP" ]; then

  read RESP;

  echo

fi

if [ "$RESP" = "y" ]; then

  echo "O.k... Probably not a bad idea..."

  echo

  runtest=yes

  sleep 2

  make -k check

fi

if [ "$RESP" = "n" ]; then

    echo "Skipping tests..."

    echo

    sleep 2

fi



make install DESTDIR=$PKG

chmod 755 $PKG/usr/lib/libgcc_s.so.1

( cd $PKG

    mkdir -p lib

    cd lib

    ln -svf ../usr/bin/cpp cpp

    cd ../usr/bin

    ln -svf gcc cc )



# Fix info dir

if test $PKGNAME = texinfo; then

  true

else

  rm $PKG/usr/info/dir

fi



# Compress and strip

( cd $PKG/usr/man

    gzip -9 */*

    cd man1

    ln -svf g++.1.gz c++.1.gz

    ln -svf gcc.1.gz cc.1.gz ) 

# Should be redundant because of LDFLAGS 

( cd $PKG

    find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

    find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null

    find $PKG -name "*.a" | xargs file | grep "archive" | cut -f 1 -d : | xargs strip -g )



# Make the package description:

cat << EOF > $PKG/install/slack-desc

# HOW TO EDIT THIS FILE:

# The "handy ruler" below makes it easier to edit a package description. Line

# up the first '|' above the ':' following the base package name, and the '|'

# on the right side marks the last column you can put a character in. You must

# make exactly 11 lines for the formatting to be correct. It's also

# customary to leave one space after the ':'.



  |-----handy-ruler----------------------------------------------------------|

gcc: gcc (GCC with C support)

gcc:

gcc: GCC is the GNU Compiler Collection.

gcc:

gcc: This package contains those parts of the compiler collection needed

gcc: to compile C code.

gcc:

gcc:

gcc:

gcc:

gcc:

EOF



# Build the package:

cd $PKG

makepkg -l y -c n $TMP/$PKGNAME-$PKGVER-$ARCH-$BUILD.tgz



if [ "$runtest" = "yes" ]; then

  echo "Here are the test results for GCC-$VERSION"

  echo

  echo

  echo "******************************************************************"

  echo "* !!!!!!!!!!!!!!!  BEGINNING OF TEST SUMMARY  !!!!!!!!!!!!!!!!!! *"

  echo "******************************************************************"

  echo

  echo "If this is the only thing you see, then your missing"

  echo "some packages that were needed in order to run the test"

  echo "suite. Tcl, Expect and DejaGNU must be installed first..."

  echo

  cd $TMP/$PKGNAME-build

  ../$PKGNAME-$VERSION/contrib/test_summary

  # For just the brief summaries:

  #../$PKGNAME-$VERSION/contrib/test_summary | grep -A7 Summ

  echo

  echo "******************************************************************"

  echo "* !!!!!!!!!!!!!!!    END OF TEST SUMMARY    !!!!!!!!!!!!!!!!!! *"

  echo "******************************************************************"

  echo

  echo "Package creation complete..."

  echo

fi

Quote:

Originally Posted by jong357

Here's my build script if anyone is interested.

Wow, thanks! I'm also very interested in a DIY-Slackware, any advice/link/comment/pm and specially howto are very welcome :study:

Well... Lot's of time is the first thing you'll need..

http://www.diy-linux.org/x86-reference-build/

There's the base that I follow. Much, much better way to bootstrap a system than LFS IMO. After your done with the toolchain, install pkgtools.

http://jaguarlinux.com/pub/DIY/

The pkgtools in 'base' is version 11.0 with the xorg stuff removed and "slack-desc" changed to "desc" via patch, but vanilla otherwise. Once you finish the base system, you'll need to scour Pat's FTP site for the bootscripts. I personally use SysVinit cause I think they look purty... Really, I guess the only reason why I call it DIYSlackware is because of pkgtool... :scratch: I do use the network scripts from Slack tho. They are just modified to display evaluate_retval from rc.

Actually... Give me a day or so and I'll upload all my crap to that site all orderly with instructions as well. If people want to use it verbatum then cool, if not, it's a decent something to look at just to see what's possible.

I have some neat Xorg-7.1 scripts that some of you may be aware that I was working on a couple weeks ago. I'll throw them up there as well. They work a charm on slack and my DIY system.

Here is a preliminary README that I'll upload with all my scripts.

Code:

There are alot of personal prefrences in these build scripts that

you may want to change. Grub, base, etc, network to name a few.

Remember to read each build script before running for your

package. "grep -R Jaguar ." in the base directory too. I name my

OS "Jaguar" and there are a few refrences to it. Remove/change them.

Might also want to grep for lowercase "jaguar"...



Look at the pkgtools patch. You might want to add for the title,

"DIY pkgtools" or something, instead of just "pkgtools". You get

the idea. Customize the little things to make it more personal.



The ARCH variable is set to "powerpc" because I build this on

my powerbook. Do a global sed to change them for what arch you are

building for. I suggest using "i686". I do if/then checks on the

ARCH and they are only setup to handle "i686" or "powerpc".. Just

a word of warning.



Here is a command that might work to use from within your "base" source directory:



find . -type f -name *.build | xargs sed -i 's@ARCH=powerpc@ARCH=i686@g'



I'm almost positive that SHOULD only change the ARCH variable at the top

of each script. :-)



while your at it, do this:



chown -R root.root *

chmod -R 644 *



You could just run all these scripts as is and not worry about things,

but you'd be running the same exact thing I am. If your interested in

building your own UNIQUE OS, then you probably don't want that.



In a nut shell, this is a DIY/LFS build optimized for an {i686,powerpc} arch, using

SysVinit bootscripts but with Slackware's rc.inet{1,2},rc.wireless scripts,

modified to display SysVinit style. rc.wireless.conf and rc.inet1.conf are

located in /etc/sysconfig without the "rc" prefix. There's not a lot similar

to Slackware except for the package manager I suppose. That and the network aspect.



Build it how you want. You could make an exact clone of Slackware but just

optimize for an i686 arch. I don't see a point in doing that but it's your

call. This is how I choose to build it.



I've removed the glibc/gcc/binutils/kernel source to reduce the download size.

Go grab them yourself. I also like to stick with

gcc-3.4.6

glibc-2.3.6

binutils-2.16.1



I've tried other combinations and they work, for the most part, but you'll

most certainly run into problems with a "bleeding edge" build the further

you progress. Stick with the stable versions. Just my 2 cents. Other than

that, you can check for updated versions on everything else. I did have

problems with lzo-2 and expat-2.x... Stick with the 1.x versions.



The Linux-Libc-Headers project is now dead but with the release of

linux-2.6.18 or maybe 2.6.19 we can get sanitized headers straight

from the tarball!!! :-) with "make headers_install". Sweet.





Build order:

============



Toolchain:



Follow DIY but add file and mktemp at the end. tcl,expect,dejagnu too.





    Make (Pass 1)

    Sed (Pass 1)

    Binutils (Pass 1)

    GCC (Pass 1)

    Linux-Libc-Headers

    Glibc

    GCC (Pass 2)

    Binutils (Pass 2)

    Gawk

    Coreutils

    Bzip2

    Gzip

    Diffutils

    Findutils

    Make (Pass 2)

    Grep

    Sed (Pass 2)

    Gettext

    Ncurses

    Patch

    Tar

    Texinfo

    Bash

    M4

    Bison

    Flex

    Util-Linux

    Perl

    File

    Tcl

    Expect

    DejaGnu

    Mktemp (in pkgtools dir)





Begin Base Build:



Keep your eye out for any anomolies with the listed build order

(first 3 packages). I haven't refined this yet in my documentation

and I seem to remember having some problems last time around (first

couple packages). Nothing that I couldn't realize what was happening

and then fix.



Make sure you are also following the steps at DIY Linux. Performing

the system mounts and what not before starting. Also, /etc/config.site

is unecessary. We don't want man, info and docs to go to /usr/share.

The "base" package is set up to give us a Slackware style hirearchy...



Also make sure all the docs/info/man are getting to /usr and not

/usr/share. Doesn't matter I guess since we have symlinks setup in

/usr/share. I also don't gzip the info pages. I'm also a big HATER

of doc's. I remove pretty much all doc's from all packages with a

couple exceptions.



This whole thing takes alot of time and attention to what's happening

with the packages if your the anal type. My build scripts most certainly

could use some tweaking here and there.



===================



    Pkgtools (manually extract, follow echoed directions)

    Pkgtools (pass 2) (install with installpkg)



everything SHOULD be good to go with pkgtools now. Make sure

'desc's' are showing up and pkgtool is working correctly.

Remember to rebuild pkgtools after you delete your toolchain.



    Base (make sure you run /dev/MAKEDEV)

    Etc (rename /etc/{bashrc,profile})

    Linux-Libc-Headers (might want the inotify patch from LFS) (not included)

    Man-Pages

    Glibc

    GCC

    Binutils

    db

    Coreutils

    Zlib

    Debianutils

    Findutils

    Gawk

    Ncurses

    Readline

    Vim

    M4

    Bison

    Less

    Groff

    Sed

    Flex

    Gettext

    Network

    Procps

    Perl

    Texinfo

    Autoconf

    Automake

    Bash

    File

    Grep

    Libtool

    Bzip2

    Diffutils

    Kbd

    E2fsprogs

    Grub-0.97 (x86) or Yaboot-1.3.13 (ppc)

    Gzip

    Man

    Make

    Module-Init-Tools

    Patch

    Psmisc

    Shadow

    Sysklogd

    Sysvinit

    Tar

    Udev

    Util-Linux

    Linux Kernel

    Reiserfsprogs

    Xfsprogs

    mac-fdisk (ppc)

    hfsutils * (ppc) (can use tcl/tk/X if you want to rebuild later)

    Rename /etc/{bashrc,profile} back to original

    run "pwconv" and "grpconv" then

    SET THE ROOT PASSWORD & CONFIG FSTAB, YABOOT.CONF OR MENU.LST





Boot into new System:

=====================



You can take off in any direction you want but this is usually how

I work it. The quicker you can get a GUI the better off you'll be.

Build Eterm early, right after X infact. It's not listed (along with

it's deps). A terminal with scrollback capability is a great boon. This

order, after squaring away some of the "final" packages in "base", heads

directly towards getting firefox on the system. I'm crippled using links.



This is setup for Xorg-7.1 but you can still use 6.9 if

you wish... I don't like the font situation on Xorg-7.1... Not sure

if my setup is in error or that's the way it's supposed to be.



wget (1st pass)

pkgconfig

libpng

freetype2

expat

fontconfig

xorg-proto

xorg-utils

xorg-lib

libdrm

mesa

xorg-data (1st pass)

xorg-apps (1st pass)

xorg-data (final)

xorg-fonts

xorg-apps (final)

xorg-server

xorg-drivers

xorg-docs (man pages included?)(optional)(no build script yet)

links (1st pass)

perl (final)

gpm

ncurses (final)

tcl

tk

expect

dejagnu

hfsutils (final)

tcpwrappers

network (final) (newer versions of dhcpcd are quirky IMO)

openssl

wget (final)

libjpeg

libtiff

libgif

glib1

gtk1

glib2

cairo

pango

atk

gtk2

popt

links (final)

python

samba

vim (final)

nss

zip/unzip

libidl

firefox