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

[MacPorts] #48982: Got problems with ncurses lib
by MacPorts 05 Oct '15

05 Oct '15

#48982: Got problems with ncurses lib ----------------------+-------------------------------- Reporter: vlatko@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: ----------------------+-------------------------------- Hello! After an upgrade of libraries in my project the ncurses lib didn't build/compile/install... I get the following critical message near the end of the log file: :info:build } :info:build } :info:build END { :info:build print "#endif /* NC_DEFINE_H */" :info:build } :info:build ' < $DEFS :info:build make[1]: *** [ncurses_def.h] Error 133 :info:build Trace/BPT trap: 5 :info:build dyld: Library not loaded: /opt/local/lib/libncurses.6.dylib :info:build Referenced from: /opt/local/lib/libreadline.6.dylib :info:build Reason: image not found :info:build Trace/BPT trap: 5 :info:build dyld: Library not loaded: /opt/local/lib/libncurses.6.dylib :info:build Referenced from: /opt/local/lib/libreadline.6.dylib :info:build Reason: image not found :info:build Trace/BPT trap: 5 :info:build dyld: Library not loaded: /opt/local/lib/libncurses.6.dylib :info:build Referenced from: /opt/local/lib/libreadline.6.dylib :info:build Reason: image not found :info:build Trace/BPT trap: 5 :info:build /bin/sh -c 'if test "cchar_t" = "cchar_t" ; then cat ./curses.wide >>curses.h ; fi' :info:build cat ./curses.tail >>curses.h :info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ncurses/ncurses/work/ncurses-6.0/include' :info:build make: *** [all] Error 2 :info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ncurses/ncurses/work/ncurses-6.0' :info:build Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ncurses/ncurses/work/ncurses-6.0" && /usr/bin/make -j8 -w all :info:build Exit code: 2 :error:build org.macports.build for port ncurses returned: command execution failed :debug:build Error code: CHILDSTATUS 43704 2 :debug:build Backtrace: command execution failed while executing "system -nice 0 $fullcmdstring" ("eval" body line 1) invoked from within "eval system $notty $nice \$fullcmdstring" invoked from within "command_exec build" (procedure "portbuild::build_main" line 8) invoked from within "portbuild::build_main org.macports.build" ("eval" body line 1) invoked from within "eval $procedure $targetname" :info:build Warning: targets not executed for ncurses: org.macports.activate org.macports.build org.macports.destroot org.macports.install -- Ticket URL: <https://trac.macports.org/ticket/48982> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #49091: Update to allow cmake 3.3.2 to find boost 1.59
by MacPorts 05 Oct '15

05 Oct '15

#49091: Update to allow cmake 3.3.2 to find boost 1.59 ---------------------------------+-------------------------------- Reporter: christian.frisson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: cmake boost ---------------------------------+-------------------------------- Hi, As of today MacPorts provides cmake 3.3.2 and Boost 1.59. FindBoost.cmake in cmake 3.3.2 requires an update to allow to find Boost 1.59. It has been fixed in cmake but after the 3.3.2 release: https://github.com/Kitware/CMake/commit/ff5bb2efbe9f7bb4a1824b0ad727713fcd6… Attached are updated/new files to fix this: Portfile and patch-Modules- FindBoost.cmake.diff. Best regards, Christian -- Ticket URL: <https://trac.macports.org/ticket/49091> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

Re: [MacPorts] #41783: Always use Mac OS X SDK
by MacPorts 05 Oct '15

05 Oct '15

#41783: Always use Mac OS X SDK ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.2.99 Resolution: wontfix | Keywords: Port: | ---------------------------+-------------------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => wontfix Comment: Time to put this ticket out of its misery. My year or two of using this patch on my own system has shown that the SDK path gets baked into various ports, which is undesirable. For example, it gets baked into various *-config programs, pkg-config *.pc files, and similar files in other software (like perl). This in turn causes other software to try to use that SDK—even if it no longer exists. One situation when this happens is if you install and `xcode-select` a beta version of Xcode (which is called Xcode-beta.app). The SDK paths that get baked into the programs include path to Xcode-beta.app. When you later remove Xcode-beta.app and install and select a final Xcode version, things fail when the SDK can't be found. This can be worked around by creating an Xcode-beta.app symlink pointing to Xcode.app. You'd have a similar problem if you ever renamed or moved Xcode. Another situation is when running Xcode 7 on OS X 10.10 Yosemite. Xcode 7 only includes the 10.11 SDK. If you have a library that was built with the 10.10 SDK when you were using Xcode 6, and it recorded the SDK flags into its config files, other programs that try to use that library will fail when the old SDK doesn't exist. Using the newest SDK is clearly what Apple wants us to do, so that should be the way that works best. The one case that was of interest to me where that does not work is if you are trying to compile software for PowerPC. The last SDK to support the ppc arch was the 10.6 SDK. And the last SDK to support the ppc64 arch was the 10.5 SDK. So if for example you are on 10.6 but want to build for ppc64, you have to use the 10.5 SDK. At this point, I'm not sure if anyone other than myself is still interested in that, so it should not be a consideration for MacPorts. -- Ticket URL: <https://trac.macports.org/ticket/41783#comment:14> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49088: Fail to build Boost on Leopard
by MacPorts 05 Oct '15

05 Oct '15

#49088: Fail to build Boost on Leopard ----------------------+-------------------------------- Reporter: galgot@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: Boost | Port: Boost ----------------------+-------------------------------- Can't upgrade Macports due to Boost failing to build. Tried sudo port clean Boost but no success. Running MacOS X 10.5.8, Xcode 3.1.4 , macport 2.3.3, on a MacMini G4. Attached log file. -- Ticket URL: <https://trac.macports.org/ticket/49088> MacPorts <https://www.macports.org/> Ports system for OS X

1 6

[MacPorts] #49102: autojump @21.5.8: checksum mismatch
by MacPorts 05 Oct '15

05 Oct '15

#49102: autojump @21.5.8: checksum mismatch --------------------------+--------------------------- Reporter: ryandesign@… | Owner: johnny.kuan@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: autojump --------------------------+--------------------------- autojump @21.5.8 has a checksum mismatch: {{{ $ port checksum autojump ---> Fetching distfiles for autojump ---> Attempting to fetch autojump-21.5.8.tar.gz from https://github.com/joelthelion/autojump/tarball/release-v21.5.8 ---> Verifying checksums for autojump Error: Checksum (rmd160) mismatch for autojump-21.5.8.tar.gz Error: Checksum (sha256) mismatch for autojump-21.5.8.tar.gz Error: Failed to checksum autojump: Unable to verify file checksums Error: See /opt/local/var/macports/logs/_Users_rschmidt_macports_dports_sysutils_autojump/autojump/main.log for details. Error: Follow http://guide.macports.org/#project.tickets to report a bug. Error: Processing of port autojump failed }}} This was first reported on the mailing list: https://lists.macosforge.org/pipermail/macports- users/2015-October/039454.html It looks like the project changed authors, from joelthelion to wting. This would account for the checksum mismatch, since the project author is part of the enclosing directory filename, and filenames are included in the data that the checksums are computed from. The port should be updated to use the new author name, and at the same time be updated to a newer version. 22.2.4 is currently the latest. -- Ticket URL: <https://trac.macports.org/ticket/49102> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

Re: [MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
by MacPorts 05 Oct '15

05 Oct '15

#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): I'll try to make this short, but the code extracts cancel most of the effort :) > it takes forever to build Qt4 on some systems. Interesting, the other day I did the build with nice +15 and only 3 out of my 2*2 cores (2 real, 2 HyperThreads), while watching 2 episodes in QuickTime - and I think the build was done well before I finished the 2nd, i.e. in less than 1.5hours. That's a lot of time to wait turning thumbs, but not exactly "forever" ;) Since it seems more than 1 person here will be rebuilding, maybe we can collect some statistics, for future reference? Also, I'd be more than happy to maintain a qt4-mac-devel port (i.e. with commit access), for exactly the suggested purpose (port development, test- bed, whatever you want to call it). Getting a GSoC student to handle my changes rather than letting me do it myself ... am I being a jerk if I say that feels like an insult? qt4-mac vs qt4 "tout court": I'd say there is no real need to change this. Everyone is used to the qt4-mac name for the port, and even if there's no more need to use a -mac vs a -x11 suffix I don't think there's a real advantage to dropping the suffix either. Besides, there's nothing that stops someone from reviving qt4-x11; it should be possible to get it to build still using the latest Qt version that still built for X11 (last time I checked Fink has such a "port" too). Above all, it seems a waste of time to force a rebuild of all dependents just for a change of name ... The only thing I champion is NOT to use qt4-mac for the prefix path, and that is also because Qt4 locations have been using `qt4` directories. Now, for a minimal change to make Qt4 concurrent, I would propose the following settings in the Qt4 PortGroup (I'm leaving the 2 comments I have in mine): {{{ # standard Qt4 name global qt_name set qt_name qt4 set qt_dir ${prefix}/libexec/${qt_name} set qt_dir_rel libexec/${qt_name} set qt_docs_dir ${prefix}/share/doc/${qt_name} set qt_plugins_dir ${prefix}/share/${qt_name}/plugins set qt_mkspecs_dir ${prefix}/share/${qt_name}/mkspecs set qt_imports_dir ${prefix}/share/${qt_name}/imports set qt_includes_dir ${prefix}/include/${qt_name} set qt_libs_dir ${qt_dir}/lib set qt_frameworks_dir ${qt_dir}/Library/Frameworks set qt_bins_dir ${qt_dir}/bin set qt_data_dir ${prefix}/share/${qt_name} set qt_translations_dir ${prefix}/share/${qt_name}/translations set qt_sysconf_dir ${prefix}/etc/${qt_name} #set qt_examples_dir ${prefix}/share/${qt_name}/examples set qt_examples_dir ${applications_dir}/Qt4/examples set qt_demos_dir ${applications_dir}/Qt4/demos # no need to change the cmake_module_dir, though I'd have preferred to # put it into ${prefix}/lib/cmake as qt5-mac also does, and which is the place Linux uses set qt_cmake_module_dir ${prefix}/share/cmake/Modules set qt_qmake_cmd ${qt_dir}/bin/qmake set qt_moc_cmd ${qt_dir}/bin/moc set qt_uic_cmd ${qt_dir}/bin/uic set qt_lrelease_cmd ${qt_dir}/bin/lrelease }}} * and for configure.args in the Portfile : {{{ # 20151003 : -prefix ${prefix} instead of -prefix ${qt_dir} (as with Qt5) would be # great, but will lead to frameworks in ${prefix}/Library/Frameworks instead # of in ${qt_dir}/Library/Frameworks ... configure.args-append \ -v \ -confirm-license \ -opensource \ -prefix ${qt_dir} \ -bindir ${qt_bins_dir} \ -libdir ${qt_libs_dir} \ -docdir ${qt_docs_dir} \ -headerdir ${qt_includes_dir} \ -plugindir ${qt_plugins_dir} \ -importdir ${qt_imports_dir} \ -datadir ${qt_data_dir} \ -translationdir ${qt_translations_dir} \ -sysconfdir ${qt_sysconf_dir} \ -examplesdir ${qt_examples_dir} \ -demosdir ${qt_demos_dir} \ -openssl-linked \ -dbus-linked \ -fast \ -optimized-qmake \ -no-pch \ -framework \ -no-phonon \ -no-phonon-backend \ -fontconfig -system-freetype }}} and to re-absorb the sqlite3 plugin subport into the main port so that `port:qt4-mac` itself doesn't require that subport in order to be able to run the applications it installs: {{{ # the sqlite3 plugin ("sqlite") has been re-absorbed into the main port however configure.args-append -system-sqlite depends_lib-append port:sqlite3 foreach driver {mysql odbc psql sqlite2} { configure.args-append -no-sql-${driver} } }}} Doing this means removing the `port:qt4-mac-sqlite3-plugin` dependency in dependent ports, or change them to `path:${qt_plugins_dir}/sqldrivers/libqsqlite.dylib:qt4-mac- sqlite3-plugin` (as has already been done in the KDE4 PortGroup). * I'd suggest looking at the changes to build without internal use of exceptions, which is actually the preferred way to build Qt (and the default in Qt5). I've added a variant to re-enable use of exceptions, but I don't think there's any point to that. Contrary to Qt's own -no- exceptions build, mine doesn't disable exceptions in the few components that do require them (just like Qt5 does). {{{ configure.args-append -no-exceptions # (26) don't build with exceptions, which gives a completely ABI- compatible build patchfiles-append disable-exceptions.patch post-destroot { if {![variant_isset exceptions ]} { # building with -no-exceptions will add a section to QtCore/qconfig.h that has to be removed # given that we did NOT build QtCore WITHOUT exceptions... exec patch -d ${destroot}${qt_frameworks_dir} -Np0 -i ${filespath }/qconfig-remove-EXCEPTIONS.diff } } }}} IIRC, current `port:qt4-mac` sets and then "configure.args-delete"'s `-optimized qmake`, for a reason that's unclear to me. I disabled that and haven't had any issues, and qmake is considerably faster because of it. I also use {{{ pre-configure { configure.env-append MAKEFLAGS=-j${build.jobs} } }}} to build qmake in parallel, which can make a big difference. NB: that's the "official" way to do it. A few useful things from my post-destroot : {{{ post-destroot { # Move .apps into the applications_dir, and link each .apps' # executable back into ${qt_bins_dir} set dr_qt_apps_dir ${destroot}${qt_apps_dir} set dr_qt_bins_dir ${destroot}${qt_bins_dir} xinstall -m 755 -d ${dr_qt_apps_dir} foreach app [glob ${dr_qt_bins_dir}/*.app] { # remove the leading stuff set app [lindex [split ${app} /] end] # move the .app move ${dr_qt_bins_dir}/${app} ${dr_qt_apps_dir} # link it back ln -s ${qt_apps_dir}/${app} ${dr_qt_bins_dir} # provide a proxy to the app's executable; symlinks won't # be accepted by qtchooser if the user has that port installed. set texe [strsed ${app} {g@\.app@@}] set appProxy ${dr_qt_bins_dir}/[string tolower ${texe}] copy ${filespath}/appProxy.sh ${appProxy} reinplace "s|@BUNDLEEXEC@|${qt_apps_dir}/${app}/Contents/MacOS/${texe}|g" ${appProxy} ln -s ${qt_qmake_cmd} ${destroot}/${prefix}/bin/qmake- qt${qt_major} ln -s ${qt_moc_cmd} ${destroot}/${prefix}/bin/moc-qt${qt_major} ln -s ${qt_uic_cmd} ${destroot}/${prefix}/bin/uic-qt${qt_major} ln -s ${qt_lrelease_cmd} ${destroot}/${prefix}/bin/lrelease- qt${qt_major} # expose KDE4 styles to Qt4: ln -s ${prefix}/lib/kde4/plugins/styles ${destroot}${qt_plugins_dir}/ } } }}} That's about all I can think of now. The only thing that I'd really hope to get in at this point are the install locations and to a somewhat lesser extent, preservation of the port name(s) and the re-absorbtion of the sqlite3 plugin. If I'm not overlooking anything else won't introduce incompatibilities with the changes I've been "evolving" and that I'm running locally. I'd just as well like to avoid having to rebuild everything *again* just because "you guys" haven't been keeping up with me :P -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:67> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #42100: arpack 3.1.3_0+accelerate+gcc48+universal: i386 configure cannot find BLAS
by MacPorts 05 Oct '15

05 Oct '15

#42100: arpack 3.1.3_0+accelerate+gcc48+universal: i386 configure cannot find BLAS -------------------------+--------------------- Reporter: nowornot@… | Owner: mmoll@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: fixed | Keywords: Port: arpack | -------------------------+--------------------- Changes (by mcalhoun@…): * status: new => closed * resolution: => fixed Comment: Should be fixed in r140910. -- Ticket URL: <https://trac.macports.org/ticket/42100#comment:22> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #49011: update relax to 3.3.8
by MacPorts 05 Oct '15

05 Oct '15

#49011: update relax to 3.3.8 -----------------------------------+-------------------------------- Reporter: howarth.at.macports@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: relax -----------------------------------+-------------------------------- The attached Portfile diff updates the relax packaging to the current upstream 3.3.8 release. -- Ticket URL: <https://trac.macports.org/ticket/49011> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #49099: vala 0.30.0 fails to build on Lion
by MacPorts 04 Oct '15

04 Oct '15

#49099: vala 0.30.0 fails to build on Lion ---------------------+-------------------------------- Reporter: amtor@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: vala ---------------------+-------------------------------- Upgrading vala from 0.28.1 to 0.30.0 on Lion fails to build. I have cleaned the vala port and tried to upgrade again to version 0.30.0. Still fails to build. See attached log. -- Ticket URL: <https://trac.macports.org/ticket/49099> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #49094: phantomjs 2.0 fails to build on OS X 10.11 El Capitan
by MacPorts 04 Oct '15

04 Oct '15

#49094: phantomjs 2.0 fails to build on OS X 10.11 El Capitan -----------------------+-------------------------------- Reporter: brandon@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: phantomjs -----------------------+-------------------------------- Build log is attached from brand new El Capitan install with fresh MacPorts 2.3.4. The failure appears to be due to build problems in the version of Qt5 (5.3) that ships with phantomjs 2.0. As a side note, given the regressions mentioned in the release notes for version 2.0 it might be prudent to roll this port back to 1.9 or ship a 1.9 compatability port for a while: http://phantomjs.org/release-2.0.html -- Ticket URL: <https://trac.macports.org/ticket/49094> MacPorts <https://www.macports.org/> Ports system for OS X

1 2