Opened 4 years ago
Closed 4 years ago
#60904 closed enhancement (fixed)
ncplot @2020-02-21_1: Overlinking
Reported by: | Dave-Allured (Dave Allured) | Owned by: | mf2k (Frank Schima) |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | ncplot |
Description
Please remove port:zlib
from depends_lib
. This is only an indirect dependency through port netcdf. Also remove -lz
from the makefile patch. Thanks.
Change History (7)
comment:1 Changed 4 years ago by mf2k (Frank Schima)
comment:2 Changed 4 years ago by Dave-Allured (Dave Allured)
That Makefile appeared to be somewhat old and unrefined, so I was suspicious. I checked the code two different ways for zlib dependency. I could not find any recognizable references to zlib headers or functions. Also I tried omitting -lz
from the link command, and that gave a working executable with no complaints.
I suspect that in your case, -lz
was in your linker formula via the makefile patch, before checking the result with otool
. My guess is that this forces /opt/local/lib/libz.*.dylib
to be visible, regardless of whether the application actually has any direct reference. You might try omitting -lz
and see if you get a good executable.
My test setup is a little different than yours. I am working with a down level Macports setup, thanks in part to Covid. I am compiling ncplot
stand-alone rather than with port install
. I do not see how any of that would make a difference for this particular dependency, but I suppose it is possible.
~/3rd/ncplot/0725 32> otool -L ncplot ncplot: /opt/local/lib/libXm.4.dylib (compatibility version 5.0.0, current version 5.4.0) /opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/local/lib/libnetcdf.15.dylib (compatibility version 15.0.0, current version 15.0.0) /opt/local/lib/libgsl.23.dylib (compatibility version 25.0.0, current version 25.0.0) /opt/local/lib/libpng16.16.dylib (compatibility version 53.0.0, current version 53.0.0) /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.25.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1) /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
comment:3 Changed 4 years ago by mf2k (Frank Schima)
Yes, the Makefile is very primitive. You have to uncomment for a MacOS install, hence the patch. That's where the -lz
comes from. If you happen to be in contact with the upstream developer, who works for NCAR, maybe you can ask him about it?
comment:4 Changed 4 years ago by Dave-Allured (Dave Allured)
Question filed upstream: https://github.com/NCAR/ncplot/issues/5
comment:5 Changed 4 years ago by Dave-Allured (Dave Allured)
The reply was: "zlib was originally included because libpng required it. -lm and -lz removed." Please see the above reference for full context.
The upstream Makefile was updated. For Macports, I assume that zlib
would be an indirect dependency through any version of libpng
that needed it. Therefore I believe zlib
should be removed as a direct dependency of ncplot
.
Best practice for -lm
is a mystery to me. There certainly are tons of math calls within ncplot
.
comment:6 Changed 4 years ago by mf2k (Frank Schima)
Great, thank you. I have updated the port. I will wait a bit before committing to see if I can get it to use gmt first.
comment:7 Changed 4 years ago by mf2k (Frank Schima)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I don't understand this request. Currently 990 ports depend on zlib, so this is hardly uncommon. Also, the Makefile is from upstream. Why should that change?
I added the dependency on it because
otool -L
shows it as linking directly with it.