-1
.
.
.
checking for kernel header at least 3.2.0... ok
*** On GNU/Linux systems the GNU C Library should not be installed into
*** /usr/local since this might make your system totally unusable.
*** We strongly advise to use a different prefix.  For details read the FAQ.
*** If you really mean to do this, run configure again using the extra
*** parameter `--disable-sanity-checks'.
Pre-configuration commands finished with code: 1

I wanted to look at some c code so I just cloned glibc, opened it in clion, and this error came up.

  1. What do I do to build it on my system: debian?
  2. Why would debian do such a thing?

2 Answers 2

2
  1. Why would debian do such a thing?

This is not caused by Debian, but by the way the C compiler and the dynamic linker/loader are configured on most Linux systems: if there is a library with the same name in both /usr/local/lib and /usr/lib, the one in /usr/local/lib takes priority.

This allows the system administrator to easily replace any library on their system with a customized one, and have their custom library persist over package updates.

However, replacing your installed glibc with a custom one is not a good idea unless you really know what you are doing: it affects practically every command and program on the system, including the tools you use to install your new glibc.

From the glibc Frequently Asked Questions wiki page:

Why shall glibc never get installed on GNU/Linux systems in /usr/local?

The GNU C compiler treats /usr/local/include and /usr/local/lib in a special way, these directories will be searched before the system directories. Since on GNU/Linux the system directories /usr/include and /usr/lib contain a --- possibly different --- version of glibc and mixing certain files from different glibc installations is not supported and will break, you risk breaking your complete system.

If you want to test a glibc installation, you must install to a different directory with DESTDIR (do not override --prefix with another value, since only --prefix=/usr is allowed).

How do I install all of the GNU C Library project libraries that I just built?

The only pedantically correct way to install these libraries is to install them first into a temporary directory such as /tmp/glibc via make install DESTDIR=/tmp/glibc, then copy that directory into an initial root disk, boot the initial root disk, and copy the results to your root filesystem, and then pivot into the root filesystem as the final step of booting. That is the only safe way to install glibc today.

Notice however that no distribution does this. They don't do it because it would require a reboot after a glibc install, and at present that's only required if you want all processes running to reload glibc after a security update (since already running processes will still be running the old library). Instead the distributions use a package manager to unpack an archive of the libraries and install them into a running system. This is actually quite dangerous because at some point in time you will have a mixed copy of the libraries on your system, some will be new, some will be old, and that may cause, for that small window of time, all newly executed processes to fail to start. In a similar fashion during the upgrade the localization archive that contains locales for languages will be rebuilt, and during that period processes may fail to start if their needed localization language is missing (not yet rebuilt into the archive). Even the package management system is not immune, for example rpm has to take measures not to exec new processes while installing glibc, using instead a builtin lua interpreter to run scripts, to allow rpm to run using the old copies of the libraries as a cohesive whole, while installing the new copies.

In summary, the best way to install glibc is to install it from another system into the disk you're using, usually this can be done in an initial root disk, the next best way is via static or carefully crafted application that can copy the new files into place without itself trying to execute new processes with an incomplete partial install. Choose one or the other. Eventually the latter will become unsupportable on heavily loaded systems that share a runtime.


  1. What do I do to build it on my system: debian?

Like the FAQ says, the DESTDIR environment variable. Do it before you begin, so the safety check in glibc's ./configure script won't trigger.

Once you have built it, you may be able to test it somewhat by setting the LD_LIBRARY_PATH environment variable to point to $DESTDIR/lib. But as described above, it may cause conflicts with other files belonging to your Debian standard version of glibc.

A better way to test the new glibc would be to prepare a virtual machine, then mount its disk to the host system (with the VM stopped), so you can install all the components of your new glibc to the VM before needing to run any of them and risking incompatibility. Then you can start the VM and see what happens.

If the still VM works and the new glibc passes any tests you want to do at that point, only then you can start considering installing the new glibc to your host system. And for that, you'll need to plan carefully: will you boot from an external media to install your new glibc? Or will you package the new glibc into a (set of) *.deb package(s), and use the package manager to install it? Either way, make extra sure yor backups are up to date and you have a boot media at hand before you start.

If you decide to use the packaging route, then I urge you to first load the source packages for your distribution's standard version of glibc, and carefully study the packaging and any pre/postinstall scripts included: even using a package manager, there can be specific steps in the process that must be performed exactly right.

-1

You need to pass --prefix=<some other directory> to configure script. It will make sure files are installed in <some other directory>[0].

Installing an incompatible version of glibc in /usr/local may render your system useless.

To compile glibc go to root of source tree and

cd build
../configure --prefix=<some other directory> # /tmp/compileGlibc
make -j$(nproc)

This should build glibc. And running

make install

will install files to <some other directory>.

Also you can compile glibc with default PREFIX by passing --disable-sanity-checks to the configure script.

[0] https://sourceware.org/git/?p=glibc.git;a=blob;f=INSTALL;h=b29916e748c25a25888125ee3d162050d6339181;hb=HEAD

1
  • You can't change the prefix when configuring glibc. Only /usr is allowed.
    – onwsk8r
    Feb 1 at 16:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .