Created attachment 185137 [details] Patch
Please confirm this passes QA (poudriere) and in particular that an existing consumer/dependent port does not regress at link/runtime
I'm not aware of any z3 users in ports tree, except security/klee ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219150 ). I confirm that this patch solves qa problem from that PR. QA for z3 with this patch also passes.
Bump.
Patch is malformed, please re-generate.
Created attachment 185536 [details] Patch Right, it got reversed somehow.
(In reply to arrowd from comment #5) Hmm, still doesn't apply for me.
(In reply to Steve Wills from comment #6) Strange, this is what `svn diff` gives me. Can you please show how you apply the patch and what it says?
(In reply to arrowd from comment #7) $ patch -p2 < attachment.cgi\?id=185536 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: math/z3/files/patch-scripts_mk__util.py |=================================================================== |--- math/z3/files/patch-scripts_mk__util.py (revision 447066) |+++ math/z3/files/patch-scripts_mk__util.py (working copy) -------------------------- Patching file files/patch-scripts_mk__util.py using Plan A... Hunk #1 failed at 14. 1 out of 1 hunks failed--saving rejects to files/patch-scripts_mk__util.py.rej done
Strange, it does apply to me. Ok, here are the contents of files/patch-scripts_mk__util.py --- scripts/mk_util.py.orig 2016-11-07 22:02:30 UTC +++ scripts/mk_util.py @@ -49,7 +49,7 @@ C_COMPILERS=['gcc', 'clang'] CSC_COMPILERS=['csc', 'mcs'] JAVAC=None JAR=None -PYTHON_PACKAGE_DIR=distutils.sysconfig.get_python_lib() +PYTHON_PACKAGE_DIR=distutils.sysconfig.get_python_lib(prefix=getenv("PREFIX", None)) BUILD_DIR='build' REV_BUILD_DIR='..' SRC_DIR='src' @@ -2391,7 +2391,7 @@ def mk_config(): check_ar() CXX = find_cxx_compiler() CC = find_c_compiler() - SLIBEXTRAFLAGS = '' + SLIBEXTRAFLAGS = '%s -Wl,-soname,libz3.so.0' % LDFLAGS if GPROF: CXXFLAGS = '%s -pg' % CXXFLAGS LDFLAGS = '%s -pg' % LDFLAGS Just copy it over existing file.
Bump-bump.
The soname should probably be related to the version of the software, like the major version number, 4 in this case.
(In reply to Mathieu Arnold from comment #11) This looks much like bikeshedding. I chose 0 because this is sort of "default" value when upstream doesn't even care about soname versioning. What if they decide to add it and start versioning with 0? Then our 4 would be "newer" that their "0".
It looks like this is _eventually_ going to make it upstream. https://github.com/Z3Prover/z3/pull/739
For reference, from the linked pull request it looks upstream is using .so.<major>.<minor> As a practical matter I don't think it much matters if we choose .so.0 and upstream's next update uses (e.g.) .so.4.4 or if we choose .so.4 and the future update uses .so.4.4.
A commit references this bug: Author: jrm Date: Tue Sep 5 15:26:55 UTC 2017 New revision: 449291 URL: https://svnweb.freebsd.org/changeset/ports/449291 Log: math/z3: Patch to add SONAME to shared library Also ensure that python is available at build time when the PYTHON option (for python bindings) is off. PR: 221321 Submitted by: 6yearold@gmail.com (maintainer) Changes: head/math/z3/Makefile head/math/z3/files/patch-scripts_mk__util.py
Shouldn't we add a symlink from libz3.so.0 to libz3.so ?
(In reply to Alex Dupre from comment #16) Yep, I've addressed this there: https://reviews.freebsd.org/D13637