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

[MacPorts] #46108: CMake and Yosemite Issue
by MacPorts 04 Mar '15

04 Mar '15

#46108: CMake and Yosemite Issue ----------------------------+-------------------------------- Reporter: jonlederman@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.3 Keywords: CMake Yosemite | Port: CMake ----------------------------+-------------------------------- Hi, Thanks for all your fine work on MacPorts. I have an issue with CMake after upgrading to Yosemite and then reinstalling MacPorts. I get the following error when invoking CMake Any help would be greatly appreciated. Thanks so much in advance. -Jon -sc/submodules/build-i386-apple-darwin/externals/zrtpcpp --check-build- system CMakeFiles/Makefile.cmake 0 Re-run cmake: build system dependency is missing -- The C compiler identification is AppleClang 6.0.0.6000054 -- The CXX compiler identification is AppleClang 6.0.0.6000054 -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -- broken CMake Error at /opt/local/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" is not able to compile a simple test program. It fails with the following output: Change Dir: /Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeTmp Run Build Command:"/opt/local/bin/gmake" "cmTryCompileExec2814572797/fast" gmake[3]: Entering directory '/Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeTmp' /opt/local/bin/gmake -f CMakeFiles/cmTryCompileExec2814572797.dir/build.make CMakeFiles/cmTryCompileExec2814572797.dir/build gmake[4]: Entering directory '/Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeTmp' /opt/local/bin/cmake -E cmake_progress_report /Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec2814572797.dir/testCCompiler.c.obj /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk -miphoneos-version-min=4.0 -DTARGET_OS_IPHONE=1 -D__IOS -fms-extensions -o CMakeFiles/cmTryCompileExec2814572797.dir/testCCompiler.c.obj -c /Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec2814572797 /opt/local/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec2814572797.dir/link.txt --verbose=1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk -miphoneos-version-min=4.0 -DTARGET_OS_IPHONE=1 -D__IOS -fms-extensions CMakeFiles/cmTryCompileExec2814572797.dir/testCCompiler.c.obj -o cmTryCompileExec2814572797 Undefined symbols for architecture i386: "start", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) CMakeFiles/cmTryCompileExec2814572797.dir/build.make:88: recipe for target 'cmTryCompileExec2814572797' failed gmake[4]: *** [cmTryCompileExec2814572797] Error 1 gmake[4]: Leaving directory '/Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeTmp' Makefile:118: recipe for target 'cmTryCompileExec2814572797/fast' failed gmake[3]: *** [cmTryCompileExec2814572797/fast] Error 2 gmake[3]: Leaving directory '/Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeTmp' CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:13 (PROJECT) -- Configuring incomplete, errors occurred! See also "/Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeOutput.log". See also "/Users/Jon/Documents/Developer/SonicCloud/linphone-iphone- sc/submodules/build-i386-apple- darwin/externals/zrtpcpp/CMakeFiles/CMakeError.log". make[2]: *** [cmake_check_build_system] Error 1 make[1]: *** [build-zrtpcpp] Error 2 make: *** [build] Error 2 Jons-MacBook-Pro-3:build Jon$ -- Ticket URL: <https://trac.macports.org/ticket/46108> MacPorts <https://www.macports.org/> Ports system for OS X

1 8

[MacPorts] #46167: cmake fails to build on clean 2.3.3 installation
by MacPorts 04 Mar '15

04 Mar '15

#46167: cmake fails to build on clean 2.3.3 installation ------------------------+-------------------------------- Reporter: diochnos@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: ------------------------+-------------------------------- I find it hard to believe that I am posting this ticket, but I can not see what I have done wrong. In a nutshell: cmake fails to install on a new macports installation. Background: There was a previous version of macports installed on the system (before the upgrade to Yosemite), which was uninstalled entirely (together with complete removal of the /opt/local/ directory). In particular, for the previous version I gave the following: $ sudo port -f uninstall installed \\ $ sudo port clean all For this version (2.3.3) I also gave a $ make clean before I started. This time I attempted a custom installation with the following command for configuration: $ env PATH=/usr/bin:/bin:/usr/sbin:/sbin CFLAGS="-pipe -Os" ./configure --prefix=/opt/macports/yosemite --with-applications- dir=/opt/macports/yosemite/Applications Other than that $ make \\ $ sudo make install \\ $ sudo port selfupdate \\ $ sudo port upgrade outdated \\ (everything as expected; meanwhile I also gave at some point `xcode-select --install`, so that's not a problem either) Then: $ sudo port install cmake fails on the last package, when attempting to bring in cmake. Upon the error: $ sudo port clean cmake \\ $ sudo port install cmake Same problem (even with a restart). Log attached. Running Xcode 6.1.1 on OS X 10.10.1. -- Ticket URL: <https://trac.macports.org/ticket/46167> MacPorts <https://www.macports.org/> Ports system for OS X

1 7

[MacPorts] #46902: Updating cmake @3.0.2_1+gui fails
by MacPorts 04 Mar '15

04 Mar '15

#46902: Updating cmake @3.0.2_1+gui fails ----------------------------+-------------------------------- Reporter: willic3@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: cmake, upgrade | Port: cmake +gui ----------------------------+-------------------------------- I did a selfupdate a couple of days ago, and the new version of cmake is unable to get past the patching stage: ---> Fetching distfiles for cmake ---> Verifying checksums for cmake ---> Checksumming cmake-3.1.3.tar.gz ---> Extracting cmake ---> Extracting cmake-3.1.3.tar.gz ---> Applying patches to cmake ---> Applying patch-CMakeFindFrameworks.cmake.diff patching file Modules/CMakeFindFrameworks.cmake ---> Applying patch-Modules-FindFreetype.cmake.diff patching file Modules/FindFreetype.cmake ---> Applying patch-Modules-FindQt4.cmake.diff patching file Modules/FindQt4.cmake ---> Applying patch-Modules-Platform-Darwin.cmake.diff patching file Modules/Platform/Darwin.cmake ---> Applying patch-Modules-Platform-Darwin-Initialize.cmake.diff patching file Modules/Platform/Darwin-Initialize.cmake ---> Applying patch-Modules-noArchCheck.diff patching file Modules/BasicConfigVersion-AnyNewerVersion.cmake.in patching file Modules/BasicConfigVersion-ExactVersion.cmake.in patching file Modules/BasicConfigVersion-SameMajorVersion.cmake.in ---> Applying patch-CMakeLists.txt.diff patching file CMakeLists.txt Hunk #1 FAILED at 476. 1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej patching file Source/QtDialog/CMakeLists.txt Hunk #1 succeeded at 125 (offset 26 lines). Hunk #2 succeeded at 141 (offset 26 lines). Hunk #3 FAILED at 179. Hunk #4 succeeded at 184 (offset 18 lines). 1 out of 4 hunks FAILED -- saving rejects to file Source/QtDialog/CMakeLists.txt.rej Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.1.3" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/cmake/files /patch-CMakeLists.txt.diff' Exit code: 1 Error: org.macports.patch for port cmake returned: command execution failed Warning: targets not executed for cmake: org.macports.install org.macports.patch org.macports.configure org.macports.build org.macports.destroot Please see the log file for port cmake for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/main.log Error: Unable to upgrade port: 1 To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Looking back in the old tickets, it appears this problem has occurred before. Thanks, Charles -- Ticket URL: <https://trac.macports.org/ticket/46902> MacPorts <https://www.macports.org/> Ports system for OS X

1 12

[MacPorts] #47005: python27 @2.7.9 destroot failure 10.4 - modules missing
by MacPorts 04 Mar '15

04 Mar '15

#47005: python27 @2.7.9 destroot failure 10.4 - modules missing ---------------------------+-------------------------------- Reporter: geoffdown@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: Tiger PowerPC | Port: Python27 ---------------------------+-------------------------------- Upgrade to python27 @2.7.9 failed at the destroot phase: {{{ :info:destroot Python build finished, but the necessary bits to build these modules were not found: :info:destroot bsddb185 linuxaudiodev ossaudiodev :info:destroot readline spwd sunaudiodev :info:destroot To find the necessary bits, look in setup.py in detect_modules() for the module's name. }}} @2.7.8_3 built ok, that was some time ago. I don't know how to act on the above message (there's more than one setup.py for a start). Are these dependencies? -- Ticket URL: <https://trac.macports.org/ticket/47005> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #47028: You're exposing your body to significant amount
by MacPorts 04 Mar '15

04 Mar '15

#47028: You're exposing your body to significant amount ---------------------------+-------------------------------- Reporter: lorilopez57@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: ---------------------------+-------------------------------- You're exposing your body to significant amount of stress the civic leader muscles ability to produce force to move against that resistance you're going to be stimulating and adaptive responses exposing it to a very intense stress if you're going out and getting a suntan if you're laying out Noonan audits on a clear day your supposing your skin to a stress is stressing skin's ability to protect your [http://supertestoboostsfacts.com/ragedna/ RageDNA] body yes ... radiation up to a point very hard trainees and stimulating adaptive response up to a point laying out an intense sunlight is constantly in adaptive response beyond some point you're not stimulating any further improvements you're starting to cause damage that your body's going to require more energy to recover from and if you expose your body too much too often you're going to end up with rather than an improvement in terms of the death of response land up with a breakdown of the relation with tissue in the case of exercise too much too often rather than getting stronger eventually get. http://supertestoboostsfacts.com/ragedna/ -- Ticket URL: <https://trac.macports.org/ticket/47028> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

Re: [MacPorts] #28582: MacPorts OpenSSL breaks a new Ruby release
by MacPorts 04 Mar '15

04 Mar '15

#28582: MacPorts OpenSSL breaks a new Ruby release -------------------------------------+---------------------- Reporter: joelmichael+macports@… | Owner: larryv@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Resolution: worksforme | Keywords: Port: openssl ruby19 | -------------------------------------+---------------------- Changes (by kimuraw@…): * status: new => closed * resolution: => worksforme Comment: I close this ticket. The ruby's redmine ticket says this problem was solved with other reasons. https://redmine.ruby-lang.org/issues/4370#note-4 -- Ticket URL: <https://trac.macports.org/ticket/28582#comment:13> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #41600: bison: update to 3.0.2
by MacPorts 04 Mar '15

04 Mar '15

#41600: bison: update to 3.0.2 ------------------------------+---------------------- Reporter: akim.demaille@… | Owner: larryv@… Type: update | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: bison | ------------------------------+---------------------- Comment (by rjvbertin@…): Who is *you* here? Currently the portfile indicates that it doesn't install libraries, and that appears to be true. I don't think it's a particularly good idea to split up the package in this case. There are times where I appreciate Debian's way of splitting up things and wished things were done the same way in MacPorts, but most of the time it just adds extra work. Remember that Debian creates split-up packages *after* building the full project *once* (I presume Arch would do the same). MacPorts doesn't allow that kind of efficiency AFAIK. I'd be in favour of merging the +yacc variant into the main port, and also wondered about the examples. In fact, I'd be in favour of moving the examples to a variant; most people are probably not interested in them anyway because they install bison only as a result of some automatic dependency. (And most who do use the application won't need examples anymore.) -- Ticket URL: <https://trac.macports.org/ticket/41600#comment:27> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #41600: bison: update to 3.0.2
by MacPorts 04 Mar '15

04 Mar '15

#41600: bison: update to 3.0.2 ------------------------------+---------------------- Reporter: akim.demaille@… | Owner: larryv@… Type: update | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: bison | ------------------------------+---------------------- Comment (by larryv@…): The [http://git.savannah.gnu.org/cgit/bison.git/tree/PACKAGING?id=v3.0.4 PACKAGING] file suggests distributing Bison as two separate packages, but that file hasn’t changed much during its [http://git.savannah.gnu.org/cgit/bison.git/log/PACKAGING decade of existence], and my cursory examination of [https://www.archlinux.org/packages/core/x86_64/bison/files/ Arch’s] and [https://packages.debian.org/wheezy/amd64/bison/filelist Debian’s] packaging suggests that other distributions tend to disregard it. Does upstream (i.e., you) care about this? It would be easy enough to split the port, but I don’t want to do so if PACKAGING is no longer relevant. -- Ticket URL: <https://trac.macports.org/ticket/41600#comment:26> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #41600: bison: update to 3.0.2
by MacPorts 04 Mar '15

04 Mar '15

#41600: bison: update to 3.0.2 ------------------------------+---------------------- Reporter: akim.demaille@… | Owner: larryv@… Type: update | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: bison | ------------------------------+---------------------- Comment (by larryv@…): Does omitting the `--disable-yacc` configure option change the build (other than installing the yacc executable, static library, and man page)? Is there a good reason we shouldn’t just do that always and get rid of the `yacc` variant? -- Ticket URL: <https://trac.macports.org/ticket/41600#comment:25> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #41600: bison: update to 3.0.2
by MacPorts 04 Mar '15

04 Mar '15

#41600: bison: update to 3.0.2 ------------------------------+---------------------- Reporter: akim.demaille@… | Owner: larryv@… Type: update | Status: assigned Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: bison | ------------------------------+---------------------- Comment (by larryv@…): Replying to [comment:4 akim.demaille@…]: > I have fixed the install rules so that all the examples be installed. > It's a pity that Bison does not install them by itself. Do we really want to install the examples’ intermediate products (e.g., `calc++-parser.cc`, `calc++-parser.hh`, etc.)? Seems really weird to me. -- Ticket URL: <https://trac.macports.org/ticket/41600#comment:24> MacPorts <https://www.macports.org/> Ports system for OS X

1 0