SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Hello Slackware friends.
If someone of you try to compile new glibc-2.17,this is what you gotta do
put this in diffutils and tar,because they will fail to compile without that line in SlackBuild script.I will test other packages to view if they fail to compile with new glibc
sed -i -e '/gets is a/d' gnu/stdio.in.h
Sorry for my english
This is the packages that i tested and they compile perfect with new glibc
This is the build order that i compile my packages after bild toolchain from my next post
Still testing the new glibc, which removes the gets() function and may or may
not be a safe upgrade yet. It might be safer after the next gcc comes out.
consider that the first release candidate (not the final one) of gcc-4.8.0 is, at least (being optimistic), one month away...
As you are basically rebuilding a slackware system from scratch, (if you feel like) could be useful also for others to update the first post with the exact order you follow in building the various packages
glibc #Here i add this line to SlackBuild sed -i -e 's/-lgcc_eh//g' Makeconfig
patches for glibc is glibc-2.17-sync-with-linux37.patch and glibc-2.17-no_timezones.patch
difutils # sed -i -e '/gets is a/d' gnu/stdio.in.h This in SlackBuild
tar #This line iin SlackBuild sed -i -e '/gets is a/d' gnu/stdio.in.h
New packages that's compile correctly is all KDE-4.10 deps and all KDE-4.10 with new glibc-2.17.
I will try gcc-4.8 snapshot
All packages are compiled with CFLAGS -O2 -fpic -pipe -march=native
Also i have a one question why Slackware packages are compiled with fPIC instead fpic ?
create the object files that will go into the shared library using the gcc -fPIC or -fpic flag. The -fPIC and -fpic options enable ``position independent code'' generation, a requirement for shared libraries;
Use -fPIC or -fpic to generate code. Whether to use -fPIC or -fpic to generate code is target-dependent. The -fPIC choice always works, but may produce larger code than -fpic (mnenomic to remember this is that PIC is in a larger case, so it may produce larger amounts of code). Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, I choose -fPIC, because it always works.
While the architectures supported by Gentoo are quite differently addressing memory, they all share the same characteristic: direct non-PIC-aware addressing is always cheaper (read: faster) than PIC addressing. For example the RISC (Reduced Instruction Set) architectures sparc, ppc and hppa sometimes use more than one assembler command issuing several more opcodes to do what x86 does with a single variable length assembler command, loading a full 32-Bit address for example. Only the AMD64 seems to support some kind of "emulation" mode where it does not seem to make a difference if PIC or normal addressing is used for referring code functions and data to access.
-fPIC is enabled in the *.SlackBuilds only for the x86_64 architecture.
I decided to update my toolchain. Well actually only glibc and rebuilding the toolchain.
1) U glibc-2.19-1
I just needed to add/delete a patch to the slackbuild and all went well.
2) R zlib-1.2.8-2
Why not huh?
3) R binutils-2.23.52-3
4) R oprofile-0.9.7-5
5) U file-5.17-1
6) R gmp-3.1.2-2
7) R mpfr
9) U libmpc-1.0.2-3
ln -s libmpc.so.3 libmpc.so.3
10) R gcc-4.8.2-2
First install gcc-gnat gcc-java and gcc-go and reinstall updated packages including gcc-g++
11) R libtool-2.4.2-3
12) R binutils-2.23.52-4
13) R popt
14) R oprofile
15) R glibc-2.19-2
PART 2: base rebuild according to LFS book and dependencies according to salix
R zlib, R file, R attr, R acl, R sed, R bzip2, U pkg-config-0.28-1, R shadow, R ncurses
R libtermcap, R procps and U psmisc-22.21
R libcap and U coreutils-8.22
R m4, R flex, U bison-3.0.2, R bash, R libtool, R gdbm, R net-tools
A few updates are available but gave me problems like gdbm and I decided to skip procps-ng.
Net-tools is unmaintained and the slackbuild needed a few extra patches.
R autoconf, U automake-1.14.1, R diffutils, R gawk, R findutils, U gettext-0.18.3.1, R xz
R less, R gzip, R kbd, U kmod-16, R make, R patch, R sysklogd, R sysvinit, U tar, R texinfo.
Again a few could need some updating like kbd but did not try, tar needed a few patches and texinfo is old.
R readline, R bc, R gawk, R man, U man-pages-3.61, R db48, R expat, R openssl and openssl-solibs.
U perl-5.18.2. I tried gdbm > 1.8.3 but somehow the usr/include/gdbm.h does not install.
I should try to upgrade to man-db as well. Readline is also quite old.
R libpng, U freetype-2.5.3, U fuse-2.9.3, R libelf, R libffi, R python, R gamin, U glib2-2.40.0 and R gamin again.
Python could get an update though. Almost there.
R udev, U util-linux-2.24, R udev, U e2fsprogs-1.42.9, U mdadm-3.3, R lvm2, R grub.
I spent a lot of time fixing grub with a few hard to find patches.
R libmnl, R libnfnetfilter_conntrack, R libnl3, U libusb-1.0.18, U libpcap-1.5.3, iptables and iproute2.
U iptables-1.4.21, U iproute2-3.12.0. Almost forgot R nano.
R sysvinit-functions and salix scripts. The scripts are built with SLKBUILD.
R mkinitrd and I rebooted!
If I made some foolish errors, so what, I can go again!
Is there a slackbuild available for the headers?
Last edited by hendrickxm; 03-29-2014 at 12:35 AM.
I will update to 3.12 kernel headers since that release is the new LTS.
Next, am I going to think about what packages I can/will upgrade/rebuild and the order.
I used the LFS-book, the dependencies according to salix and toolchain notes in this write-up: http://eerielinux.wordpress.com/2013...x-system-pt-3/ as a lead.
I tried to create packages for an updated kernel but I have not figured out yet how I can rebuild a "huge" kernel package. I tried to change the direcotries in the slackbuild but the buildscript finishes almost instantly without actually building a package.