[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 Stefan Vigerske changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Stefan Vigerske --- Hmm, I think you are right! With GCC 8.2.0, which I'm using, there still was AC_CHECK_LIB([z], [compress], []). The empty [] in the third argument does not seem to have the desired effect of suppressing the addition of -lz to LIBS. It is still there: https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure?revision=259610=markup#l12945 With revision 263320 from August 5, the third argument of AC_CHECK_LIB is nontrivial and then -lz is not appended to LIBS anymore: https://gcc.gnu.org/viewcvs/gcc/trunk/libbacktrace/configure?r1=259610=263320 Sorry, I didn't realize this behavior of AC_CHECK_LIBS, but the documentation also says clearly that augmenting LIBS is only the default behavior if not overwritten. Then everything should be fine with the next GCC release.
[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 --- Comment #6 from Ian Lance Taylor --- In my testing I don't see any reference to -lz in libbacktrace.la. It is not the case that using AC_CHECK_LIB([z], [compress], [AC_DEFINE(HAVE_ZLIB, 1, [Define if -lz is available.])]) in libbacktrace/configure.ac causes -lz to be added to LIBS. This happens temporarily during the configure script, but the assignment to LIBS is undone. It is not reflected in the generated Makefile. So while I'm certainly willing to fix this, I can't recreate the problem and I don't understand the problem. Can you explain further? Thanks.
[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 --- Comment #5 from Stefan Vigerske --- The AC_CHECK_LIB([z], [compress], []) adds -lz to the LIBS variable in the Makefile, if successful. This results in calling the libtool that builds libbacktrace.la with -lz, which then results in having dependency_libs=' -lz' in libbacktrace.la. The build of libgfortran(.so) picks this up, so that the systems libz.so ends up as dependency of libgfortran.so. If libbacktrace itself does not require zlib, then maybe -lz should not end up in LIBS. I don't know what the preferred way to handle this is. One way is to save LIBS before calling AC_CHECK_LIB and to restore it again afterwards. However, the test executable would still need -lz.
[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #4 from Ian Lance Taylor --- Note that zlib is only used for the test programs, not for libbacktrace itself. Are you sure that libgfortran is picking up a dependency on zlib? If that is coming from libbacktrace, then something else is going wrong.
[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 --- Comment #3 from joseph at codesourcery dot com --- Host libbacktrace would need to use GCC's host zlib and target libbacktrace would need to use GCC's target zlib for the same target multilib (which would require appropriate dependencies to be added to cause a target zlib to be built; I think it used to be built for GCJ, but I don't see any current dependencies that would result in it being built).
[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87182 Richard Biener changed: What|Removed |Added Component|libfortran |libbacktrace --- Comment #2 from Richard Biener --- Now we do.