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.
i really like all the updated packages and stuff in 10.2 compared to 10.1... but i am having issues with 10.2 which i don't have in 10.1 and i suspect it's because of the glibc changes done in 10.2 (NPTL)...
i don't really know a lot about libraries and compilers and stuff but i'm trying to learn... what i would like to do is not have to go back to 10.1, so i'd like to keep my 10.2 but i'd like to make it as though the NPTL changes never happened... in other words i'd like to have a glibc and stuff similar to the one in 10.1...
what steps should i take in order to do this the right way??
i have never recompiled glibc so i don't know the implications this could have... i also don't know what other steps might need to be taken after recompiling it... for example, would i need to recompile the kernel after recompiling glibc??
any help you could give me with this would be great...
well, the issues are mainly some system freezes using some apps... but please let's not get into that, i would want to do this even if i wasn't having problems... it will be an educational experience even if it doesn't solve the issues i am having...
so is it just a matter of taking the glibc build script from 10.1 and using that?? what else would i need to recompile??
Originally posted by batev You can compare the build scripts from 10.1 and 10.2 and see the differnce. They are not quite different.
yeah, i took a quick look yesterday... seems like the main difference is all the NPTL crap... i'm gonna try and recompile the glibc from 10.2 using the build script from 10.1 later tonight... we'll see how it goes...
Although it's been designed to build self hosting cross-toolchains, you can always point it at your arch and build a self-contained second toolchain.
Once you've got the hang of it, and ironed all the bugs out of your toolchain (often there are patches and fixes that need applying en route to toolchain-haven), you might consider rebuilding (and repackaging) your desired version of glibc and link against it binutils and gcc, giving you a whole new toolchain that you can upgrade to.
It's worth pointing out, tho', that even this sort of change may stop everything that links against glibc from functioning, so you'd then have to recompile all your packages against this new toolchain (not impossible if you have a second self-hosted toolchain that you can use to build these packages *before* upgrading).
Originally posted by piete Upgrading (or changing) your glibc may break gcc and binutils, and of course, with them broken, you can't downgrade glibc again.
but then how does Pat manage to recompile glibc without having to touch gcc and/or binutils?? take a look at the changelog, glibc has been recompiled many times without having to change anything else... for example:
Sat Sep 10 22:21:22 PDT 2005
OK, everything was set in stone except for these things. ;-)
There may still be a couple more changes (maybe), but this is pretty close.
a/aaa_base-10.2.0-noarch-2.tgz: Fixed rp-pppoe version number in email
to root. (thanks to Piter Punk)
a/aaa_elflibs-10.2.0-i486-2.tgz: Upgraded glib libraries to 2.6.6.
a/bash-3.0-i486-3.tgz: Added bash patch bash30-016.
(suggested by Fredrik Rinnestam and Xavier Thomassin)
Added a patch to prevent an issue with newer glibc versions and 2.4.x
kernels that leads to a bash hang if bash is recompiled on such a system.
(Thanks to Fredrik Rinnestam) a/glibc-solibs-2.3.5-i486-5.tgz: Recompiled against header files from
linux 2.4.31 (linuxthreads version) and linux 2.6.13 (NPTL version).
ap/vim-6.3.086-i486-1.tgz: Upgraded vim to patchlevel 86, and upgraded to
l/esound-0.2.36-i486-1.tgz: Upgraded to esound-0.2.36.
l/glib2-2.6.6-i486-1.tgz: Upgraded to glib-2.6.6. l/glibc-2.3.5-i486-5.tgz: Recompiled.
l/gtk+2-2.6.10-i486-1.tgz: Upgraded to gtk+-2.6.10.
l/pango-1.8.2-i486-1.tgz: Upgraded to pango-1.8.2.
Thanks to Giacomo Lozito for pointing the bugfix releases of glib, gtk+,
and pango out. The 2.8 series still needs time to stabilize and may present
some compatibility issues (just a guess), and the version bump on atk-1.10.1
makes me want to play it safe on that one as well. We'll get to those in the
l/sdl-1.2.9-i486-1.tgz: Upgraded to SDL-1.2.9, SDL_image-1.2.4,
SDL_mixer-1.2.6, and SDL_ttf-2.0.7.
n/nmap-3.90-i486-1.tgz: Upgraded to nmap-3.90. (suggested by many :-)
n/wget-1.10.1-i486-2.tgz: Change /etc/wgetrc to /etc/wgetrc.new so that it'll
be protected from replacement the next time this package is upgraded.
Suggested by Luigi Genoni.
xap/xvim-6.3.086-i486-1.tgz: Upgraded X version of vim to patchlevel 86, and
upgraded to ctags-5.5.4.
Wed Jul 20 16:17:08 PDT 2005
a/glibc-solibs-2.3.5-i486-4.tgz: Recompiled, as I forgot that with both
linuxthreads and NPTL versions of glibc that the patch would have to be
applied twice. Thanks again to Dirk van Deun for pointing out my error.
I tried this once and it broke every binary on my system. :-) I had built my entire system against a 2.6 kernel and a threaded glibc tho. When I downgraded to a non NPTL glibc, all hell broke loose. Couldn't run a single binary on my system. Got all sorts of wierd ld errors and what not.
I'd like to know how Pat got away with switching to an NPTL glibc midstride... I'm thinking it's because the entire system was still built against a non-threaded glibc and 2.4 headers. As far as I'm aware, 10.2 was not a complete recompile. So adding a threaded glibc wouldn't have an effect because the entire system defaults to not looking to use threads anyway. linux-2.4.xx isn't capable of supporting it.... So that leads me to believe that nothing on a stock 10.2 install will be capable of using threads to begin with. I'm assuming he added a threaded glibc so you could compile your own stuff to have thread support.
That's my take on it... Whether or not I'm even close, I don't know. Let us know what happens. Now, when Pat goes for a complete recompile against 2.6 headers ( I assume 11.0 ), I wouldn't even dream of trying to downgrade. You'll open up a can of worms if you do.
as you can tell i know very little about this issue, but it seems like Pat hints at what it took in that file...
BTW everyone, i'm getting ready to go forward with the glibc recompile, but i want to upgrade my kernel (to 2.4.32-rc1) also... right now i'm trying to remember how to go about making a new kernel-headers package... once i have that down, i will proceed... i'm thinking it's gonna go something like this:
- recompile kernel-ide and kernel-modules...
- recreate kernel-sources and kernel-headers...
- recompile glibc...
- recompile alsa...
- recompile nvidia...