taskManeage - Tasks: task #15390, Installing GNU C Library within...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #15390: Installing GNU C Library within project (glibc)

Submitter:  Mohammad Akhlaghi <makhlaghi>
Submitted:  Sun 15 Sep 2019 01:00:52 PM UTC
   
 
Should Start On:  Sat 14 Sep 2019 11:00:00 PM UTC Should be Finished on:  Sat 14 Sep 2019 11:00:00 PM UTC
Category:  Software Priority:  7 - High
Status:  Postponed Privacy:  Public
Assigned to:  makhlaghi Percent Complete:  80%
Open/Closed:  Open Effort:  0.00

Jump to the original submission

Sun 23 Mar 2025 09:47:30 AM UTC, comment #18: 

Indeed, the problem is directly caused by the unavailability of both the old glibc and old kernel hdrs. Apart from that, as you mentioned, having the kernel hdrs as part of the reproducible software system is a must for one using glibc as the topic of this thread.

> Indeed, when building glibc, it is important to include the headers of the host's kernel. That is done in this part of the development branch (of comment 5 below). But this doesn't seem to be related to Boud's problem: he didn't compile glibc. As far as I understood re-building the M4 configure script, or using a more recent version of M4 (see task #16641) the problem was fixed because the configure-time checks passed without any manual override.


The details were clearly discussed in comment #16:. In the opening statement, I was implicitly mentioning that `m4` or other software may rely on specific features/definitions (such as the default stack size for signal handlers in the case of Boud's issue) within the evolved `glibc` whose ingredients are to be found within kernel headers. In other words, the problem is indirectly related to kernel headers version or more simply put, the old `m4` would have worked with the old glibc and the old kernel header.




As far as my interests go on this matter, I am mainly concerned with replacing the chain of gcc-glibc with glibc-gcc. In other words, I am not in line with the LFS approach as I dont find it relevant (objective-wise and order-wise) to a reproducible software system.

Following are my thoughts on the matter for people who share that line of thinking.




Focusing on a GNU/Linux host with a working `glibc-gcc` combination patched and compiled using the kernel headers of that host: the objective is to make sure that the reproducible software system to be built using this host has a specific version of `glibc` built into it and later on specific versions of `gcc` and other software are built using that version of `glibc`.

I am thinking we could do something like:

  • include standard kernel headers of a specific version from the linux official repo in the reproducible software system (so we would not depend on any patches introduced by that host into the kernel and we have standard kernel hdrs as our foundation)
  • cross-compile `glibc` using the standard kernel hdrs (not the host kernel headers), flag --enable-kernel and other carefully selected configuration options for better portability.


For a GNU/Linux host not having a working glibc-gcc duo!! and we insist on not cross-compiling gcc-glibc on a different system, a very naive theoretical approach could be:

  • use `musl` as the initial lightweight glibc-independent C library (or bootstrap a minimal one)
  • cross-compile/install a precompiled `TinyCC` as the initial lightweight C compiler (or bootstrap a minimal one)
  • bootstrap a minimal c++ complier adhering to c++14 and c++17.
  • build the llvm ecosystem using the above two so there would not be any dependence on glibc (all sorts of difficulties could happen here in practice)
  • include standard kernel hdrs like before
  • cross-compile glibc like before but this time using llvm's `clang` as the C compiler.


Mohammadreza Khellat <mkhellat>
Sun 23 Mar 2025 01:40:07 AM UTC, comment #17: 

Thanks Mohammadreza,

> it is quite important to include kernel headers of the
> initial build environment from 4 years ago when building
> the problematic m4 and the rest.


Indeed, when building glibc, it is important to include the headers of the host's kernel. That is done in this part of the development branch (of comment 5 below). But this doesn't seem to be related to Boud's problem: he didn't compile glibc. As far as I understood re-building the M4 configure script, or using a more recent version of M4 (see task #16641) the problem was fixed because the configure-time checks passed without any manual override.

That 'glibc' branch is almost 5 years old now (time really flies! Maneage didn't even have a name at that time, I just called it "the template"!). So it needs some basic updates to fit the more modern Maneage, but have a look at the steps and if you are interested, it would be great if you could help out in ultimately merging it into Maneage.

One of the main reasons I haven't done so is that this model of a single Makefile for many software is not really good. It became very obvious in this branch because almost all the rules in the 'core-gnu.mk' file of this branch are repeated in 'basic.mk' and having such duplicates is not good!

So I have always had it in my long term plans to define a separate shell script for each software that would load common functions and would be called with an automatically created Makefile during the configuration process. In this way, when it is necessary to build one software multiple times (as we now do with Make and Lzip for example at the end of 'basic.mk'), we don't have to have two copies of the code. But the necessary free time to do this re-structuring has never come up so far; not even to formally define it as a separate task, although I think I did hint at this here and there in the tasks (I don't have time to search unfortunately) :-(.

In short, if you are interested, there are a lot of ways you can help ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sat 22 Mar 2025 07:20:17 AM UTC, comment #16: 

Thanks Mohammad and Boud for the inputs.

For the time, this is my take on the problem: due to kernel dependencies of glibc (although it is designed to have backward compatibility and is supposed to work with different kernel versions (--enable-kernel flag when building glibc), it is quite important to include kernel headers of the initial build environment from 4 years ago when building the problematic m4 and the rest. We should carefully pay attention to this when devising our plan for building glibc.




>  11382  gcc  -I.   -I/BUILD/tmp_subp_zenodo5262698/software/installed/include  -Wno-nullability-completeness  -g -O2 -MT gl_linkedhash_list.o -MD -M
> P -MF $depbase.Tpo -c -o gl_linkedhash_list.o gl_linkedhash_list.c &&\
>  11383  mv -f $depbase.Tpo $depbase.Po
>  11384  depbase=`echo gl_list.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
>  11385  gcc  -I.   -I/BUILD/tmp_subp_zenodo5262698/software/installed/include  -Wno-nullability-completeness  -g -O2 -MT gl_list.o -MD -MP -MF $depb
> ase.Tpo -c -o gl_list.o gl_list.c &&\
>  11386  mv -f $depbase.Tpo $depbase.Po
>  11387  In file included from /usr/include/signal.h:328,
>  11388                   from ./signal.h:52,
>  11389                   from c-stack.c:49:
>  11390  c-stack.c:55:26: error: missing binary operator before token "("
>  11391     55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
>  11392        |                          ^~~~~~~~
>  11393  config.status: creating man/ncursesw6-config.1


Signal handling is a critical component of glibc to implement POSIX signal handling APIs. The problem here is related to the definition of `SIGSTKSZ` (default stack size for signal handlers).

In earlier versions of glibc, `SIGSTKSZ` was defined as a constant directly in signal.h. Starting from glibc 2.34, `SIGSTKSZ` became dynamic when certain macros like `_DYNAMIC_STACK_SIZE_SOURCE` or `_GNU_SOURCE` are defined. In these cases, `SIGSTKSZ` is redefined to call `sysconf(_SC_SIGSTKSZ)`[1,2]. This is probably why using new versions of m4 solved the problem as the new versions do not use the stack size constant.

Furthermore, Kernel headers provide the underlying definitions and constants that glibc relies on. For example, `SIGSTKSZ` might be defined in architecture-specific headers like bits/sigstksz.h or similar files. If the kernel headers are updated, the definition of `SIGSTKSZ` may change, affecting how glibc interprets or uses it [3].

To confirm, we should examine the existing signal.h as well as the kernel headers used during compilation to clarify how `SIGSTKSZ` is defined or overridden even if no errors are encountered during build.

[1] (https://stackoverflow.com/questions/69719688/buildroot-error-when-building-with-ubuntu-21-10)
[2] (https://stackoverflow.com/questions/74999961/c-error-missing-binary-operator-before-token)
[3] (https://github.com/DynamoRIO/dynamorio/issues/5434).


Mohammadreza Khellat <mkhellat>
Fri 21 Mar 2025 08:25:11 PM UTC, comment #15: 

comment #13:

> As this is among few core issues I find to be relevant to a reproducible software system, may I ask if you have any hunch as to which component(s) of glibc might have been responsible for the issue? I might be inclined towards POSIX APIs and system call wrappers as a first guess.


See points 1 + 2 of the commit description at [3]: the culprit appears to be /usr/include/signal.h . Here are some log excerpts:

building m4

 11382  gcc  -I.   -I/BUILD/tmp_subp_zenodo5262698/software/installed/include  -Wno-nullability-completeness  -g -O2 -MT gl_linkedhash_list.o -MD -M
P -MF $depbase.Tpo -c -o gl_linkedhash_list.o gl_linkedhash_list.c &&\
 11383  mv -f $depbase.Tpo $depbase.Po
 11384  depbase=`echo gl_list.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
 11385  gcc  -I.   -I/BUILD/tmp_subp_zenodo5262698/software/installed/include  -Wno-nullability-completeness  -g -O2 -MT gl_list.o -MD -MP -MF $depb
ase.Tpo -c -o gl_list.o gl_list.c &&\
 11386  mv -f $depbase.Tpo $depbase.Po
 11387  In file included from /usr/include/signal.h:328,
 11388                   from ./signal.h:52,
 11389                   from c-stack.c:49:
 11390  c-stack.c:55:26: error: missing binary operator before token "("
 11391     55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
 11392        |                          ^~~~~~~~
 11393  config.status: creating man/ncursesw6-config.1


Same for grep and diffutils :

 36001  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -I/BUILD/tmp_subp_zenodo5262698/software/installed/include -Wno-null
ability-completeness -O2 -pedantic -fomit-frame-pointer -m64 -c sqrtrem.c -o sqrtrem.o >/dev/null 2>&1
 36002  In file included from /usr/include/signal.h:328,
 36003                   from ./signal.h:52,
 36004                   from c-stack.c:49:
 36005  c-stack.c:55:26: error: missing binary operator before token "("
 36006     55 | #elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
 36007        |                          ^~~~~~~~
 36008  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -I/BUILD/tmp_subp_zenodo5262698/software/installed/include -Wno-nullability-completeness -O2 -pedantic -fomit-frame-pointer -m64 -c tdiv_qr.c  -fPIC -DPIC -o .libs/tdiv_qr.o
 36009  cc1: note: unrecognized command-line option '-Wno-nullability-completeness' may have been intended to silence earlier diagnostics


Point 3 listed at [3] is about gcc backwards incompatibility (-V and -qversion). I don't know if point 4, errors in building gcc-10.2.0 presumably related to changes in preprocessor directives, are GNU C Lib related. For convenience, I'll quote the log here:

4. The errors in building gcc 10.2.0 start with the following:

 37011  ../../../libiberty/objalloc.c: In function ‘objalloc_create’:
 37012  ../../../libiberty/objalloc.c:95:18: error: ‘PTR’ undeclared (first use in this function)
 37013     95 |   ret->chunks = (PTR) malloc (CHUNK_SIZE);
 37014        |                  ^~~
 37015  ../../../libiberty/objalloc.c:95:18: note: each undeclared identifier is reported only once for each function it appears in
 37016  ../../../libiberty/objalloc.c:95:22: error: expected ‘;’ before ‘malloc’
 37017     95 |   ret->chunks = (PTR) malloc (CHUNK_SIZE);
 37018        |                      ^~~~~~~
 37019        |                      ;
 37020  ../../../libiberty/objalloc.c: At top level:
 37021  ../../../libiberty/objalloc.c:114:1: error: unknown type name ‘PTR’
 37022    114 | PTR
 37023        | ^~~
 37024  ../../../libiberty/objalloc.c:115:1: error: conflicting types for ‘_objalloc_alloc’; have ‘int(struct objalloc *, long unsigned int)’
 37025    115 | _objalloc_alloc (struct objalloc *o, unsigned long original_len)
 37026        | ^~~~~~~~~~~~~~~
 37027  In file included from ../../../libiberty/objalloc.c:23:
 37028  ../../../libiberty/../include/objalloc.h:72:14: note: previous declaration of ‘_objalloc_alloc’ with type ‘void *(struct objalloc *, long unsigned int)’
 37029     72 | extern void *_objalloc_alloc (struct objalloc *, unsigned long);
 37030        |              ^~~~~~~~~~~~~~~


[3] https://codeberg.org/boud/subpoisson/commit/365a2e846757ce5f5a91877c79a0a0d880651610

Boud Roukema <boud>
Group Member
Fri 21 Mar 2025 07:45:25 PM UTC, comment #14: 

Thanks Boud! I agree with raising the priority of this task. Let's hope we can find the time to fully test and finish the work to merge the branch I made below (in Comment 5; the completeness percentage was already predicted to be 80% then!).

I am also happy to see that Mohammadreza is interested on this topic and I also know Giacomo has already started to look into this branch, so if we organize ourselves sufficiently well, the prospects for completing it are in the horizon ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 21 Mar 2025 07:17:09 PM UTC, comment #13: 

Hi Boud,

As this is among few core issues I find to be relevant to a reproducible software system, may I ask if you have any hunch as to which component(s) of glibc might have been responsible for the issue? I might be inclined towards POSIX APIs and system call wrappers as a first guess.

Mohammadreza Khellat <mkhellat>
Fri 21 Mar 2025 05:28:38 PM UTC, comment #12: 

I think that building the GNU C Library within Maneage should be High rather than Normal priority. I tried to reproduce [1] from the final Zenodo commit 086b149 - on the same physical machine, by the same author (me) - which is a paper published just four years ago. The only changes on the host system are regular Debian stable updates.

I firstly needed to do several hacks to bypass errors due to changes in the GNU C Library.

After that a few more hacks were needed to get a full configure, including a hack for gcc backwards incompatibility (easy to work around: -V and -qversion are obsolete options that caused fatal errors in the './configure' script) and I lack the time to fix bugs in the full 'analysis' side from a minimal-changes-only approach. Feel free to try branch 202503_reproduce that does an incomplete reproduction [2]. It would probably be simpler to update to the current main Maneage branch to try making a commit that could hopefully be reproduced in 2029.

In any case, building the GNU C library in Maneage would, hopefully, remove one source of rapid (4 years in this case) irreproducibility.

[1] "Anti-clustering in the national SARS-CoV-2 daily infection counts", 2021, PeerJ, 9:e11856, by B. F. Roukema - ArXiv:2007.1179 - doi:10.7717/peerj.11856 - doi:10.5281/zenodo.5262698

[2] https://codeberg.org/boud/subpoisson/src/branch/202503_reproduce

Boud Roukema <boud>
Group Member
Fri 15 Jul 2022 02:33:04 PM UTC, comment #11: 

I'm adding "(glibc)" to the task title to make it easier to find. :)

Boud Roukema <boud>
Group Member
Sun 30 Aug 2020 10:26:04 PM UTC, comment #10: 

Thanks for the explanation (reminder) Mohammad! :)

So installing gnulib as a separate package would be a low priority, I agree, since it's for package developers. So it is independent of the glibc task.

Pedantically, I see that gnulib is a package in Debian (literally speaking, it's built and installed independently) with just two executables: check-module and gnulib-tool.

The usage

gnulib-tool --import [module1 ... moduleN]

looks especially interesting for a package like cosmdist . That's now on my TODO list to try some time...

Of course,

 dpkg -L gnulib |wc
   9349    9349  411942

so you're right that the overwhelming bulk of gnulib is for choosing the particular source files (and creating the right sort of configure and Makefiles and so on) needed for a particular target package.

So this thread can return to glibc ... :)

Boud Roukema <boud>
Group Member
Thu 27 Aug 2020 08:59:07 PM UTC, comment #9: 

Thanks for bringing this up Boud. Gnulib is a very unique software: it isn't meant to be built (or installed!) independently.

Gnulib is meant to be included into the source of programs and compiled and built with the programs. I heavily rely on Gnulib in Gnuastro ;-)!

The basic idea behind Gnulib is that it contains a growing fraction of the GNU C Library components (and many more!) in a very portable manner (with internal checks for different OSs and hardware), classified as modules.

As a software author, you tell tell which modules you want in 'bootstrap.conf' (for example, see Gnuastro's 'bootstrap.conf'), and during the bootstrapping of your software (Gnulib actually gives you a 'bootstrap' script to put in your source), all the necessary Gnulib source files are copied into your project's source.

Only after bootstrapping is done do you run Autoconf and Automake to generate the './configure' and 'Makefile.in' files. Gnulib's modules have their own './configure' stage tests. In the case of Gnuastro, +95% of the configure-time tests are those of Gnulib! Then, when the user runs 'make', Gnulib will compile as a static/internal library before your program's source, and thus static-links to (gets copied inside) your library/executables. In the case of Gnuastro, its in the 'libgnuastro.so' library, which all the programs then link with dynamically.

The great result is that the software actually has all the requested components of the GNU C Library in its own source and it uses them!

So for example even when you compile Gnuastro on a macOS, it actually uses its own GNU C Library that is compiled on with it, and can provide an identical/reproducible behavior and output :-).

This is the reason that I mentioned it in the discussion of the Maneage paper: it helps so much in reproducibility and helps the software authors so much (they can rely on GNU C Library even on systems that don't have it!).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 27 Aug 2020 08:05:45 PM UTC, comment #8: 

Should gnulib be a separate task to this one on glibc?


My understanding is that if we install glibc in maneage, then there would be no point in installing gnulib .

In that case, installing gnulib would only make sense if it were an easy alternative to glibc , either because it's lightweight (the source is about 62Mb for me, which is not so lightweight) or because it's easier to compile and install or is more portable than glibc.

Would there be any sense in temporarily installing gnulib either in basic.mk (since many things depend on it) or high-level-mk as an opt-in option in Maneage?

Boud Roukema <boud>
Group Member
Mon 11 May 2020 08:33:50 PM UTC, comment #7: 

Since the we started the gitlab.com/maneage group, I am maintaining my development branches there and the old repository in the links before has been deleted.

The development branch `glibc' that is discussed in the comments below is now available under the project-dev repository of that group.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 13 Nov 2019 02:33:34 PM UTC, comment #6: 

In the previous comment, the last link (to a specific commit) was incorrect. Here is the correct link: https://gitlab.com/makhlaghi/reproducible-paper/commit/8340cac356c354

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 13 Nov 2019 12:54:19 PM UTC, comment #5: 

Thanks to the wonderful guidelines of Linux from scratch (LFS), I made some good progress in this task in the last few days (in my fork's glibc branch). It now builds a temporary GNU Binutils, GNU GCC, and GNU C Library with fixed/known versions.

It wasn't as easy as just copying and pasting from LFS because LFS assumes root privileges and in some parts this caused problems for our scenario. But I am happy that we can now build programs were we even control the C library. For example see this (checking the linked libraries with a tiny "hello world" program (notice how `libc.6.so' and `ld-linux-x86-64.so.2' are in the template's build directory, not the host system's):


$ ldd a.out
        linux-vdso.so.1 (0x00007ffd9a3be000)
        libc.so.6 => /template/build/dir/software/installed-round-2/lib/libc.so.6 (0x00007fda87f2a000)
        /template/build/dir/software/installed-round-2/lib64/ld-linux-x86-64.so.2 (0x00007fda880ea000)


But the job is not finshed yet! Because the currently built GCC was built before GNU C Library, so it still needs the host's C library. We should now build a new GCC and GNU Binutils from the template's C library so they can be fully independent of the host system.

The last commit so far in my `glibc' branch now goes all the way to the second GNU Binutils build and was tested on three different GNU/Linux systems (two of them large/remote computers) and works perfectly on all three.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 08 Nov 2019 03:39:09 AM UTC, comment #4: 

Sorry, the conflict between glibc and GMP happens when `gmp.h' is in glibc's include-path (not its installation path as I mentioned before).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 08 Nov 2019 03:28:42 AM UTC, comment #3: 

The previous problem was fixed by removing MPFR (which depends GMP) as a dependency of the AWK that is built for glibc. Apparently glibc has a conflict with GMP if its in it's installation path.

On this branch glibc now builds on my GNU/linux system, but while building the higher-level `basic.mk' programs I noticed two problems that still need to be fixed:

1. Many programs (like `gzip' and `tar' that were checked), need patchelf to actually link with our internal C library.

2. There was a compilation error while building `ncurses' with C++ because of the new C library.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 06 Nov 2019 09:23:38 PM UTC, comment #2: 

I forgot to mention that I am doing this work on the glibc branch of my fork of the project on Gitlab.

Also, as described in a more recent commit on that branch, the quoted error message below is from `glibc-2.30.9000-235-g807edded25' (tarball created with the most recent commit), I was just using it to confirm if this problem may have been fixed since the 2.30 release.

But as the error message shows, it still occurred in that tarball to. So probably, its an internal setting of the template that is causing it.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 06 Nov 2019 09:13:41 PM UTC, comment #1: 

Work on this task has officially started. From the commit message:
"""
A separate Makefile (`glibc.mk') was added to the pipeline with the sole purpose of building the GNU C Library on GNU/Linux systems. When the host is a GNU/Linux operating system, the `configure.sh' script will first call this Makefile before calling `basic.mk'.

In `glibc.mk', all the GNU C Library dependencies are defined and installed in a separate directory structure under `$(BDIR)/software/installed-for-glibc'. They will just be used to build the GNU C Library. Only the GNU C Library will be installed in the standard place under `$(BDIR)/software/installed'.

After the GNU C Library is installed, `configure.sh' goes to the standard `basic.mk' and builds everything as before, but this time, because they have access to our build of the GNU C Library, they will link to it, not to the host's C library.

Everything goes nicely except close to the start of the build of glibc, I get an error about `__GMP_CAST' in the installed `gmp.h'. So I am not yet merging this branch into master.
"""

The full error message is this:


gcc -B/build-dir/software/installed-for-glibc/bin/ ../sysdeps/ieee754/float128/float1282mpn.c -c -std=gnu11 -fgnu89-inline  -g -O2 -Wall -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math -fstack-protector-strong -Wstrict-prototypes -Wold-style-definition -fmath-errno   -fpie -fcf-protection   -ftls-model=initial-exec    -I/build-dir/software/installed-for-glibc/include   -I../include -I/build-dir/software/build-tmp/glibc-2.30.9000-235-g807edded25/glibc-build/stdlib  -I/build-dir/software/build-tmp/glibc-2.30.9000-235-g807edded25/glibc-build  -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/x86/nptl  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86  -I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.  -D_LIBC_REENTRANT -include /build-dir/software/build-tmp/glibc-2.30.9000-235-g807edded25/glibc-build/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC     -DTOP_NAMESPACE=glibc -o /build-dir/software/build-tmp/glibc-2.30.9000-235-g807edded25/glibc-build/stdlib/float1282mpn.o -MD -MP -MF /build-dir/software/build-tmp/glibc-2.30.9000-235-g807edded25/glibc-build/stdlib/float1282mpn.o.dt -MT /build-dir/software/build-tmp/glibc-2.30.9000-235-g807edded25/glibc-build/stdlib/float1282mpn.o
In file included from divmod_1.c:27:
/build-dir/software/installed-for-glibc/include/gmp.h:322:33: error: expected declaration specifiers or '...' before '(' token
  322 | #define __GMP_CAST(type, expr)  ((type) (expr))
      |                                 ^
/build-dir/software/installed-for-glibc/include/gmp.h:1495:21: note: in expansion of macro '__GMP_CAST'
 1495 |   mpn_divrem_1 (qp, __GMP_CAST (mp_size_t, 0), np, nsize, dlimb)
      |                     ^~~~~~~~~~
divmod_1.c:43:1: note: in expansion of macro 'mpn_divmod_1'
   43 | mpn_divmod_1 (mp_ptr quot_ptr,
      | ^~~~~~~~~~~~
make[3]: *** [../o-iterator.mk;9: /build-dir/software/build-tmp/glibc-2.30.9000-235-g807edded25/glibc-build/stdlib/divmod_1.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/dev/shm/reproducible-paper-template/glibc-2.30.9000-235-g807edded25/stdlib'
make[2]: *** [Makefile;438: stdlib/subdir_lib] Error 2
make[2]: Leaving directory '/dev/shm/reproducible-paper-template/glibc-2.30.9000-235-g807edded25'
make[1]: *** [Makefile;12: install] Error 2
make[1]: Leaving directory '/dev/shm/reproducible-paper-template/glibc-2.30.9000-235-g807edded25/glibc-build'
make: *** [reproduce/software/make/glibc.mk:447: /build-dir/software/installed-for-glibc/version-info/proglib/glibc] Error 2


However, this same tarball built successfully on my system from scrach with no problem. When I compared the `gmp.h' of the template (top) and the one on my system (bottom), I got this:


#define __GMP_CFLAGS "-O2 -pedantic -fomit-frame-pointer -m64"
#define __GMP_CFLAGS "-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt"


But even after adding `-mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' to CFLAGS while compiling GMP, I still got the same error.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 15 Sep 2019 01:00:52 PM UTC, original submission:  

On systems that support it (not including macOS systems for example!), a much better level of control/reproducibility can be achieved if we also have a fixed version of the GNU C library.

Installing the GNU C Library itself doesn't take too long. We'll just need some bootstrapping first: build some basic necessary tools to build GNU C library, then delete all of those basic tools and re-build them with our own GNU C Library.

Mohammad Akhlaghi <makhlaghi>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mkhellat (Posted a comment)
  • -email is unavailable- added by boud (Posted a comment)
  • -email is unavailable- added by makhlaghi (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-03-21 boud Priority5 - Normal 7 - High
    2024-09-16 boud Dependencies- bugs #66223 is dependent
    2022-07-15 boud SummaryInstalling GNU C Library within project Installing GNU C Library within project (glibc)
    2019-11-13 makhlaghi Percent Complete70% 80%
    2019-11-08 makhlaghi Assigned toNone makhlaghi
    2019-11-08 makhlaghi Percent Complete50% 70%
    2019-11-06 makhlaghi Percent Complete0% 50%

    Back to the top

    Powered by Savane 3.15-26b0.
    Corresponding source code