TC 3.x: Are further toolchain and / or library updates planned?

[maro]

Out of sheer curiosity I've attempted a "crude" comparison of the current versions used in the tool chain for TC 2.x and TC 3.x. For this I just used the URLs of the sources mentioned in the .info files of the dependencies of compile.tcz. There is therefore the (theoretical) risk that my findings are incorrect, since I have not tried to check the "real" executables and libraries.

Please note I'm writing this here to gain a better understanding of how the whole change from TC 2.x to TC 3.x takes place and what might be still on the horizon. Overall I'm certainly quite impressed how well TC 3.0alpha is shaping up.

What I did was that (actually a few days ago) I simply "followed" the URLs and checked if a newer version of a source tar-ball seemed to be available (either in the same directory or somewhere in the "neighborhood"). This is probably not the best heuristic, but as I wrote before I'm just a bit curious without having any particular intention. In a few cases the URLs appeared to be "stale", so I used "google" in an attempt to find the most likely "current place".

Most of the extensions in question have been "bumped up", but for some (like flex, make, and pkg-config) TC 2.x probably has already used the latest available version. Then there are some which appear to be now on the latest available version (like bison, findutils, gmp, m4, mpfr, patch, ppl, and sed). For a few (like binutils, cloog, diffutils, file, gawk, gcc, gperf and grep) a newer release seems to be available. But since in almost all cases this appears to be just a slightly higher minor version. I therefore consider the tool chain to be pretty much "up to date".

I've only "stumbled" over a few small things where I'd appreciate if someone from the Core team could maybe share some insights:
(1) Judging from the URLs in 'base-dev.tcz' the libraries have by and large not been changed (apart of course from those related to the kernel, gcc and glibc). There appears to be in some cases (like libfltk, libjpeg, libpng, ncurses, util-linux and zlib) newer versions available. Is it under consideration to include some updates of those in the future?
(2) In TC 3.x the 'gcc.tcz' extension has now dependencies (i.e. 'cloog.tcz', 'ppl.tcz', 'gmp.tcz' and 'mpfr.tcz') which were not required for TC 2.x. I'm curious to find out what the advantage for the "average user" might be in including those now. In particular 'ppl.tcz' with it's not exactly small size of 4.4MB might be of interest here.

[Juanito]

Most of the extensions in question have been "bumped up", but for some (like flex, make, and pkg-config) TC 2.x probably has already used the latest available version. Then there are some which appear to be now on the latest available version (like bison, findutils, gmp, m4, mpfr, patch, ppl, and sed). For a few (like binutils, cloog, diffutils, file, gawk, gcc, gperf and grep) a newer release seems to be available. But since in almost all cases this appears to be just a slightly higher minor version. I therefore consider the tool chain to be pretty much "up to date".

At the time I compiled the gcc "helper" apps for tc-3.x - bison, file, findutils, gawk, gperf, grep, m4, patch, sed - they were the latest available version. Since that time, there may have been a few updates as you suggest.

binutils, gcc and glibc were chosen according to what was listed as the latest stable version at the time we started working on the tc-3.x kernel/toolchain and cloog, gmp, mpfr and ppl were the latest versions available at that time.

(1) Judging from the URLs in 'base-dev.tcz' the libraries have by and large not been changed (apart of course from those related to the kernel, gcc and glibc). There appears to be in some cases (like libfltk, libjpeg, libpng, ncurses, util-linux and zlib) newer versions available. Is it under consideration to include some updates of those in the future?

e2fsprogs was updated to add ext4 functionality - personally, I've only thought it worth updating the base libs if they bring one or more of improved performance, smaller size or added functionality - team tc is looking at what base libs might be usefully updated as we speak.

(2) In TC 3.x the 'gcc.tcz' extension has now dependencies (i.e. 'cloog.tcz', 'ppl.tcz', 'gmp.tcz' and 'mpfr.tcz') which were not required for TC 2.x. I'm curious to find out what the advantage for the "average user" might be in including those now. In particular 'ppl.tcz' with it's not exactly small size of 4.4MB might be of interest here.

It seems to be something of a standard to build gcc against gmp/mpfr (see lfs stable) and cloog and ppl were added to enable gcc graphite - see http://gcc.gnu.org/wiki/Graphite - quite what this brings I'm not sure, but I did see something of a difference in extension size for source compiled with/without cloog/ppl.

[^thehatsrule^]

IIRC those became required to build gcc in v4.3, if that's what you're looking for.

[curaga]

I thought we're already on the latest fltk (1.1.10)?

[^thehatsrule^]

Yes, we use the latest stable.  maro could be referring to the experi/developmental branches.

[maro]

Thanks for all your responses so far. I really appreciate your comments.

Regarding the fltk version: The source tar-ball mentioned in 'base-dev.tcz.info' is 'fltk-1.1.9-source.tar.bz2'. I'm aware that there are several development branches, but v1.1.10 is the last stable release. According to a FAQ page "The final release of this branch will be FLTK-1.1.10 and there will be no further releases of the 1.1.x branch - not even for urgent bug fixes.". If TC is already using this version please ignore my comment. BTW the above mentioned URL in the .info file is one of those "broken" ones.

Furthermore I've just spotted that TC 3.0a4 has been released and that seems to contain several library updates. Things are still moving pretty damn fast in the world of TC / MC ...

[roberts]

fltk-1.1.10 is in the base. Perhaps an extension info file needs updated?

[maro]

Thanks Robert for clearing this up. As I wrote in the OP my "method" had the caveat that I assumed the .info files to be correct.

That raises the generic question: What is the "proper" way to find out the release level of a shared library? I mean looking at the file name (e.g. libfltk.so.1.1) does provide a "strong hint" towards the major version information (e.g. 1.1) but does not help to differentiate between the minor version (e.g. 1.1.9 vs. 1.1.10).

[roberts]

Peruse http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release/src/

[^thehatsrule^]

It could be that the extension wasn't updated.

[maro]

Fair point Robert, but I was more or less thinking along the line of a command like gcc -v. Obviously one can't "call" a shared library from the shell, so I was wondering if there is a way via 'strings', 'nm', 'readelf', etc.

[Arslan S.]

did you check pkgconfig files in base-dev.tcz ? they contain version infos
see /usr/bin/fltk-config for libfltk

fltk-config --version returns 1.1.9

[Juanito]

did you check pkgconfig files in base-dev.tcz ? they contain version infos
see /usr/bin/fltk-config for libfltk

fltk-config --version returns 1.1.9

Hmm - in the case of fltk, it could be that I missed updating the dev files...

[Arslan S.]

did you check pkgconfig files in base-dev.tcz ? they contain version infos
see /usr/bin/fltk-config for libfltk

fltk-config --version returns 1.1.9

Hmm - in the case of fltk, it could be that I missed updating the dev files...

yes exactly as you think
another proof is :
pkg-config libpng --modversion returns 1.2.29

[^thehatsrule^]

Fair point Robert, but I was more or less thinking along the line of a command like gcc -v. Obviously one can't "call" a shared library from the shell, so I was wondering if there is a way via 'strings', 'nm', 'readelf', etc.

Some could though, like the libc (ie run /lib/libc.so.6)