[Bug libbacktrace/87182] libbacktrace does not use GCC own zlib

2018-09-04 Thread vigerske at math dot hu-berlin.de
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

2018-09-03 Thread ian at airs dot com
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

2018-09-03 Thread vigerske at math dot hu-berlin.de
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

2018-09-03 Thread ian at airs dot com
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

2018-09-03 Thread joseph at codesourcery dot com
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

2018-09-03 Thread rguenth at gcc dot gnu.org
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.