It has been stated on many places that Slackware will be rebuilt ground-up, with new gcc and glibc and so.

But it seems everywhere there is nothing but speculations and vague talk about what gcc version and glibc version will be used.

Does anyone here know ? if so, where did you see/hear it?

I heard Pat is going for the latest (maybe even CVS) glibc and GCC 4.x. Of course you cannot be sure about that until that toolchain actually comes out. What do you want to know?

I feel a little anxious when i don't know everything 

seriously, i don't like it when 'nothing' happens on slackware-current for months.

cvs does not sound like slackware... but ok for gcc 4 , I think gcc 4.2.0 may be just weeks away now so, maybe we'll see some gcc4.1.2 based slackware-current soon.

I rather like the idea of having a well tried-out toolchain to build everything from, but still - newer is cooler.

cvs for slackware? when last time i checked default kernel for 11 was still 2.4? no way.

CVS glibc yes... Rumour has it. Mainly because it would be more stable than the latest stable 2.5 releases .

Huge changes in Slackware current

ftp://ftp.slackware.com/pub/slackware/s ... ngeLog.txt


I wonder when this will affect Zenwalk

anyone has a clue about the build order of our ~400 packages? 

Yes, but he is on a beach in the caribbean

No no, he's working 

++

Working, on a beach in the caribbean? Where can i sign up for that  Cold and windy Amsterdam definitely does not compare well.

@ oskar: the .dep-files and a bit of python-ing (ok, pick your own prefered scripting-language then) should be allow you to sort that build-order out    Inverse-deps-tracking: now that could be a nice new sport 

no sorry, but run dependencies and build dependencies are not the same. as mentioned above for ex. evince needs gnome-icons-2.18 which need standard-naming-uitls which need PERL::XML. Took me several hours to find(!) these, but they are only needed for building not for running evince.

You're right... I just bumped my head on the same problem with Qt-3.3.8 requiring mySQL & sqlite    They too are build-time deps, but not needed for running Qt (plugins..). I don't think we have any standardized mechanism to handle build-time deps    Is this critical enough to do something about it? I sometimes (not very systematically though..) put tests for build-time deps in my buildfile.

For an example: see the k3b buildfile; There i actually do the buildtime deps-check. I'm not 100% content with the 'if [ -f $file-?.* ]' as 'test-regexp', but it has worked quite ok for now.

Oskar is right of course, but as prfaasse says, it is an entertaining pursuit for a rainy Sunday afternoon to invert the dependency tree.

Here is my toy that uses make to do the hard work.  Even though it won't work without build deps for the packages, it does reveal some inconsistencies.

markc

I did a test-run on the 4.4.1 iso.... Not the actual building of course... Some things do make me wonder a bit: for instance:

unrar: gcc-g++ ?

this would imply that you have to have gcc-g++ installed to *run* (remember, we have runtime deps here..) unrar... So: unrar does some small on-the-fly compilation to extract a rar-archive? I have to admit it is possible, but i do think it is unlikely...  Otherwise: i do think that gcc would have to be one of the first things to be built & should be installed for about the complete rest ;-)

the glibc and /usr/lib/libgcc_s.so.1 are linked together somehow but this has nothing to do with on-the-fly-compiles.


As gcc and glibc is already provided by slackware I don't think we want to built it ( ? ? ? ), the way to make a clean install would be currently.
- copy all of the slackware packages (of course the recompiled versions!) in zenwalk in a directory /my-mountpoint/zw-5.0
- copy aaa_base to /my-mountpoint
- Mount target volume to /my-mountpoint then chroot /my-mountpoint
- installpkg aaa_base
- installpkg /my-mountpoint/zw-5.0/*.tgz
- exit ( to exit the chroot)
then run lilo or adapt grub.conf and boot to /my-mountpoint. now there should be a compiler and a working console system hopefully.