Facts and myth about installing new glibc?

[amigo]

Thanks to technosaurus -for keeping some poor folks hope alive that there is a way around doing things sanely. Of course, you know much more about these things than I do and are a master at building things statically. I know there are ways around some of these problems, but as you know, they are not simple. My desire is that people here become convinced of the usefulness of sane building tactics -and especially that what seems to be the 'hard way' is really the easy way. The tricks you mention are way beyond the scope of any development cycle. for instance, how long did it take to get scite to do what you wanted? Could you do that for 237 other programs and still keep up with upgrading them when necessary? And, in between, you (as a developer) might want to write some new stuff -setup routines and other distro-specific stuff... Anything is possible, but some schemes are simply not practical for real scenarios. Also, you are talking about uclibc, which doesn't suffer from the well know 'a-hole problem' that glibc does.... One of the many reasons you prefer uclibc over glibc.

@tallboy, yes there is a way to 'sign' packages which makes the name unique to a certain system. It must consist of a unique name, the lib/prog version, the architecture, the build number and optionally a signature -which can indicate who built the package or for what distro variant it was built, something like this:
myproggie-0.1-i586-1_billybob
where the '-1' is the build number and billybob is the signature. Of course the sig could indicate the person and variant. Anyway, you can probably understand all that except the 'build' number. build numbers are used to distinguish new builds where the program version is not changed. when I first build myproggie-0.1, then the whole string looks as above: myproggie-0.1-i586-1_billybob
But, if I make a mistake, or decide to include somethigng else in the package, then the next build would be: myproggie-0.1-i586-2_billybob, and so on.
Still, there is lots more info which should be available some way, like the date of the build, exact details about the toolchain, etc. The only way to do so is with database files -preferably included inside the package. A central database with the info is simply unmaintainable. On my KISS system, each package contains an overkill of info about itself -even down to the md5sum of every file included. if anyone ever wants to find out if any files on their system have been modified, then the database provides all the necessary info. Of course, each package also contains a list of the exact versions of any libs/progs it depends on. The complete database allows for lots of usage scenarios. For instance, I can query it to tell me which programs a package depends on *and the order in which those dependencies must be built*. Or I can find libs which no programs depend on... There's no substitute for information.

[amigo]

While I'm here, I should mention that there is another key element of the toolchain -the 'libc headers'. Before building a new glibc, one must create a set of headers from the kernel sources, which are used during the build of glibc. These headers define the interface between the kernel and glibc. The kernel version from which the headers are taken have (almost) no relation to the version of the kernel which runs on the new system or which is running at the time that glibc is built. I say almost, because only at critical junctions where major features of the kernel interface change, will there be any need of using newer or older libc headers to accomodate the changes.

So, anyway, before one builds a new glibc, these libc-headers must first be prepared. Slackware calls the package kernel-headers which leads to lots of confusion -people think they should update these headers when they update their kernel, which is not true. In fact, the headers should only be updated when glibc itself is updated.

Also, when building glibc, one must specify a backwards-compatibility range for kernel versions. If you've ever seen or heard of the error 'kernel too old', then this compatibility range is the reason. Usually, most distros use a figure here which lets users run the new system using a kernel from an older release of the distro -one or two versions back. This allows for much easier upgrading.

[tallboy]

Thank you.

tallboy

[Ibidem]

Little tidbit:
Debian's way of identifying packages ends up something like
<packagename><-variant>_<upstream version>-<package revision>~<random comments/repository identifier>_<arch>.deb
So for example:
vlc-nox_2.0.3-1~bpo60_i386.deb
is the from the first VLC 2.0.3 build, has X11 disabled, and comes from Debian's backports for Squeeze, and is built for the "i386" architecture (really only runs on i486+ machines).
Packages from different architectures are incompatible.
Dependencies can be by packagename (vlc-nox) or can specify a version like this:
Depends: libogg0 (>= 1.1.0)
This means the SONAME of libogg must be libogg.so.0 (libogg.so.1 doesn't work, since it's ABI incompatible), and the package version must be at least 1.1.0.


Oh, by the way:
libstc++.a does exist.

[technosaurus]

This means the SONAME of libogg must be libogg.so.0 (libogg.so.1 doesn't work, since it's ABI incompatible), and the package version must be at least 1.1.0.

When a new API is used it would be possible to add only the new functions to libogg.so.1 and link it to libogg.so.0 so as to keep compatibility and minimize size, but that would be just too much for autotools to figure out. To make it ideal you would need to add new functions and deprecate old ones rather than making substantial changes to an existing function without changing the name. Eventually the chain would be long enough to start slowing down startup times, but by that time it may be time to rebase the toolchain since most of the maintained apps relying on the oldest builds will have been (or at least could be) rebuilt on the newer ones.

Sorry, I know I get out into the weeds, but I hadn't thought of this before. I'll have to add this to my thesis.