LinuxQuestions.org - what makes glibc-*.tgz so special?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - what makes glibc-*.tgz so special? (https://www.linuxquestions.org/questions/slackware-14/what-makes-glibc-%2A-tgz-so-special-460183/)

what makes glibc-*.tgz so special?

Has anyone noticed that the Slackware (10.2 & current) glibc package is not a standard "tgz" package?

I've been trying to install Slackware onto my laptop (no cdrom or floppy) by using pkgtools in knoppix to install the Slack-packages to an empty partition. This has worked great, except for glibc. The first thing I noticed is that the glibc package is not a regular tar.gz file. On any other Slackware package I can extract it with a standard 'tar -vxf' command. When I attempt this with glibc, I get an invalid file format error. Also, when I try to install glibc with 'installpkg' I get

Code:

Executing install script for glibc-2.3.5-i486-5...

chroot: cannot run command `/bin/cp': No such file or directory

The error is not that big of a deal, I can work around it. It looks like it's trying to use chroot to preform some installation trickery which means I need to install some other packages before this one. I was more curious as to why Pat made this package different from all the others. Can any one easy my curiosity?

Thanks!
...aaron

from glibc doinst.sh script:

Code:

# Timezone stuff:

if [ -L etc/localtime -a ! -r etc/localtime-copied-from ]; then

  mv etc/localtime etc/localtime-copied-from

  chroot . /bin/cp etc/localtime-copied-from etc/localtime

fi

# Add the default timezone in /etc, if none exists:

if [ ! -r etc/localtime ]; then

  ( cd etc ; rm -rf localtime localtime-copied-from )

  ( cd etc ; ln -sf /usr/share/zoneinfo/Factory localtime-copied-from )

  chroot . /bin/cp etc/localtime-copied-from etc/localtime

fi

this is all and only chroot stuff inside the script. I really don't understand which directory is '.' and why chroot inside to perform a copy of time stuff in etc... ?!?!

about the tgz: consider that the glibc-version-arch package is used to build other sources, the glibc-solib-version is used to run binaries.

finally, I've tryed to open it via tar xzvf and it works as a common gzipped archive (as a tar.gz).

M

Quote:

Originally Posted by the_real_absinthe

I really don't understand which directory is '.'

. is the current directory.

Quote:

about the tgz: consider that the glibc-version-arch package is used to build other sources, the glibc-solib-version is used to run binaries.

so glibc is just the headers while glibc-solibs are the compiled libraries? This is good to know, I was only going to install glibc.

Quote:

this is all and only chroot stuff inside the script. I really don't understand which directory is '.' and why chroot inside to perform a copy of time stuff in etc... ?!?!

If this is anything like gcc, it probably doesn't like being worked on in a directory that is not the final install directory. chroot is probably used to trick it into thinking it's in /etc instead of /tmp/glibc*/etc (temporary work directory).

Quote:

finally, I've tryed to open it via tar xzvf and it works as a common gzipped archive (as a tar.gz).

erm... sorry, I must have mis-typed. :(

It does appear to extract with 'tar', but I can't extract it with 'arch' or browse though the archive with Konqueror like I normally can. This is actually why I noticed it, at which point I tested the glibc in slack-current and got the same thing. After that I tried using tar from the command line which didn't work. I see now that it does work from the command line once I use the right options.

Any idea why KDE does not recognize glibc as a regular archive file when all of the other packages work just fine?

Thanks!
...aaron

Quote:

Originally Posted by Nylex

. is the current directory.

sorry! I now that '.' is the current dir. :) I neant why does he chroot in current dir to perform those operation?

M

PS: sorry but I don't use kde so I really don't know anything about arch :(

Quote:

Originally Posted by the_real_absinthe

sorry! I now that '.' is the current dir. :) I neant why does he chroot in current dir to perform those operation?

Before the doinst.sh script is executed, the install script changes directory to $ROOT (or "/" if $ROOT isn't defined). I think that what Pat is attempting to do is run the /bin/cp of the *new* installation instead of the one provided by the install CD (or whatever enviroment you're using to install).
This means that to install the glibc package you will need some package from a/ which contains /bin/cp to be installed before.

Quote:

This means that to install the glibc package you will need some package from a/ which contains /bin/cp to be installed before.

That's what I thought, I was more curious about why the package was different then the error itself. For some reason KDE does not like the file format of this package in both 10.2 and current. Oh well, I guess it doesn't matter to much now that I have the answer to the error.

thanks!
...aaron

Perhaps I'm going out on a limb here, but here's my $0.02 worth to attempt to answer the original question of what makes glibc* so special...
Most (if not all) of the standard utilities in linux (du, ls, cp et al) are not compiled as standalone (statically linked) binaries. Instead, they are dynamically linked against the shared sobject (.so) of glibc. This saves a small TRUCKLOAD of disk space (not to mention all the RAM that would be used at runtime).
However, that does tend to make the glibc shared object rather a critical one because if you accidentally screw it up, you're basically left in a pile of excrement since all the normal utilities RELY on a functional glibc.
Therefore, when it comes time to upgrade glibc (and I'm not going to ask WHY you find the need to do this), the installation scripts need to be especially careful since the new version of glibc might BREAK all the system utilities that were linked against the outgoing version of glibc.
I'm guessing that by temporarily installing the new glibc into a 'holding' location and then using chroot to make that holding location 'appear' to be the correct location is what's really happening...

Thanks, that makes a lot of sense.

And welcome to LQ!
...aaron