SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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.
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.
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!!
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
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.
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
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... 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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.