[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Reproduce-devel] [bug #56691] confusing information about libc.a and De
[Reproduce-devel] [bug #56691] confusing information about libc.a and Debian
Sun, 28 Jul 2019 21:44:24 -0400 (EDT)
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Follow-up Comment #1, bug #56691 (project reproduce):
Thanks a lot for the great report.
Let me just address the comment about tarball downloading first: We have a
backup tarball repository
<https://gitlab.com/makhlaghi/reproducible-paper-dependencies> containing all
the tarballs that the template currently needs.
When a software's server is in-accessible for any reason, you can use this
repository to download the tarball manually and put it in
`.build/software/tarballs'. Or, you can just clone the whole tarball
repository once and use it for all your projects. You can then give the
absolute address of the local tarball repository to the `--software-dir'
option of `./project configure' and the project will not need to download
tarballs any more.
I have been thinking of automatically using our backup tarball repository when
a tarball URL isn't accessible, so to make it formal, I just defined task
Let's get back to the main issue: the two proposed solutions were based on
what we tried with two different Debian-based systems (one was Ubuntu, I can't
remember the other one). Both are indeed an ugly solution (the user should not
have to do anything as root).
As you pointed out so nicely, they are not generic and vary from one OS to
another (but so far, we have only seen this problem in building GCC from
source on Debian-based OSs). Other OSs we've tested don't have this problem.
But this is very strange for me: why is it so hard to build GCC on
Debian-based OSs? Since you are using Debian, not any of its derivaties, can
you please try the following:
Make no change to your original system, and just ignore this test by setting
`host_cc=0' in line 937 of configure.sh
(right after the block of code that prints this warning, ending in `fi'). Will
you have a problem with building GCC?
Unfortunately I am not a Debian-based user myself, so it has always been very
hard for me to find a generic solution to this problem. But since you are very
familiar with Debian, maybe with your help we'll be able to fix this annoying
problem for Debian-based users.
Just in case you are interested, the Make rule to build GCC is in the end of
But anyway, let's get back to the two hacks that you tried.
For the first one (regarding `crti.o' and `crtn.o'), I came up with this
interesting suggestion: to set `LIBRARY_PATH'. If the `libc.a' file is in the
same directory, this might even fix this whole problem. Can you please try it
when you get the chance?
I am not sure about the second one, let's try the possible solution above
first, then see if the second problem still happens or not.
Reply to this item at:
Message sent via Savannah