December 2015 - macports-tickets - lists.macosforge.org

[MacPorts] #49987: Invalid install_name for shared library
by MacPorts 12 Dec '15

12 Dec '15

#49987: Invalid install_name for shared library -----------------------------------+-------------------------------- Reporter: alexander.afanasyev@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: libcryptopp -----------------------------------+-------------------------------- This error was fixed before update to 5.6.3 and now it back again. The shared library is compiled with install_path="libcryptopp.dylib" parameter, which causes dependent applications or library to fail with {{{ dyld: Library not loaded: libcryptopp.dylib Referenced from: /some/path/app Reason: image not found }}} Until this issue fixed upstream, I suggest a similar patch to https://trac.macports.org/browser/trunk/dports/devel/libcryptopp/Portfile?r… The patch could be simpler: change in GNUMakefile install_path to "$(PREFIX)/lib/$@": {{{ diff --git a/GNUmakefile b/GNUmakefile index d2f5404..1bef87e 100755 --- a/GNUmakefile +++ b/GNUmakefile @@ -388,7 +388,7 @@ libcryptopp.so: public_service | $(LIBOBJS) $(CXX) -shared -o $@ $(CXXFLAGS) $(GOLD_OPTION) $(LIBOBJS) $(LDLIBS) libcryptopp.dylib: $(LIBOBJS) - $(CXX) -dynamiclib -o $@ $(CXXFLAGS) -install_name "$@" -current_version "$(LIB_MAJOR).$(LIB_MINOR).$(LIB_PATCH)" -compatibility_version "$(LIB_MAJOR).$(LIB_MINOR)" $(LIBOBJS) + $(CXX) -dynamiclib -o $@ $(CXXFLAGS) -install_name "$(PREFIX)/lib/$@" -current_version "$(LIB_MAJOR).$(LIB_MINOR).$(LIB_PATCH)" -compatibility_version "$(LIB_MAJOR).$(LIB_MINOR)" $(LIBOBJS) cryptest.exe: public_service | libcryptopp.a $(TESTOBJS) $(CXX) -o $@ $(CXXFLAGS) $(TESTOBJS) ./libcryptopp.a $(LDFLAGS) $(GOLD_OPTION) $(LDLIBS) }}} -- Ticket URL: <https://trac.macports.org/ticket/49987> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

Re: [MacPorts] #43009: [update] net-snmp 5.7.2.1 + improvements
by MacPorts 12 Dec '15

12 Dec '15

#43009: [update] net-snmp 5.7.2.1 + improvements ------------------------+-------------------------- Reporter: jul_bsd@… | Owner: ryandesign@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: net-snmp | ------------------------+-------------------------- Comment (by ryandesign@…): Replying to [comment:16 jul_bsd@…]: > {{{ > Mar 12 19:09:44 HOST com.apple.xpc.launchd[1] (org.macports.net-snmp): The Debug key is no longer respected. Please remove it. > }}} > Debug is not a setting of Portfile AFAIK That's a bug in MacPorts base. I filed #49990 for this. -- Ticket URL: <https://trac.macports.org/ticket/43009#comment:17> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49990: The Debug key is no longer respected. Please remove it.
by MacPorts 12 Dec '15

12 Dec '15

#49990: The Debug key is no longer respected. Please remove it. --------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Keywords: | Port: --------------------------+-------------------------------- portstartupitem.tcl puts {{{ <key>Debug</key><false/> }}} into launchd plists. On Yosemite and later, loading such a plist produces this message from the OS: {{{ The Debug key is no longer respected. Please remove it. }}} We should either unconditionally remove this key, or else if it serves a purpose on older systems, conditionally insert it on those older systems. -- Ticket URL: <https://trac.macports.org/ticket/49990> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #40700: nedi @1.0.7_3: ln: ./org.macports.nedisyslog.plist: Operation not permitted
by MacPorts 12 Dec '15

12 Dec '15

#40700: nedi @1.0.7_3: ln: ./org.macports.nedisyslog.plist: Operation not permitted -----------------------------+-------------------------------- Reporter: Peter.Stange@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: fixed | Keywords: Port: nedi | -----------------------------+-------------------------------- Comment (by ryandesign@…): You didn't add a pre-activate block to clean up the formerly directly- installed org.macports.nedisyslog.plist, which causes activation failures. See #49989. -- Ticket URL: <https://trac.macports.org/ticket/40700#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49986: osxfuse installation aborts on the latest Xcode compiler
by MacPorts 12 Dec '15

12 Dec '15

#49986: osxfuse installation aborts on the latest Xcode compiler --------------------+-------------------------------- Reporter: uri@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: osxfuse --------------------+-------------------------------- Attempts to install osxfuse fail on El Capitan 10.11.2 with Xcode-7.2. Attached is the complete log, but this excerpt seems clear enough: debug:main OS darwin/15.2.0 (Mac OS X 10.11) arch i386 :debug:main Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl :debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync....skipping... am.h >@ file10 2>@stderr :debug:patch euid/egid changed to: 0/0 :debug:patch chowned /opt/local/var/macports/build/_opt_local_var_macports_sources_r sync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work /osxfuse-osxfuse-b f71481/kext/common/fuse_param.h to macports :debug:patch euid/egid changed to: 503/501 :debug:patch euid/egid changed to: 0/0 :debug:patch setting attributes on /opt/local/var/macports/build/_opt_local_var_macp orts_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work/osx fuse-osxfuse-bf71481/kext/common/fuse_param.h :debug:patch euid/egid changed to: 503/501 :debug:patch Privilege de-escalation not attempted as not running as root. :debug:configure configure phase started at Fri Dec 11 18:13:12 EST 2015 :notice:configure ---> Configuring osxfuse :debug:configure Using compiler 'Xcode Clang' :debug:configure Executing org.macports.configure (osxfuse) :debug:configure Privilege de-escalation not attempted as not running as root. :debug:build build phase started at Fri Dec 11 18:13:12 EST 2015 :notice:build ---> Building osxfuse :debug:build Executing org.macports.build (osxfuse) :debug:build Environment: CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources _rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work/.CC_PRINT_OPTIO NS' CPATH='/opt/local/include' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.11' :debug:build Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_ma cports_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work/o sxfuse-osxfuse-bf71481" && ./build.sh -t homebrew -f /opt/local' :debug:build Executing command line: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_fuse_osxfuse/osxfuse/work /osxfuse-osxfuse-bf71481" && ./build.sh -t homebrew -f /opt/local :info:build OSXFUSEBuildTool() : skip unsupported Xcode version in '/Applications/Xcode.app/Contents/Developer'. :info:build OSXFUSEBuildTool() failed: no supported version of Xcode found. Plus, it seems to ignore the architecture requirement (in my system "build_arch" is set to x86_64) and seems to want to build for i386? Or maybe I'm misinterpreting that "i386" appearing above?. -- Ticket URL: <https://trac.macports.org/ticket/49986> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #46642: apple-gcc42 @5666.3_14 +bootstrap on Tiger PPC fails to build
by MacPorts 12 Dec '15

12 Dec '15

#46642: apple-gcc42 @5666.3_14 +bootstrap on Tiger PPC fails to build -------------------------------+-------------------------------- Reporter: snipsnipsnip@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: apple-gcc42 tiger | Port: apple-gcc42 -------------------------------+-------------------------------- Hi, I noticed that building the port apple-gcc42+bootstrap on Tiger PPC fails with message like `/CoreOS/Standard/Standard.make: No such file or directory`. {{{ $ sudo port clean apple-gcc42 $ sudo port -v install apple-gcc42 +bootstrap ... fetch and patch ... ---> Configuring apple-gcc42 ---> Building apple-gcc42 make: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/gcc-5666.3' GNUmakefile:16: /CoreOS/Standard/Standard.make: No such file or directory make: *** No rule to make target `/CoreOS/Standard/Standard.make'. Stop. }}} Relevant lines in the `GNUmakefile` are: {{{ ifndef CoreOSMakefiles CoreOSMakefiles = $(MAKEFILEPATH)/CoreOS endif include $(CoreOSMakefiles)/Standard/Standard.make }}} It seems that both `$(CoreOSMakefiles)` and `$(MAKEFILEPATH)` hasn't been set on my Mac, making `$(CoreOSMakefiles)` to be `/CoreOS`. I added `CoreOSMakefiles="/Developer/Makefiles/CoreOS"` to `build.args` then built successfully. Not sure if this is the right way, nor if the problem is only for me, but I attach a patch for information: {{{ --- Portfile.orig 2015-01-21 16:14:53.000000000 +0900 +++ Portfile 2015-01-21 16:38:15.000000000 +0900 @@ -231,6 +231,8 @@ error "Please install this port without the bootstrap variant." } } else { + build.args-append \ + CoreOSMakefiles="/Developer/Makefiles/CoreOS" notes-append " Now please reinstall ${name} without the bootstrap variant by running: }}} -- Ticket URL: <https://trac.macports.org/ticket/46642> MacPorts <https://www.macports.org/> Ports system for OS X

1 15

[MacPorts] #49595: [KDE4]: move headerfiles to a dedicated TLD
by MacPorts 12 Dec '15

12 Dec '15

#49595: [KDE4]: move headerfiles to a dedicated TLD -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: kdelibs4 -------------------------+-------------------------------- As already mentioned on macports-dev, it turns out to be preferable to store the KDE4 headerfiles under a prefix directory where there is less chance they'll clash with KF5 headerfiles. Otherwise, conflicts will arise when building KF5 frameworks or applications (I've already witnessed such conflicts that were resolved by the attached fix, which is why I label this ticket a defect). The attached patchfile accomplishes that. It defines the new path, `${prefix}/include/KDE4` in the KDE4 PortGroup, and applies it the kdelibs4 Portfile. For the (presumable vast) majority of dependent ports this is all that is required, as kdelibs4 installs cmake scripts that will set the new include path. There are a few exceptions like Phonon and Attica, but as far as I can tell now they will not lead to clashes so their headers can remain where they are now. I was afraid that all dependent ports might require a revbump because of this, but it turns out that that is not strictly required. The current patch does '''''not''''' cause binary incompatibilities, and the change to the header search path in the cmake scripts does not cause errors finding headers in their old locations. That change only ensures that the headers can be found in their new location. (Ex: I could rebuild `port:kdenlive` without having to rebuild `port:kde4-runtime` first, and `port:nepomuk- widgets` without having to rebuild `port:nepomuk-core` first.) -- Ticket URL: <https://trac.macports.org/ticket/49595> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #49548: kde4-workspace, libgpod, libqalculate: More revbumps needed
by MacPorts 11 Dec '15

11 Dec '15

#49548: kde4-workspace, libgpod, libqalculate: More revbumps needed --------------------+--------------------------------------------------- Reporter: mk@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: kde4-workspace, libgpod, libqalculate --------------------+--------------------------------------------------- Very likely due to the recent {{{qt4-mac}}} update also these ports need a revbump: {{{ libgpod @0.8.3 +python27 libqalculate @0.9.7 kde4-workspace @4.14.4.20150324 +oxygen }}} -- Ticket URL: <https://trac.macports.org/ticket/49548> MacPorts <https://www.macports.org/> Ports system for OS X

1 42

[MacPorts] #49187: ceres-solver CeresConfig.cmake requires eigen3@3.2.2 instead of @3.2.5
by MacPorts 11 Dec '15

11 Dec '15

#49187: ceres-solver CeresConfig.cmake requires eigen3(a)3.2.2 instead of @3.2.5 -----------------------+-------------------------------- Reporter: cignoni@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: -----------------------+-------------------------------- for the port ceres-solver the corresponding CeresConfig.cmake specifies that it requires eigen3(a)3.2.2 but if you have the current eigen3 @3.2.5 it fails to satisfy the requirements I encountered this bug when building openMVS ( https://github.com/OpenMVS ) on a osx 10.10.5 with xcode 7.0.1 installed. I manually changed the CeresConfig.cmake to specify current eigen3 @3.2.5 and it successfully compiled. -- Ticket URL: <https://trac.macports.org/ticket/49187> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

Re: [MacPorts] #44627: ceres-solver @1.9.0 library segfaults
by MacPorts 11 Dec '15

11 Dec '15

#44627: ceres-solver @1.9.0 library segfaults -------------------------------+----------------------- Reporter: julian.panetta@… | Owner: mmoll@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: fixed | Keywords: mavericks Port: ceres-solver | -------------------------------+----------------------- Changes (by mmoll@…): * status: new => closed * resolution: => fixed Comment: This issue has been fixed since the 1.10 release. See https://github.com /ceres-solver/ceres-solver/issues/151. -- Ticket URL: <https://trac.macports.org/ticket/44627#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X

1 0