Opened 6 years ago
Closed 5 years ago
#76 closed defect (fixed)
Divcc produces a broken gzip
Reported by: | Lukáš Zaoral | Owned by: | blurrymoi |
---|---|---|---|
Priority: | major | Milestone: | 4.3 |
Component: | divcc | Keywords: | |
Cc: | kdudka@…, jamartis@…, lzaoral@… |
Description
I've tried to test the gzip
binary compiled by divcc
from the 4.3.4 release and I have encountered the following problems:
1) Configure fails at the "checking whether we are cross compiling" step if the 32-bit system headers are not present on a 64-bit system.
2) A comment in #52 mentions, that "gzip-1.8-divine.diff
is no longer required with recent versions of divine". However, I wasn't able to compile the 1.8 release of gzip
without the patch applied to the fseeko.c
and fseterr.c
files.
3) The make check
target of gzip
fails regardless of a release (1.8, 1.10) or a level of optimization used (0-2). The error messages between these configurations differ, but are consistent regardless of used Linux distro (Fedora 30, Manjaro and Debian 10).
If the dioscc
compiler is used, none of these problems arise and all gzip
tests pass with all mentioned releases and optimization flags.
Change History (5)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
As for 1), a config.log
would be useful. I get the same problem on openbsd (but not on archlinux). For me, the failure is as follows:
configure:4702: checking whether we are cross compiling configure:4712: divcc -o conftest conftest.c >&5 failed to link, ld exited with exitcode = 1, signal = 0 stderr: ld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in conftest.divcc.8458.o >>> referenced by conftest.c:15 >>> conftest.divcc.8458.o:(main) ld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in conftest.divcc.8458.o >>> referenced by conftest.c:15 >>> conftest.divcc.8458.o:(main) ld: error: can't create dynamic relocation R_X86_64_32S against symbol: __isthreaded in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /usr/lib/libc.so.95.1 >>> referenced by conftest.c:16 >>> conftest.divcc.8458.o:(main) configure:4716: $? = 1 configure:4723: ./conftest ./configure: ./conftest: not found
comment:3 Changed 6 years ago by
The failures in config.log
s are following:
- Fedora 30:
configure:4905: checking whether we are cross compiling configure:4915: divcc -o conftest conftest.c >&5 In file included from conftest.c:11: In file included from /usr/include/stdio.h:27: In file included from /usr/include/bits/libc-header-start.h:33: In file included from /usr/include/features.h:474: /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found # include <gnu/stubs-32.h> ^~~~~~~~~~~~~~~~ 1 error generated. Error building conftest.c configure:4919: $? = 1 configure:4926: ./conftest ./configure: line 4928: ./conftest: No such file or directory
- Debian 10:
configure:4911: checking whether we are cross compiling configure:4921: divcc -o conftest conftest.c >&5 In file included from conftest.c:11: /usr/include/stdio.h:27:10: fatal error: 'bits/libc-header-start.h' file not found #include <bits/libc-header-start.h> ^~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Error building conftest.c configure:4925: $? = 1 configure:4932: ./conftest ./configure: 1: eval: ./conftest: not found
comment:4 Changed 6 years ago by
I have done some testing and even though the following code is compiled into a 64-bit binary using either divcc
or dioscc
, the __x86_64__
macro is not implicitly defined. Therefore, the 32-bit header files might be used as in the case above.
#include <stdio.h> int main(void) { puts("Architecture: "); #ifdef __x86_64__ puts("x86_64"); #else puts("i686"); #endif }
comment:5 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
These should now all be resolved in next
(or otherwise explained as in the case of gzip-1.8). If any of the issues persist, please file a new issue. Thank you for reporting and diagnostics.
Regarding point 2), gzip-1.8 simply fails to build on recent glibc-based systems, regardless of the compiler. You can double-check (in a clean tree) with just ./configure && make. (In the future, it might be better to report separate issues separately.)