Re: [MacPorts] #50311: gmt5: build fails on Mavericks: error: conflicting types for 'dsyev_'
Dear Josh, Thank you for your reply. > However the reporter is building with +universal, which you can see later in > the log means x86_64 and i386. I didn’t notice this. > All compilers will define __LP64__ if and only if compiling for a 64-bit > target. This is correct. This means that __LP64__ is not defined for a 32-bit target. If the machine is 32-bit, long int, which is 32-bit is selected. But long int is 64-bit on 64-bit machine and this caused an error. I set universal_variant no to solve the problem. Thanks a lot. Takeshi - Takeshi Enomoto take...@macports.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #50311: gmt5: build fails on Mavericks: error: conflicting types for 'dsyev_'
On 2016-3-19 15:18 , Takeshi Enomoto wrote: Hi, I’m trying to fix the problem reported for gmt5. gmt5 fails due to the incompatibility of pointer type on a call to dsyev_ of CLPACK in Accelerate. The reporter runs Mavericks on an i386 machine (I didn’t know that i386 is supported). I don't think it could be an i386 machine, since the kernel has been x86_64 only since 10.8. If you see "arch i386" in the platform identification line in the log, that just corresponds to the output from 'uname -p'. However the reporter is building with +universal, which you can see later in the log means x86_64 and i386. According to the error message in main.log, int * is passed to long *. incompatible pointer types passing 'int *' to parameter of type '__CLPK_integer *' (aka 'long *’) It should be int * because it is 4-byte integer of Fortran. I suspect the compiler doesn’t compile the source with __LP64__ symbol on i386. Perhaps is this a problem of Xcode clang? Would put this clang version to blacklist help? All compilers will define __LP64__ if and only if compiling for a 64-bit target. This is correct. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Bad files on Mavericks buildbot (Fwd: buildbot failure in MacPorts on buildports-mavericks-x86_64)
On Mar 31, 2015, at 4:10 PM, Joshua Root j...@macports.org wrote: Oh, we took care of a conflict in /Applications/MacPorts/Python 2.6 already, but I guess there are more of python26's files still lying around. Henry (or whoever's reading this), could you please delete '/opt/local/Library/Frameworks/Python.framework/Versions/2.6' on the Mavericks slave as well? Instead of advocating deleting individual files and possibly missing some, why don't we advocate forcing the activation, then deactivating? sudo port -f activate python26 sudo port -f deactivate python26 That would take care of all of the port's files. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Bad files on Mavericks buildbot (Fwd: buildbot failure in MacPorts on buildports-mavericks-x86_64)
Looks like this was python26 files sitting in $prefix: Error: Failed to install python26 DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Headers already exists and does not belong to a registered port. Unable to activate port python26. Use 'port -f activate python26' to force the activation. Begin forwarded message: Date: March 31, 2015 at 12:50:28 PM EDT Subject: buildbot failure in MacPorts on buildports-mavericks-x86_64 From: nore...@macports.org To: bl...@macports.org, dl...@geeklair.net, dl...@macports.org The Buildbot has detected a failed build on builder buildports-mavericks-x86_64 while building MacPorts. Full details are available at: http://build.macports.org/builders/buildports-mavericks-x86_64/builds/11929 Buildbot URL: http://build.macports.org/ Buildslave for this Build: apple-mavericks-x86_64-ports Build Reason: scheduler Build Source Stamp: [branch trunk] 134598 Blamelist: dl...@macports.org BUILD FAILED: failed status sincerely, -The Buildbot -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Bad files on Mavericks buildbot (Fwd: buildbot failure in MacPorts on buildports-mavericks-x86_64)
Oh, we took care of a conflict in /Applications/MacPorts/Python 2.6 already, but I guess there are more of python26's files still lying around. Henry (or whoever's reading this), could you please delete '/opt/local/Library/Frameworks/Python.framework/Versions/2.6' on the Mavericks slave as well? - Josh On 2015-4-1 03:57 , Daniel J. Luke wrote: Looks like this was python26 files sitting in $prefix: Error: Failed to install python26 DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Headers already exists and does not belong to a registered port. Unable to activate port python26. Use 'port -f activate python26' to force the activation. Begin forwarded message: Date: March 31, 2015 at 12:50:28 PM EDT Subject: buildbot failure in MacPorts on buildports-mavericks-x86_64 From: nore...@macports.org To: bl...@macports.org, dl...@geeklair.net, dl...@macports.org The Buildbot has detected a failed build on builder buildports-mavericks-x86_64 while building MacPorts. Full details are available at: http://build.macports.org/builders/buildports-mavericks-x86_64/builds/11929 Buildbot URL: http://build.macports.org/ Buildslave for this Build: apple-mavericks-x86_64-ports Build Reason: scheduler Build Source Stamp: [branch trunk] 134598 Blamelist: dl...@macports.org BUILD FAILED: failed status sincerely, -The Buildbot -- Daniel J. Luke ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Fwd: buildbot failure in MacPorts on buildports-mavericks-x86_64
Looks like the Mavericks buildbot is hosed; can someone kick it? - MLD
{{{
Building ports
Building uhd (1 of 1)...Error: Port uhd not found
[snip]
touch: /var/tmp/failcache/uhd: No such file or directory
}}}
- Original message -
From: nore...@macports.org
To: michae...@macports.org
Subject: buildbot failure in MacPorts on buildports-mavericks-x86_64
Date: Tue, 17 Feb 2015 05:33:16 -0800
The Buildbot has detected a failed build on builder
buildports-mavericks-x86_64 while building MacPorts.
Full details are available at:
http://build.macports.org/builders/buildports-mavericks-x86_64/builds/10917
Buildbot URL: http://build.macports.org/
Buildslave for this Build: apple-mavericks-x86_64-ports
Build Reason: scheduler
Build Source Stamp: [branch trunk] 133000
Blamelist: michae...@macports.org
BUILD FAILED: failed status cleanup
sincerely,
-The Buildbot
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: buildbot failure in MacPorts on buildports-mavericks-x86_64
On Feb 17, 2015, at 8:37 AM, Michael Dickens wrote:
Looks like the Mavericks buildbot is hosed; can someone kick it? - MLD
{{{
Building ports
Building uhd (1 of 1)...Error: Port uhd not found
[snip]
touch: /var/tmp/failcache/uhd: No such file or directory
}}}
We're aware of it, and trying to work with Shree at Mac OS Forge to resolve it.
The build servers for OS X 10.7 and later went down after the macports.org SSL
certificate was renewed; we needed to manually accept the certificate once as
the right user. After that, builds resumed, except on the 10.9 build server,
which had a wedged Subversion working copy. After that was fixed by running
svn cleanup as the right user, we now have strange errors like the above
about ports or portgroups being missing. We think the working copy may somehow
have acquired uncommitted changes, which need to be reverted.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: buildbot failure in MacPorts on buildports-mavericks-x86_64
OK; good to know this is a known issue and is being actively addressed.
Thanks! - MLD
On Tue, Feb 17, 2015, at 09:53 AM, Ryan Schmidt wrote:
On Feb 17, 2015, at 8:37 AM, Michael Dickens wrote:
Looks like the Mavericks buildbot is hosed; can someone kick it? - MLD
{{{
Building ports
Building uhd (1 of 1)...Error: Port uhd not found
[snip]
touch: /var/tmp/failcache/uhd: No such file or directory
}}}
We're aware of it, and trying to work with Shree at Mac OS Forge to
resolve it.
The build servers for OS X 10.7 and later went down after the
macports.org SSL certificate was renewed; we needed to manually accept
the certificate once as the right user. After that, builds resumed,
except on the 10.9 build server, which had a wedged Subversion working
copy. After that was fixed by running svn cleanup as the right user, we
now have strange errors like the above about ports or portgroups being
missing. We think the working copy may somehow have acquired uncommitted
changes, which need to be reverted.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Linking issues on OSX Mavericks
Hello list, In discussion with Marko Käning I've been trying to get kde frameworks (aka kf5) to build on mac osx mavericks by using kdesrc-build which is a perl script that runs cmake, make and make install with some additional options specified. With the help of macports for most dependencies I'm able to build 13 of the frameworks, but the others fail. Many when building test applications with errors as seen here: https://paste.kde.org/psdzdpguq -- error log from kcoreaddons. If I try make VERBOSE=1 I see this: [ 3%] Built target KF5CoreAddons_automoc /Applications/Xcode.app/Contents/Developer/usr/bin/make -f src/lib/CMakeFiles/KF5CoreAddons.dir/build.make src/lib/CMakeFiles/KF5CoreAddons.dir/depend cd /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons /opt/local/bin/cmake -E cmake_depends Unix Makefiles /Users/jeremywhiting/devel/kde/src/frameworks/kcoreaddons /Users/jeremywhiting/devel/kde/src/frameworks/kcoreaddons/src/lib /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons/src/lib /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons/src/lib/CMakeFiles/KF5CoreAddons.dir/DependInfo.cmake --color= /Applications/Xcode.app/Contents/Developer/usr/bin/make -f src/lib/CMakeFiles/KF5CoreAddons.dir/build.make src/lib/CMakeFiles/KF5CoreAddons.dir/build make[2]: Nothing to be done for `src/lib/CMakeFiles/KF5CoreAddons.dir/build'. /opt/local/bin/cmake -E cmake_progress_report /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons/CMakeFiles 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 [ 87%] Built target KF5CoreAddons /Applications/Xcode.app/Contents/Developer/usr/bin/make -f tests/CMakeFiles/faceicontest.dir/build.make tests/CMakeFiles/faceicontest.dir/depend cd /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons /opt/local/bin/cmake -E cmake_depends Unix Makefiles /Users/jeremywhiting/devel/kde/src/frameworks/kcoreaddons /Users/jeremywhiting/devel/kde/src/frameworks/kcoreaddons/tests /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons/tests /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons/tests/CMakeFiles/faceicontest.dir/DependInfo.cmake --color= /Applications/Xcode.app/Contents/Developer/usr/bin/make -f tests/CMakeFiles/faceicontest.dir/build.make tests/CMakeFiles/faceicontest.dir/build Linking CXX executable faceicontest.app/Contents/MacOS/faceicontest cd /Users/jeremywhiting/devel/kde/build/frameworks/kcoreaddons/tests /opt/local/bin/cmake -E cmake_link_script CMakeFiles/faceicontest.dir/link.txt --verbose=1 /usr/bin/c++ -pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security -Werror=return-type -Wno-variadic-macros -Wlogical-op -std=c++0x -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -fexceptions -g -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/faceicontest.dir/faceicontest.cpp.o CMakeFiles/faceicontest.dir/faceicontest_automoc.cpp.o -o faceicontest.app/Contents/MacOS/faceicontest /opt/local/Library/Frameworks/QtWidgets.framework/QtWidgets ../src/lib/libKF5CoreAddons.5.5.0.dylib /opt/local/Library/Frameworks/QtGui.framework/QtGui /opt/local/Library/Frameworks/QtCore.framework/QtCore Undefined symbols for architecture x86_64: KUser::allUsers(unsigned int), referenced from: FaceIconTest::FaceIconTest() in faceicontest.cpp.o KUser::KUser(KUser const), referenced from: QListKUser::node_copy(QListKUser::Node*, QListKUser::Node*, QListKUser::Node*) in faceicontest.cpp.o KUser::~KUser(), referenced from: QListKUser::node_copy(QListKUser::Node*, QListKUser::Node*, QListKUser::Node*) in faceicontest.cpp.o QListKUser::node_destruct(QListKUser::Node*, QListKUser::Node*) in faceicontest.cpp.o KUser::faceIconPath() const, referenced from: FaceIconTest::FaceIconTest() in faceicontest.cpp.o KUser::loginName() const, referenced from: FaceIconTest::FaceIconTest() in faceicontest.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) So it seems it's specifying the right paths to find the library to link against. nm on the .dylib shows the symbols that the linker says are missing. file on the dylib says it's x86_64 format. otool -L shows it is linking against libc++ so I'm not sure what else would cause this. Note I'm a bit new to development on Mac though I've dabbled in it before. I build software on linux quite a lot and a bit on windows also so am used to compiler differences, but I'm a bit stumped here so I thought I'd ask for ideas. thanks, Jeremy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman
Re: Linking issues on OSX Mavericks
Hi, - On 4 Dec, 2014, at 00:20, Jeremy Whiting jpwhit...@kde.org wrote: nm on the .dylib shows the symbols that the linker says are missing. file on the dylib says it's x86_64 format. otool -L shows it is linking against libc++ so I'm not sure what else would cause this. I'll bet the problem is different symbol mangling for libc++ and libstdc++. Ensure you don't have MACOSX_DEPLOYMENT_TARGET set or that it's greater or equal 10.9 and that you link with -std=c++11 -stdlib=libc++. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Linking issues on OSX Mavericks
Perfect that solved the linking issue. Thanks On Dec 3, 2014 5:42 PM, Clemens Lang c...@macports.org wrote: Hi, - On 4 Dec, 2014, at 00:20, Jeremy Whiting jpwhit...@kde.org wrote: nm on the .dylib shows the symbols that the linker says are missing. file on the dylib says it's x86_64 format. otool -L shows it is linking against libc++ so I'm not sure what else would cause this. I'll bet the problem is different symbol mangling for libc++ and libstdc++. Ensure you don't have MACOSX_DEPLOYMENT_TARGET set or that it's greater or equal 10.9 and that you link with -std=c++11 -stdlib=libc++. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)
Hi, The warning is correct. If s_decoded.name is a boolean then s_decoded.name = 12 is always true. OSX10.9 has a newer clang, which issues a warning in this case (-Wtautological-constant-out-of-range-compare), older OSes have older clang versions that do not. Finally -Werror turns it into an error. So basically its a bug in the code which should be reported upstream to get fixed. Chris On 15/10/14 02:22, Craig Treleaven wrote: At 2:39 PM -0700 10/14/14, nore...@macports.org wrote: The Buildbot has detected a failed build on builder buildports-mavericks-x86_64 while building MacPorts. Full details are available at: http://build.macports.org/builders/buildports-mavericks-x86_64/builds/7702 Can some kind person (Jeremy?) help me understand why the version of Clang on the Mavericks buildbot is falling over while the Lion and MtnLion versions don't even spit a warning? Mavericks Clang errors out with the following: test_dr.c:49:3: error: comparison of constant 12 with expression of type 'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare] BOZO_end_boolean(b_multiple_frame_rate) ^~~ ./test_dr.h:102:39: note: expanded from macro 'BOZO_end_boolean' } while(!i_err (s_decoded.name = 12)); \ ~~ ^ ~~ (Complete log from the Mavericks buildbot attached.) If I understand correctly (always dicey given I'm not a C developer), this is a unit test with (I guess) an awkward construct. The thing is, Clang on MtnLion doesn't complain at all on the same code. What would be the best way to get past this? Thanks, Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)
Thanks, all. A conditional patch (... ${os.major} = 13 ...) and at
least it builds. I will follow up upstream.
Craig
At 8:43 AM +0100 10/15/14, Chris Jones wrote:
The warning is correct. If s_decoded.name is a boolean then
s_decoded.name = 12 is always true. OSX10.9 has a newer clang,
which issues a warning in this case
(-Wtautological-constant-out-of-range-compare), older OSes have
older clang versions that do not. Finally -Werror turns it into an
error.
So basically its a bug in the code which should be reported upstream
to get fixed.
On 15/10/14 02:22, Craig Treleaven wrote:
At 2:39 PM -0700 10/14/14, nore...@macports.org wrote:
The Buildbot has detected a failed build on builder
buildports-mavericks-x86_64 while building MacPorts.
Full details are available at:
http://build.macports.org/builders/buildports-mavericks-x86_64/builds/7702
Can some kind person (Jeremy?) help me understand why the version of
Clang on the Mavericks buildbot is falling over while the Lion and
MtnLion versions don't even spit a warning?
Mavericks Clang errors out with the following:
test_dr.c:49:3: error: comparison of constant 12 with expression of type
'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
BOZO_end_boolean(b_multiple_frame_rate)
^~~
./test_dr.h:102:39: note: expanded from macro 'BOZO_end_boolean'
} while(!i_err (s_decoded.name = 12)); \
~~ ^ ~~
(Complete log from the Mavericks buildbot attached.)
If I understand correctly (always dicey given I'm not a C developer),
this is a unit test with (I guess) an awkward construct. The thing is,
Clang on MtnLion doesn't complain at all on the same code.
What would be the best way to get past this?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)
I’d assume (even though I’m not that Jeremy) that the clang on mavericks is newer and simply has more warnings as errors. The warning flags in the brackets are what were triggered: do they exist on the older compiler version and if so are they active? That’s probably all it is. On Oct 14, 2014, at 21:22, Craig Treleaven ctrelea...@macports.org wrote: At 2:39 PM -0700 10/14/14, nore...@macports.org wrote: The Buildbot has detected a failed build on builder buildports-mavericks-x86_64 while building MacPorts. Full details are available at: http://build.macports.org/builders/buildports-mavericks-x86_64/builds/7702 Can some kind person (Jeremy?) help me understand why the version of Clang on the Mavericks buildbot is falling over while the Lion and MtnLion versions don't even spit a warning? Mavericks Clang errors out with the following: test_dr.c:49:3: error: comparison of constant 12 with expression of type 'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare] BOZO_end_boolean(b_multiple_frame_rate) ^~~ ./test_dr.h:102:39: note: expanded from macro 'BOZO_end_boolean' } while(!i_err (s_decoded.name = 12)); \ ~~ ^ ~~ (Complete log from the Mavericks buildbot attached.) If I understand correctly (always dicey given I'm not a C developer), this is a unit test with (I guess) an awkward construct. The thing is, Clang on MtnLion doesn't complain at all on the same code. What would be the best way to get past this? Thanks, Craig libdvbpsi_buildFail_Mavericks_2014Oct14.txt.zip___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)
On Oct 14, 2014, at 9:22 PM, Craig Treleaven ctrelea...@macports.org wrote: Mavericks Clang errors out with the following: test_dr.c:49:3: error: comparison of constant 12 with expression of type 'bool' is always true [-Werror,-Wtautological-constant-out-of-range-compare] BOZO_end_boolean(b_multiple_frame_rate) ^~~ ./test_dr.h:102:39: note: expanded from macro 'BOZO_end_boolean' } while(!i_err (s_decoded.name = 12)); \ ~~ ^ ~~ (Complete log from the Mavericks buildbot attached.) If I understand correctly (always dicey given I'm not a C developer), this is a unit test with (I guess) an awkward construct. The thing is, Clang on MtnLion doesn't complain at all on the same code. What would be the best way to get past this? Patch or reinplace the -Werror flags out of the build. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: clang 3.5 build fails on Mavericks
Hi Lawrence, FWIW, I successfully installed clang-3.5 on 10.9.4 a few days ago. interesting… Wondering what went wrong in my case. I’ll deal with the related ticket later. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: clang 3.5 build fails on Mavericks
Did you try building it from source? Because when I installed it my machines just now, it installed from ready built binaries (with no errors). -- Andreas Kusalananda Kähäri System Developer at BILS Uppsala University, Sweden On 11 Sep 2014, at 20:35, Marko Käning mk-macpo...@techno.ms wrote: Hi Lawrence, FWIW, I successfully installed clang-3.5 on 10.9.4 a few days ago. interesting… Wondering what went wrong in my case. I’ll deal with the related ticket later. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: clang 3.5 build fails on Mavericks
On 11 Sep 2014, at 20:50 , Andreas Kusalananda Kähäri andreas.kah...@bils.se wrote: Did you try building it from source? Because when I installed it my machines just now, it installed from ready built binaries (with no errors). Yes, I didn’t force the build, but it happened to be a build from sources. Don’t know why... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
clang 3.5 build fails on Mavericks
Hi, I am surprised to see clang 5.3 failing to build on OSX 10.9.4, as I thought it is stable. Greets, Marko [1] https://trac.macports.org/ticket/44937 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Mavericks MacPorts Base Buildbot is hanging in svn
Hi, it seems the Mavericks base builbot locks up while trying to check out an SVN working copy. It currently hangs: https://build.macports.org/builders/buildbase-mavericks-x86_64/builds/460/steps/svn/logs/stdio and will eventually time out as it has before: https://build.macports.org/builders/buildbase-mavericks-x86_64/builds/458/steps/svn/logs/stdio The error message will be svn: E175002: REPORT of '/repository/macports/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.macports.org), which looks like a network issue to me. Can you take a look? -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks MacPorts Base Buildbot is hanging in svn
Clemens Didn’t see anything odd so I restarted it. Let me know if it hangs again. -Shree On Aug 19, 2014, at 5:10 PM, Clemens Lang c...@macports.org wrote: Hi, it seems the Mavericks base builbot locks up while trying to check out an SVN working copy. It currently hangs: https://build.macports.org/builders/buildbase-mavericks-x86_64/builds/460/steps/svn/logs/stdio and will eventually time out as it has before: https://build.macports.org/builders/buildbase-mavericks-x86_64/builds/458/steps/svn/logs/stdio The error message will be svn: E175002: REPORT of '/repository/macports/!svn/vcc/default': Could not read response body: Secure connection truncated (https://svn.macports.org), which looks like a network issue to me. Can you take a look? -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Mavericks Buildbot hangs
Hi, the Mavericks buildbot seems to be stuck. Can you take a look? In general, the buildbots seems to hang a lot at the moment. E.g., the tests for some of the base buildbots get aborted because they hang without output for more than 1200 seconds. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 28, 2014, at 2:00 PM, Brandon Allbery allber...@gmail.com wrote: Every link-time shared object contains a canonical name telling the dynamic loader how to find the runtime version of the shared object. On OS X with Mach-O, it's called install_name and is a full pathname; there is nothing like ELF's rpath, except that there is now ;-) from man install_name_tool: -rpath old new Changes the rpath path name old to new in the specified Mach-O binary. More than one of these options can be specified. If the Mach-O binary does not contain the old rpath path name in a specified -rpath it is an error. -add_rpath new Adds the rpath path name new in the specified Mach-O binary. More than one of these options can be specified. If the Mach-O binary already contains the new rpath path name specified in -add_rpath it is an error. -delete_rpath old deletes the rpath path name old in the specified Mach-O binary. More than one of these options can be specified. If the Mach-O binary does not contains the old rpath path name specified in -delete_rpath it is an error. we use -add_rpath in the oracle-instantclient port for Leopard and newer... -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 27, 2014, at 8:49 PM, Mark Brethen mark.bret...@gmail.com wrote:
On Jun 27, 2014, at 9:22 AM, Joshua Root j...@macports.org wrote:
On 2014-6-27 23:30 , Mark Brethen wrote:
On Jun 27, 2014, at 12:45 AM, Ryan Schmidt ryandes...@macports.org wrote:
On Jun 27, 2014, at 12:38 AM, Joshua Root wrote:
On 2014-6-27 14:03 , Mark Brethen wrote:
After installing Coin, I get the following error with SoQt:
--- Found 1 broken file(s), matching files to ports
Error: Port SoQt is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a
bug.
Running port -d -y rev-upgrade gives:
Could not open Inventor.framework/Versions/C/Inventor: Error opening or
reading file (referenced from
/opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib)
DEBUG: Marking
/opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib
as broken
--- Found 1 broken file(s), matching files to ports
Inventor.framework/Versions/C/Inventor is a relative path and so not a
suitable install_name.
Correct. And that's yet another bug in the Coin port's +aqua variant that
needs to be fixed.
SoQt's frameworks' install_names are wrong too, but I'm not sure if that's
because Coin's are wrong or if it's a separately-fixable instance of the
same problem.
The Inventor install_name originates with Coin: 'Since Coin is an Open
Inventor implementation, the framework is named Inventor, not Coin.'
(Coin/Readme.MacOS)
However, I did not experience any linking errors when I installed Coin as a
framework. SoQt is just a bridge between Qt and Coin.
So, to clarify, are you saying this is just a flag that is raised because
there isn't a port named 'Inventor'?
No, we're saying the install_name needs to be an absolute path, not a
relative one.
- Josh
For SoQt: -install_name
/opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.dylib
For Coin: -install_name
/opt/local/Library/Frameworks/Inventor.framework/Versions/C/Libraries/libCoin.60.dylib
Are you saying those are the install_names that are currently being used, or
those are the flags that need to be used? If the latter, you'll need to figure
out how to patch the build system to insert those.
brethen-mbp:Frameworks marbre$ ls -alR Inventor.framework
total 32
drwxr-xr-x 7 root wheel 238 Jun 24 19:52 .
drwxr-xr-x 27 root wheel 918 Jun 27 19:41 ..
lrwxr-xr-x 1 root wheel 24 Jun 24 19:52 Headers -
Versions/Current/Headers
lrwxr-xr-x 1 root wheel 25 Jun 24 19:52 Inventor -
Versions/Current/Inventor
lrwxr-xr-x 1 root wheel 26 Jun 24 19:52 Libraries -
Versions/Current/Libraries
lrwxr-xr-x 1 root wheel 26 Jun 24 19:52 Resources -
Versions/Current/Resources
drwxr-xr-x 4 root wheel 136 Jun 24 19:52 Versions
Inventor.framework/Versions:
total 8
drwxr-xr-x 4 root wheel 136 Jun 24 19:52 .
drwxr-xr-x 7 root wheel 238 Jun 24 19:52 ..
drwxr-xr-x 6 root wheel 204 Jun 24 19:52 C
lrwxr-xr-x 1 root wheel1 Jun 24 19:52 Current - C
Inventor.framework/Versions/C:
total 8
drwxr-xr-x6 root wheel 204 Jun 24 19:52 .
drwxr-xr-x4 root wheel 136 Jun 24 19:52 ..
drwxr-xr-x 115 root wheel 3910 Jun 24 19:52 Headers
lrwxr-xr-x1 root wheel23 Jun 24 19:52 Inventor -
Libraries/libCoin.dylib
drwxr-xr-x5 root wheel 170 Jun 24 19:52 Libraries
drwxr-xr-x8 root wheel 272 Jun 24 19:52 Resources
Inventor.framework/Versions/C/Libraries:
total 14776
drwxr-xr-x 5 root wheel 170 Jun 24 19:52 .
drwxr-xr-x 6 root wheel 204 Jun 24 19:52 ..
-rwxr-xr-x 1 root wheel 7555684 Jun 24 19:52 libCoin.60.1.3.dylib
lrwxr-xr-x 1 root wheel 20 Jun 24 19:52 libCoin.60.dylib -
libCoin.60.1.3.dylib
lrwxr-xr-x 1 root wheel 20 Jun 24 19:52 libCoin.dylib -
libCoin.60.1.3.dylib
Why isn't SoQt linked directly to libCoin.60.1.3.dylib?
What do you mean? What is it linked to instead?
I found this error in the main.log for Coin:
:debug:build Executing proc-post-org.macports.build-build-0
:info:build --- Patching Coin.pc: s|-arch [a-z0-9_]+||g
:debug:build Executing reinplace: /usr/bin/sed -E {s|-arch [a-z0-9_]+||g}
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_Coin/Coin/work/Coin-3.1.3/Coin.pc
@ file10 2@stderr
That doesn't look like an error; rather, it looks like a successful invocation
of reinplace.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 28, 2014, at 3:23 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 27, 2014, at 8:49 PM, Mark Brethen mark.bret...@gmail.com wrote: On Jun 27, 2014, at 9:22 AM, Joshua Root j...@macports.org wrote: On 2014-6-27 23:30 , Mark Brethen wrote: On Jun 27, 2014, at 12:45 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 27, 2014, at 12:38 AM, Joshua Root wrote: On 2014-6-27 14:03 , Mark Brethen wrote: After installing Coin, I get the following error with SoQt: --- Found 1 broken file(s), matching files to ports Error: Port SoQt is still broken after rebuilding it more than 3 times. Error: Please run port -d -y rev-upgrade and use the output to report a bug. Running port -d -y rev-upgrade gives: Could not open Inventor.framework/Versions/C/Inventor: Error opening or reading file (referenced from /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib) DEBUG: Marking /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib as broken --- Found 1 broken file(s), matching files to ports Inventor.framework/Versions/C/Inventor is a relative path and so not a suitable install_name. Correct. And that's yet another bug in the Coin port's +aqua variant that needs to be fixed. SoQt's frameworks' install_names are wrong too, but I'm not sure if that's because Coin's are wrong or if it's a separately-fixable instance of the same problem. The Inventor install_name originates with Coin: 'Since Coin is an Open Inventor implementation, the framework is named Inventor, not Coin.' (Coin/Readme.MacOS) However, I did not experience any linking errors when I installed Coin as a framework. SoQt is just a bridge between Qt and Coin. So, to clarify, are you saying this is just a flag that is raised because there isn't a port named 'Inventor'? No, we're saying the install_name needs to be an absolute path, not a relative one. - Josh For SoQt: -install_name /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.dylib For Coin: -install_name /opt/local/Library/Frameworks/Inventor.framework/Versions/C/Libraries/libCoin.60.dylib Are you saying those are the install_names that are currently being used, or those are the flags that need to be used? If the latter, you'll need to figure out how to patch the build system to insert those. Those are the install_names at build time of each respective port. brethen-mbp:Frameworks marbre$ ls -alR Inventor.framework total 32 drwxr-xr-x 7 root wheel 238 Jun 24 19:52 . drwxr-xr-x 27 root wheel 918 Jun 27 19:41 .. lrwxr-xr-x 1 root wheel 24 Jun 24 19:52 Headers - Versions/Current/Headers lrwxr-xr-x 1 root wheel 25 Jun 24 19:52 Inventor - Versions/Current/Inventor lrwxr-xr-x 1 root wheel 26 Jun 24 19:52 Libraries - Versions/Current/Libraries lrwxr-xr-x 1 root wheel 26 Jun 24 19:52 Resources - Versions/Current/Resources drwxr-xr-x 4 root wheel 136 Jun 24 19:52 Versions Inventor.framework/Versions: total 8 drwxr-xr-x 4 root wheel 136 Jun 24 19:52 . drwxr-xr-x 7 root wheel 238 Jun 24 19:52 .. drwxr-xr-x 6 root wheel 204 Jun 24 19:52 C lrwxr-xr-x 1 root wheel1 Jun 24 19:52 Current - C Inventor.framework/Versions/C: total 8 drwxr-xr-x6 root wheel 204 Jun 24 19:52 . drwxr-xr-x4 root wheel 136 Jun 24 19:52 .. drwxr-xr-x 115 root wheel 3910 Jun 24 19:52 Headers lrwxr-xr-x1 root wheel23 Jun 24 19:52 Inventor - Libraries/libCoin.dylib drwxr-xr-x5 root wheel 170 Jun 24 19:52 Libraries drwxr-xr-x8 root wheel 272 Jun 24 19:52 Resources Inventor.framework/Versions/C/Libraries: total 14776 drwxr-xr-x 5 root wheel 170 Jun 24 19:52 . drwxr-xr-x 6 root wheel 204 Jun 24 19:52 .. -rwxr-xr-x 1 root wheel 7555684 Jun 24 19:52 libCoin.60.1.3.dylib lrwxr-xr-x 1 root wheel 20 Jun 24 19:52 libCoin.60.dylib - libCoin.60.1.3.dylib lrwxr-xr-x 1 root wheel 20 Jun 24 19:52 libCoin.dylib - libCoin.60.1.3.dylib Why isn't SoQt linked directly to libCoin.60.1.3.dylib? What do you mean? What is it linked to instead? :info:build /usr/bin/clang++ -dynamiclib -o .libs/libSoQt.20.5.0.dylib .libs/SoQt.o .libs/SoQtSignalThread.o .libs/SoQtComponent.o .libs/SoQtGLWidget.o .libs/SoQtImageReader.o .libs/SoAny.o .libs/SoQtCursor.o .libs/SoQtObject.o .libs/SoQtCommon.o .libs/SoQtComponentCommon.o .libs/SoQtGLWidgetCommon.o .libs/SoQtRenderArea.o .libs/libSoQt.lax/libSoQtDevices.a/6DOFEvents.o .libs/libSoQt.lax/libSoQtDevices.a/SoQtDevice.o .libs/libSoQt.lax/libSoQtDevices.a/SoQtDeviceCommon.o .libs/libSoQt.lax/libSoQtDevices.a/SoQtInputFocus.o .libs/libSoQt.lax/libSoQtDevices.a/SoQtInputFocusCommon.o .libs/libSoQt.lax/libSoQtDevices.a/SoQtKeyboard.o .libs/libSoQt.lax/libSoQtDevices.a/SoQtKeyboardCommon.o
Re: SoQt linking error on Mavericks (10.9.3)
On Sat, Jun 28, 2014 at 1:45 PM, Mark Brethen mark.bret...@gmail.com wrote: Those are the install_names at build time of each respective port. I think you're confused about install_name means. Every link-time shared object contains a canonical name telling the dynamic loader how to find the runtime version of the shared object. On OS X with Mach-O, it's called install_name and is a full pathname; there is nothing like ELF's rpath, but there are special environment variables that override the embedded locations (this is why people assuming that DYLD_LIBRARY_PATH is like ELF-style LD_LIBRARY_PATH break their systems; it doesn't behave the same way and can cause system-provided shared objects to not be found or inappropriately replaced). The install_name is therefore a special name embedded in a shared object allowing it to be found at runtime. If this is not either a full path or a bundle-relative path (which works *only* with bundles -- that is, things like frameworks or the app bundles you find in /Applications; these start with @ and a keyword), the dynamic loader won't be able to find the shared object at runtime. Relative pathnames will not be found reliably, and the default will be the build path --- which will almost always be incorrect, because applications aren't normally run out of their build directories, they are installed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 28, 2014, at 1:00 PM, Brandon Allbery allber...@gmail.com wrote: On Sat, Jun 28, 2014 at 1:45 PM, Mark Brethen mark.bret...@gmail.com wrote: Those are the install_names at build time of each respective port. I think you're confused about install_name means. Every link-time shared object contains a canonical name telling the dynamic loader how to find the runtime version of the shared object. On OS X with Mach-O, it's called install_name and is a full pathname; there is nothing like ELF's rpath, but there are special environment variables that override the embedded locations (this is why people assuming that DYLD_LIBRARY_PATH is like ELF-style LD_LIBRARY_PATH break their systems; it doesn't behave the same way and can cause system-provided shared objects to not be found or inappropriately replaced). The install_name is therefore a special name embedded in a shared object allowing it to be found at runtime. If this is not either a full path or a bundle-relative path (which works *only* with bundles -- that is, things like frameworks or the app bundles you find in /Applications; these start with @ and a keyword), the dynamic loader won't be able to find the shared object at runtime. Relative pathnames will not be found reliably, and the default will be the build path --- which will almost always be incorrect, because applications aren't normally run out of their build directories, they are installed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net So either the coin or soqt framework is bundled incorrectly? How would check which is the culprit? I just installed coin +aqua and soqt +aqua using '--without-framework' and did not get any link errors. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Sat, Jun 28, 2014 at 2:23 PM, Mark Brethen mark.bret...@gmail.com wrote: So either the coin or soqt framework is bundled incorrectly? How would check which is the culprit? I just installed coin +aqua and soqt +aqua using '--without-framework' and did not get any link errors. The implication from what I've seen is that something is not using install_name_tool properly to make the shared objects bundle-relative, yes. I haven't done much with bundles but could probably find the Apple docs on how to set the install_name appropriately for framework bundles. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 28, 2014, at 1:44 PM, Brandon Allbery allber...@gmail.com wrote: On Sat, Jun 28, 2014 at 2:23 PM, Mark Brethen mark.bret...@gmail.com wrote: So either the coin or soqt framework is bundled incorrectly? How would check which is the culprit? I just installed coin +aqua and soqt +aqua using '--without-framework' and did not get any link errors. The implication from what I've seen is that something is not using install_name_tool properly to make the shared objects bundle-relative, yes. I haven't done much with bundles but could probably find the Apple docs on how to set the install_name appropriately for framework bundles. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net Coin: brethen-mbp:Libraries marbre$ ls -al total 14776 drwxr-xr-x 5 root wheel 170 Jun 28 16:43 . drwxr-xr-x 6 root wheel 204 Jun 28 16:43 .. -rwxr-xr-x 1 root wheel 7555684 Jun 28 16:43 libCoin.60.1.3.dylib lrwxr-xr-x 1 root wheel 20 Jun 28 16:43 libCoin.60.dylib - libCoin.60.1.3.dylib lrwxr-xr-x 1 root wheel 20 Jun 28 16:43 libCoin.dylib - libCoin.60.1.3.dylib brethen-mbp:Libraries marbre$ otool -L libCoin.60.1.3.dylib libCoin.60.1.3.dylib: Inventor.framework/Versions/C/Inventor (compatibility version 62.0.0, current version 62.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.16.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) For SoQt: brethen-mbp:Libraries marbre$ ls -al total 1240 drwxr-xr-x 5 root wheel 170 Jun 28 17:02 . drwxr-xr-x 6 root wheel 204 Jun 28 17:02 .. -rwxr-xr-x 1 root wheel 624900 Jun 28 17:02 libSoQt.20.5.0.dylib lrwxr-xr-x 1 root wheel 20 Jun 28 17:02 libSoQt.20.dylib - libSoQt.20.5.0.dylib lrwxr-xr-x 1 root wheel 20 Jun 28 17:02 libSoQt.dylib - libSoQt.20.5.0.dylib brethen-mbp:Libraries marbre$ otool -L libSoQt.20.5.0.dylib libSoQt.20.5.0.dylib: SoQt.framework/Versions/A/SoQt (compatibility version 26.0.0, current version 26.0.0) /opt/local/Library/Frameworks/QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.8.0, current version 4.8.6) /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.6) /opt/local/Library/Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.6) Inventor.framework/Versions/C/Inventor (compatibility version 62.0.0, current version 62.3.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) Qt4-mac, Coin and SoQt are consistent, in that they all use symlinks to the actual library. Those in /usr/lib however use absolute paths. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 27, 2014, at 12:45 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 27, 2014, at 12:38 AM, Joshua Root wrote: On 2014-6-27 14:03 , Mark Brethen wrote: After installing Coin, I get the following error with SoQt: --- Found 1 broken file(s), matching files to ports Error: Port SoQt is still broken after rebuilding it more than 3 times. Error: Please run port -d -y rev-upgrade and use the output to report a bug. Running port -d -y rev-upgrade gives: Could not open Inventor.framework/Versions/C/Inventor: Error opening or reading file (referenced from /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib) DEBUG: Marking /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib as broken --- Found 1 broken file(s), matching files to ports Inventor.framework/Versions/C/Inventor is a relative path and so not a suitable install_name. Correct. And that's yet another bug in the Coin port's +aqua variant that needs to be fixed. SoQt's frameworks' install_names are wrong too, but I'm not sure if that's because Coin's are wrong or if it's a separately-fixable instance of the same problem. The Inventor install_name originates with Coin: 'Since Coin is an Open Inventor implementation, the framework is named Inventor, not Coin.' (Coin/Readme.MacOS) However, I did not experience any linking errors when I installed Coin as a framework. SoQt is just a bridge between Qt and Coin. So, to clarify, are you saying this is just a flag that is raised because there isn't a port named 'Inventor'? SoQt installs despite this; is it possible to bypass the 'Scanning binaries for linking errors' phase in the meantime? Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: SoQt linking error on Mavericks (10.9.3)
On 2014-6-27 23:30 , Mark Brethen wrote: On Jun 27, 2014, at 12:45 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 27, 2014, at 12:38 AM, Joshua Root wrote: On 2014-6-27 14:03 , Mark Brethen wrote: After installing Coin, I get the following error with SoQt: --- Found 1 broken file(s), matching files to ports Error: Port SoQt is still broken after rebuilding it more than 3 times. Error: Please run port -d -y rev-upgrade and use the output to report a bug. Running port -d -y rev-upgrade gives: Could not open Inventor.framework/Versions/C/Inventor: Error opening or reading file (referenced from /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib) DEBUG: Marking /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib as broken --- Found 1 broken file(s), matching files to ports Inventor.framework/Versions/C/Inventor is a relative path and so not a suitable install_name. Correct. And that's yet another bug in the Coin port's +aqua variant that needs to be fixed. SoQt's frameworks' install_names are wrong too, but I'm not sure if that's because Coin's are wrong or if it's a separately-fixable instance of the same problem. The Inventor install_name originates with Coin: 'Since Coin is an Open Inventor implementation, the framework is named Inventor, not Coin.' (Coin/Readme.MacOS) However, I did not experience any linking errors when I installed Coin as a framework. SoQt is just a bridge between Qt and Coin. So, to clarify, are you saying this is just a flag that is raised because there isn't a port named 'Inventor'? No, we're saying the install_name needs to be an absolute path, not a relative one. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
SoQt linking error on Mavericks (10.9.3)
After installing Coin, I get the following error with SoQt:
--- Found 1 broken file(s), matching files to ports
Error: Port SoQt is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Running port -d -y rev-upgrade gives:
Could not open Inventor.framework/Versions/C/Inventor: Error opening or reading
file (referenced from
/opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib)
DEBUG: Marking
/opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib
as broken
--- Found 1 broken file(s), matching files to ports
Coin and SoQt were built as frameworks with qt4-mac.
'Inventor.framework/Versions/C/Inventor' is a link to
'Inventor.framework/Versions/C/Libraries/libCoin.60.1.3.dylib'.
From SoQt main.log:
:debug:build Environment:
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_marbre_ports_graphics_SoQt/SoQt/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
There were numerous warnings such as:
:info:build SoQtInputFocus.cpp:64:34: warning: unused parameter 'widget'
[-Wunused-parameter]
:info:build SoQtInputFocus::enable(QWidget * widget, SoQtEventHandler *
handler, void * closure)
and
:info:build ../../../../src/Inventor/Qt/viewers/SoQtViewer.cpp:979:18: warning:
use of logical '' with constant operand [-Wconstant-logical-operand]
:info:build if (SOQT_DEBUG 0) { // debug
:info:build ^ ~
:info:build ../../../../src/Inventor/Qt/viewers/SoQtViewer.cpp:979:18: note:
use '' for a bitwise operation
finally
:info:build /usr/bin/clang++ -dynamiclib -o .libs/libSoQt.20.5.0.dylib
.libs/SoQt.o .libs/SoQtSignalThread.o .libs/SoQtComponent.o
.libs/SoQtGLWidget.o .libs/SoQtImageReader.o .libs/SoAny.o .libs/SoQtCursor.o
.libs/SoQtObject.o .libs/SoQtCommon.o .libs/SoQtComponentCommon.o
.libs/SoQtGLWidgetCommon.o .libs/SoQtRenderArea.o
.libs/libSoQt.lax/libSoQtDevices.a/6DOFEvents.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtDevice.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtDeviceCommon.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtInputFocus.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtInputFocusCommon.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtKeyboard.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtKeyboardCommon.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtMouse.o
.libs/libSoQt.lax/libSoQtDevices.a/SoQtMouseCommon.o
.libs/libSoQt.lax/libSoQtDevices.a/spwinput_win32.o
.libs/libSoQt.lax/libSoQtDevices.a/spwinput_x11.o
.libs/libSoQt.lax/libSoQtEditors.a/SoQtColorEditor.o
.libs/libSoQt.lax/libSoQtEditors.a/SoQtM
aterialEditor.o .libs/libSoQt.lax/libSoGuiEngines.a/Engines.o
.libs/libSoQt.lax/libSoGuiEngines.a/Format.o
.libs/libSoQt.lax/libSoGuiEngines.a/RadioGroup.o
.libs/libSoQt.lax/libSoGuiNodes.a/ClickCounter.o
.libs/libSoQt.lax/libSoGuiNodes.a/ColorEditor.o
.libs/libSoQt.lax/libSoGuiNodes.a/Frame.o
.libs/libSoQt.lax/libSoGuiNodes.a/Image.o
.libs/libSoQt.lax/libSoGuiNodes.a/Label.o
.libs/libSoQt.lax/libSoGuiNodes.a/MaterialEditor.o
.libs/libSoQt.lax/libSoGuiNodes.a/Nodes.o
.libs/libSoQt.lax/libSoGuiNodes.a/Pane.o
.libs/libSoQt.lax/libSoGuiNodes.a/Position.o
.libs/libSoQt.lax/libSoGuiNodes.a/RadioButton.o
.libs/libSoQt.lax/libSoGuiNodes.a/SceneTexture2.o
.libs/libSoQt.lax/libSoGuiNodes.a/Slider1.o
.libs/libSoQt.lax/libSoGuiNodes.a/Slider2.o
.libs/libSoQt.lax/libSoGuiNodes.a/ToggleButton.o
.libs/libSoQt.lax/libSoGuiNodes.a/Translation.o
.libs/libSoQt.lax/libSoGuiNodes.a/ViewpointWrapper.o
.libs/libSoQt.lax/libSoGuiNodes.a/ViewportFix.o
.libs/libSoQt.lax/libSoQtViewers.a/ExaminerV
iewer.o .libs/libSoQt.lax/libSoQtViewers.a/FullViewer.o
.libs/libSoQt.lax/libSoQtViewers.a/PlaneViewer.o
.libs/libSoQt.lax/libSoQtViewers.a/SoQtConstrainedViewer.o
.libs/libSoQt.lax/libSoQtViewers.a/SoQtExaminerViewer.o
.libs/libSoQt.lax/libSoQtViewers.a/SoQtFlyViewer.o
.libs/libSoQt.lax/libSoQtViewers.a/SoQtFullViewer.o
.libs/libSoQt.lax/libSoQtViewers.a/SoQtPlaneViewer.o
.libs/libSoQt.lax/libSoQtViewers.a/SoQtViewer.o
.libs/libSoQt.lax/libSoQtWidgets.a/QtNativePopupMenu.o
.libs/libSoQt.lax/libSoQtWidgets.a/SoAnyThumbWheel.o
.libs/libSoQt.lax/libSoQtWidgets.a/SoQtGLArea.o
.libs/libSoQt.lax/libSoQtWidgets.a/SoQtPopupMenu.o
.libs/libSoQt.lax/libSoQtWidgets.a/SoQtThumbWheel.o -L/opt/local/lib
-lQtOpenGL -lQtGui -lQtCore -arch x86_64 -Wl,-headerpad_max_install_names
-arch x86_64 -Wl,-F/opt/local/Library/Frameworks -Wl,-framework -Wl,Inventor
-Wl,-framework -Wl,OpenGL -install_name
/opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.dylib
-compatibi
lity_version 26 -current_version 26.0 -Wl,-single_module
:info:build dsymutil .libs/libSoQt.20.5.0.dylib || :
:info:build warning: no debug symbols in executable (-arch x86_64)
:info:build (cd .libs rm -f libSoQt.20.dylib ln -s libSoQt.20.5.0.dylib
Re: SoQt linking error on Mavericks (10.9.3)
On Jun 27, 2014, at 12:38 AM, Joshua Root wrote: On 2014-6-27 14:03 , Mark Brethen wrote: After installing Coin, I get the following error with SoQt: --- Found 1 broken file(s), matching files to ports Error: Port SoQt is still broken after rebuilding it more than 3 times. Error: Please run port -d -y rev-upgrade and use the output to report a bug. Running port -d -y rev-upgrade gives: Could not open Inventor.framework/Versions/C/Inventor: Error opening or reading file (referenced from /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib) DEBUG: Marking /opt/local/Library/Frameworks/SoQt.framework/Versions/A/Libraries/libSoQt.20.5.0.dylib as broken --- Found 1 broken file(s), matching files to ports Inventor.framework/Versions/C/Inventor is a relative path and so not a suitable install_name. Correct. And that's yet another bug in the Coin port's +aqua variant that needs to be fixed. SoQt's frameworks' install_names are wrong too, but I'm not sure if that's because Coin's are wrong or if it's a separately-fixable instance of the same problem. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Mavericks buildslave seems to be stuck
It's been working on py-graph-tool for over 26 hours. https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3062 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks buildslave seems to be stuck
Rebooting please standby. Shree On Apr 22, 2014, at 5:22 PM, Joshua Root j...@macports.org wrote: It's been working on py-graph-tool for over 26 hours. https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3062 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks buildslave seems to be stuck
Server is back up now and seems to be building. Let me know if you still see any issues. Shree On Apr 22, 2014, at 5:46 PM, Shreeraj Karulkar skarul...@apple.com wrote: Rebooting please standby. Shree On Apr 22, 2014, at 5:22 PM, Joshua Root j...@macports.org wrote: It's been working on py-graph-tool for over 26 hours. https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3062 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Java on Mavericks buildslave
Can Java please be installed on the Mavericks build slave? The others might need it too. The buildbot failed to build sleuthkit [1] because of this. checking if java works... configure: error: The Java VM java failed (see config.log, check the CLASSPATH?) Cheers! Frank [1] https://build.macports.org/builders/buildports-mavericks-x86_64/builds/1293___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
JVM/JDK is missing on the mavericks buildbot
Hi, it seems there is no JVM/JDK but only the java(c) shims installed on the mavericks buildbot: https://build.macports.org/builders/buildports-mavericks-x86_64/builds/1031/steps/compile/logs/stdio (...) --- Building hamcrest-core DEBUG: Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_mports_dports_java_hamcrest-core/hamcrest-core/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.9' DEBUG: Assembled command: 'cd /opt/local/var/macports/build/_opt_mports_dports_java_hamcrest-core/hamcrest-core/work/hamcrest-1.2 ant core -Dversion=1.2' DEBUG: Executing command line: cd /opt/local/var/macports/build/_opt_mports_dports_java_hamcrest-core/hamcrest-core/work/hamcrest-1.2 ant core -Dversion=1.2 Unable to find any JVMs matching version (null). No Java runtime present, try --request to install. No Java runtime present, requesting install. 2014-01-16 08:24:47.014 java[40610:1107] JLRequestRuntimeInstall: Error calling: CFMessagePortCreateRemote Command failed: cd /opt/local/var/macports/build/_opt_mports_dports_java_hamcrest-core/hamcrest-core/work/hamcrest-1.2 ant core -Dversion=1.2 Exit code: (...) It is possible that we get a JDK on the mavericks buildbot? -- Christoph ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On 2014-01-12 22:23, mk-macpo...@techno.ms wrote: On 12 Jan 2014, at 21:50 , Chris Murphy li...@colorremedies.com wrote: When I say USB device, I meant the interface in qemu that presents USB within the guest. Clearly the linux kernel is finding a USB bus. The command line to start up the VM is — qemu-system-x86_64 -m 2G -cdrom openSUSE-13.1-NET-x86_64.iso -vga std -boot order=dcn os13.1-basis.img You need -usb to activated USB support as it is not a default option. I just booted a GRML [1] live system with this command line into minimal state (no networking): qemu-system-x86_64 -cdrom src/img/grml/grml64-full_2013.09.iso -usb Ignoring all graphical glitches in the console output, the system works and USB is supported. lsusb shows one Linux Foundation 1.1 root hub after booting up. Furthermore, I was able to redirect a USB serial cable with the console command usb_add host:0x67b:0x2303 to the VM. It shows up in lsusb and it created the /dev/ttyUSB0 device that seems to be usable. So, I guess qemu isn’t a true alternative to virtualbox on MacOSX, due to the missing kvm implementation. I see it uses Xen or KVM, but the fact you're getting this far, well past the kernel and initramfs being loaded, seems like it is working. Well, a lot seems to work, indeed. But unfortunately I can’t get beyond the USB device recognition step. Yes, QEMU on Mac OS X is quite slow as it does not get any virtualization support. By the way, the VirtualBox binaries from upstream work just fine on Mavericks. Rainer [1] http://grml.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On 13 Jan 2014, at 09:54 , Rainer Müller rai...@macports.org wrote: You need -usb to activated USB support as it is not a default option. I Oh, I wasn’t aware of that! But well, this didn’t change anything with OpenSUSE 13.1… Yes, QEMU on Mac OS X is quite slow as it does not get any virtualization support. … but well, the missing hardware virtualisation is enough reason to stop this endeavour. By the way, the VirtualBox binaries from upstream work just fine on Mavericks. Well, I wanted to avoid using the upstream binaries, because I like to make sure that nothing stays behind on my system once I upgrade or remove the software. That’s why I like MacPorts. :-) BUT, I guess, this is my only option left now. :-/ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On Jan 13, 2014, at 12:33, mk-macpo...@techno.ms wrote: Well, I wanted to avoid using the upstream binaries, because I like to make sure that nothing stays behind on my system once I upgrade or remove the software. That’s why I like MacPorts. :-) BUT, I guess, this is my only option left now. :-/ Perhaps you could contribute to resolving the MacPorts VirtualBox ticket then. First, try updating the port to the latest version, and submit your patch. If that works, we’re done. If not, you can then report the problem to the developers of VirtualBox for them to fix. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On 14 Jan 2014, at 03:02 , Ryan Schmidt ryandes...@macports.org wrote: Perhaps you could contribute to resolving the MacPorts VirtualBox ticket then. I am afraid my knowledge about setting up a proper virtualbox installation is not sufficient for this endeavour. I tried a while ago though. Ticket #41392 hangs around since 2 months already… I guess I should retry it. :) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
qemu on Mavericks?
I wanted to give qemu a shot - as an alternative for the currently non-functioning virtual box [1] … Anyone out there who’s successfully using qemu on Mavericks? The small test linux image supplied by the qemu folks is running fine, but I am stuck installing OpenSUSE 13.1... Either qemu is horribly slow or it is not able to successfully find USB devices for it at all. :-( Greets, Marko P.S.: qemu likes to use kvm under Linux... Is this not supplied on MacOSX? [1] https://trac.macports.org/ticket/41392 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On 2014-1-13 05:19 , mk-macpo...@techno.ms wrote: I wanted to give qemu a shot - as an alternative for the currently non-functioning virtual box [1] … Anyone out there who’s successfully using qemu on Mavericks? The small test linux image supplied by the qemu folks is running fine, but I am stuck installing OpenSUSE 13.1... Either qemu is horribly slow or it is not able to successfully find USB devices for it at all. :-( Well, it is going to be a lot slower than VirtualBox, as qemu is an emulator under these circumstances. Though there could also be issues with the USB support. P.S.: qemu likes to use kvm under Linux... Is this not supplied on MacOSX? Nope, that's a Linux kernel thing. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
Hi Josh, On 12 Jan 2014, at 19:47 , Joshua Root j...@macports.org wrote: Well, it is going to be a lot slower than VirtualBox, as qemu is an emulator under these circumstances. Though there could also be issues with the USB support. it’s an emulator, because it cannot make use of kvm... P.S.: qemu likes to use kvm under Linux... Is this not supplied on MacOSX? Nope, that's a Linux kernel thing. ;-/ Well, I waited for ages, but OpenSUSE’s USB probing never came back. :( When I booted using its rescue system and carried out lsusb I got this message: — $ lsusb unable to initialize libusb: -99 — Don’t know though whether this was due to the rescue system itself or due to a the qemu emulation. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On Jan 12, 2014, at 12:26 PM, mk-macpo...@techno.ms wrote: Hi Josh, On 12 Jan 2014, at 19:47 , Joshua Root j...@macports.org wrote: Well, it is going to be a lot slower than VirtualBox, as qemu is an emulator under these circumstances. Though there could also be issues with the USB support. it’s an emulator, because it cannot make use of kvm... P.S.: qemu likes to use kvm under Linux... Is this not supplied on MacOSX? Nope, that's a Linux kernel thing. ;-/ Well, I waited for ages, but OpenSUSE’s USB probing never came back. :( When I booted using its rescue system and carried out lsusb I got this message: — $ lsusb unable to initialize libusb: -99 — Don’t know though whether this was due to the rescue system itself or due to a the qemu emulation. It wouldn't surprise me if by default qemu uses a paravirtualized USB port which expects a paravirt driver on the host, which of course OS X will not have. So I think you need to remove the USB device in the qemu guest and see if that works. If it does, then you can see about added the non-paravirtualized USB port to the guest, which ought to work. Chris Murphy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On 12 Jan 2014, at 20:31 , Chris Murphy li...@colorremedies.com wrote: So I think you need to remove the USB device in the qemu guest and see if that works. Chris, so far I am not trying to use any USB device. I am just trying to install OpenSUSE using an ISO file… Well, and the installation procedure is searching for USB devices FOREVER, unfortunately. So, I guess qemu isn’t a true alternative to virtualbox on MacOSX, due to the missing kvm implementation. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
permission denied errors during building with clang on Mavericks
Hi devs, I am trying to build some software using standard clang on Mavericks and I see errors due to denied permissions like this: — :info:build libtool: compile: /usr/bin/clang -DHAVE_CONFIG_H -DBUILDING_AQDATABASE -DLOCALEDIR=\/opt/local/share/locale\ -DAQDATABASE_PLUGINS=\/opt/local/lib/aqdatabase/plugins/0\ -DAQDATABASE_DATA_DIR=\/opt/local/share/aqdatabase\ -DCOMPILE_DATETIME=\20140112203526\ -I. -I../.. -I../.. -I/opt/local/include/gwenhywfar4 -I/opt/local/include -L/opt/local/lib -pipe -Os -L/opt/local/lib -arch x86_64 -g -Wall -c aqdb_db.c :info:build clang: error: couldn't create cache file '/var/folders/wy/5396pzbj3gq7s1hwf2shczvmgq/T/xcrun_db-CfooCvW7' (errno=Permission denied) :info:build clang: warning: argument unused during compilation: '-L/opt/local/lib' :info:build clang: warning: argument unused during compilation: '-L/opt/local/lib’ :info:build In file included from aqdb_db.c:14: :info:build In file included from ./aqdb_db_p.h:14: :info:build ./aqdb_db_be.h:14:10: fatal error: 'aqdatabase/aqdb_db.h' file not found :info:build #include aqdatabase/aqdb_db.h :info:build ^ :info:build 1 error generated. :info:build make[3]: *** [aqdb_db.lo] Error 1 — I figure that these missing cache files don’t stop clang from working correctly, but I wonder why this permission error occurs. Is my portfile wrongly set up for clang for some reason? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On Jan 12, 2014, at 12:44 PM, mk-macpo...@techno.ms wrote: On 12 Jan 2014, at 20:31 , Chris Murphy li...@colorremedies.com wrote: So I think you need to remove the USB device in the qemu guest and see if that works. Chris, so far I am not trying to use any USB device. When I say USB device, I meant the interface in qemu that presents USB within the guest. Clearly the linux kernel is finding a USB bus. I am just trying to install OpenSUSE using an ISO file… Well, and the installation procedure is searching for USB devices FOREVER, unfortunately. I'd expect this. Delete the USB interface for the virtual machine you've created with qemu. So, I guess qemu isn’t a true alternative to virtualbox on MacOSX, due to the missing kvm implementation. I see it uses Xen or KVM, but the fact you're getting this far, well past the kernel and initramfs being loaded, seems like it is working. Chris Murphy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On 12 Jan 2014, at 21:50 , Chris Murphy li...@colorremedies.com wrote: When I say USB device, I meant the interface in qemu that presents USB within the guest. Clearly the linux kernel is finding a USB bus. The command line to start up the VM is — qemu-system-x86_64 -m 2G -cdrom openSUSE-13.1-NET-x86_64.iso -vga std -boot order=dcn os13.1-basis.img — and there are two USB devices present after booting up. Both devices I CAN NOT remove using “usb_del” !! ( Interesting also that qemu actually hands over the machine's eyetv stick to the VM!!! ) Back to square one. :-( Well, and the installation procedure is searching for USB devices FOREVER, unfortunately. I'd expect this. Delete the USB interface for the virtual machine you've created with qemu. It’s to be expected? Oh… So, I guess qemu isn’t a true alternative to virtualbox on MacOSX, due to the missing kvm implementation. I see it uses Xen or KVM, but the fact you're getting this far, well past the kernel and initramfs being loaded, seems like it is working. Well, a lot seems to work, indeed. But unfortunately I can’t get beyond the USB device recognition step. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
OK, now I found out using “info usb” that USB support is NOT enabled by default. So, perhaps that is the problem? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: qemu on Mavericks?
On Jan 12, 2014, at 2:29 PM, mk-macpo...@techno.ms wrote: OK, now I found out using “info usb” that USB support is NOT enabled by default. So, perhaps that is the problem? Maybe. Try adding -usbdevice tablet to the qemu command line. http://wiki.qemu.org/download/qemu-doc.html#pcsys_005fusb Chris Murphy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: permission denied errors during building with clang on Mavericks
On 12 Jan 2014, at 23:59 , Clemens Lang wrote: I've that a few times now and it seems to be a problem with permissions on the cache directory mentioned in the error message. Unfortunately it doesn't abort but it seems it can still lead to miscompiled code and performance degradation. I recommend you delete the cache directory entirely Thanks, Clemens, for the hint. I did so and it has solved the issue: markos-imac:5396pzbj3gq7s1hwf2shczvmgq marko$ l total 0 drwxr-xr-x 4 macports macports 136 Jan 13 00:04 ./ drwxr-xr-x 3 root wheel 102 Jan 13 00:04 ../ drwx-- 6 macports macports 204 Jan 13 00:05 C/ drwx-- 5 macports macports 170 Jan 13 00:04 T/ Before I had the user root set for the subfolder T, which obviously caused the issue. Greets, Marko___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
On Jan 1, 2014, at 19:00, Blair Zajac wrote: On Jan 1, 2014, at 3:31 PM, Ryan Schmidt wrote: On Jan 1, 2014, at 16:27, Blair Zajac wrote: I guess a better way is to ensure the build doesn’t pick up stuff in $prefix/include. Does the patch from #40656 help? No, it doesn’t. Comparing the 'clang -E’ output between a good and a bad build, the good build is picking up /usr/include/db.h, which is where dbopen() is defined. In this case, we want the tool to find the old db.h. Seems weird that building bdb requires an old version of db.h to be installed… ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
On 2014-1-2 21:04 , Ryan Schmidt wrote: On Jan 1, 2014, at 19:00, Blair Zajac wrote: On Jan 1, 2014, at 3:31 PM, Ryan Schmidt wrote: On Jan 1, 2014, at 16:27, Blair Zajac wrote: I guess a better way is to ensure the build doesn’t pick up stuff in $prefix/include. Does the patch from #40656 help? No, it doesn’t. Comparing the 'clang -E’ output between a good and a bad build, the good build is picking up /usr/include/db.h, which is where dbopen() is defined. In this case, we want the tool to find the old db.h. Seems weird that building bdb requires an old version of db.h to be installed… Only if you build dump185. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
db46 compile failure on mavericks
Hi Jeremy,
I’m now getting this compile failure on the db46 port.
Regards,
Blair
/usr/bin/clang++ -c -I.
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/..
-I/opt/local/include -pipe -Os -arch x86_64
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../cxx/cxx_txn.cpp
-fno-common -DPIC -o .libs/cxx_txn.o
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:211:13:
warning: implicit declaration of function 'dbopen' is invalid in C99
[-Wimplicit-function-declaration]
if ((dbp = dbopen(argv[0], O_RDONLY, 0, DB_BTREE, NULL)) == NULL) {
^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:211:11:
warning: incompatible integer to pointer conversion assigning to 'DB *' (aka
'struct __db *') from 'int' [-Wint-conversion]
if ((dbp = dbopen(argv[0], O_RDONLY, 0, DB_BTREE, NULL)) == NULL) {
^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:212:12:
warning: incompatible integer to pointer conversion assigning to 'DB *' (aka
'struct __db *') from 'int' [-Wint-conversion]
if ((dbp =
^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:228:24:
error: no member named 'seq' in 'struct __db'
while (!(rval = dbp-seq(dbp, key, data, R_NEXT))) {
~~~ ^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:228:46:
error: use of undeclared identifier 'R_NEXT'
while (!(rval = dbp-seq(dbp, key, data, R_NEXT))) {
^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:233:24:
error: no member named 'seq' in 'struct __db'
while (!(rval = dbp-seq(dbp, key, data, R_NEXT))) {
~~~ ^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:233:46:
error: use of undeclared identifier 'R_NEXT'
while (!(rval = dbp-seq(dbp, key, data, R_NEXT))) {
^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:261:18:
error: no member named 'internal' in 'struct __db'
hash185p = dbp-internal;
~~~ ^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:263:19:
error: no member named 'internal' in 'struct __db'
hash186p = dbp-internal;
~~~ ^
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:288:13:
error: no member named 'internal' in 'struct __db'
btp = dbp-internal;
~~~ ^
3 warnings and 7 errors generated.
make: *** [db_dump185.lo] Error 1
make: *** Waiting for unfinished jobs….
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
On Jan 1, 2014, at 15:15, Blair Zajac wrote: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:228:24: error: no member named 'seq' in 'struct __db' Same problem reported here: https://trac.macports.org/ticket/41350 Also here: https://trac.macports.org/ticket/35570 Same here: https://trac.macports.org/ticket/18113 Do you have an old version of db.h in /opt/local/include or /usr/local/include? It's also mentioned here: https://trac.macports.org/ticket/38665 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
[cc’ing and.dam...@macports.org for db_select] On Jan 1, 2014, at 1:30 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jan 1, 2014, at 15:15, Blair Zajac wrote: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:228:24: error: no member named 'seq' in 'struct __db' Same problem reported here: https://trac.macports.org/ticket/41350 Also here: https://trac.macports.org/ticket/35570 Same here: https://trac.macports.org/ticket/18113 Do you have an old version of db.h in /opt/local/include or /usr/local/include? I don’t have a /usr/local. There was only the previous version of db46 and db46-java installed previously. Looking at the build, it is picking up db.h from db_select: /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/db46/work/db-4.6.21/build_unix# /usr/bin/clang -E -pipe -Os -arch x86_64 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/.. -I/opt/local/include /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c -fno-common -DPIC|grep ^# | grep /opt/local # 1 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c # 1 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 10 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c # 15 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 17 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 18 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 19 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 20 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 21 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 22 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c 2 # 1 /opt/local/include/db.h 1 # 25 /opt/local/include/db.h # 26 /opt/local/include/db.h 2 # 28 /opt/local/include/db.h 2 # 30 /opt/local/include/db.h 2 # 31 /opt/local/include/db.h 2 # 110 /opt/local/include/db.h” Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
On Jan 1, 2014, at 1:55 PM, Blair Zajac bl...@orcaware.com wrote: [cc’ing and.dam...@macports.org for db_select] On Jan 1, 2014, at 1:30 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jan 1, 2014, at 15:15, Blair Zajac wrote: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/db46/work/db-4.6.21/dist/../db_dump185/db_dump185.c:228:24: error: no member named 'seq' in 'struct __db' Same problem reported here: https://trac.macports.org/ticket/41350 Also here: https://trac.macports.org/ticket/35570 Same here: https://trac.macports.org/ticket/18113 Do you have an old version of db.h in /opt/local/include or /usr/local/include? I don’t have a /usr/local. There was only the previous version of db46 and db46-java installed previously. Looking at the build, it is picking up db.h from db_select: Doing a ‘port select db none’ before the upgrade got the build to work. Is there a way to check if a selection is enabled? I guess a better way is to ensure the build doesn’t pick up stuff in $prefix/include. Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
On Jan 1, 2014, at 16:27, Blair Zajac wrote: I guess a better way is to ensure the build doesn’t pick up stuff in $prefix/include. Does the patch from #40656 help? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
On Jan 1, 2014, at 3:31 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jan 1, 2014, at 16:27, Blair Zajac wrote: I guess a better way is to ensure the build doesn’t pick up stuff in $prefix/include. Does the patch from #40656 help? No, it doesn’t. Comparing the 'clang -E’ output between a good and a bad build, the good build is picking up /usr/include/db.h, which is where dbopen() is defined. In this case, we want the tool to find the old db.h. I tried adding -I/usr/include to the build: DB185INC= -c -pipe -Os -arch x86_64 -I/usr/include -I$(srcdir) -I/opt/local/include but that didn’t work. How to make sure that /usr/include is picked up first? I even tried doing ‘ln -s /usr/include iii’ and adding -Iiii but clang ignores it also. Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: db46 compile failure on mavericks
On 2014-1-2 12:00 , Blair Zajac wrote: On Jan 1, 2014, at 3:31 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jan 1, 2014, at 16:27, Blair Zajac wrote: I guess a better way is to ensure the build doesn’t pick up stuff in $prefix/include. Does the patch from #40656 help? No, it doesn’t. Comparing the 'clang -E’ output between a good and a bad build, the good build is picking up /usr/include/db.h, which is where dbopen() is defined. In this case, we want the tool to find the old db.h. I tried adding -I/usr/include to the build: DB185INC= -c -pipe -Os -arch x86_64 -I/usr/include -I$(srcdir) -I/opt/local/include but that didn’t work. How to make sure that /usr/include is picked up first? I even tried doing ‘ln -s /usr/include iii’ and adding -Iiii but clang ignores it also. I don't think you can. The gcc man page says: -I dir Add the directory dir to the list of directories to be searched for header files. Directories named by -I are searched before the standard system include directories. If the directory dir is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated . You might need to put the desired header in the build dir, or make a db185 (or just db185-headers) port. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Mavericks gstreamer010 binary package missing some files
Hi I was helping a colleague debug a build issue this afternoon and I found what seemed to be the problem. He had installed gstreamer010, on his Mavericks system, using the binary package and was getting a build error: Couldn't find include 'Gst-0.10.gir' (search path: ['.', 'gir-1.0', '/opt/local/share/gir-1.0', '/usr/share/gir-1.0', '/opt/local/share/gir-1.0']) when trying to build our collaboration software. I was able to build the same software without issue. I finally found that the only difference between our systems is that I'd configured MacPorts using buildfromsource always when he was using buildfromsource ifneeded When I build gstreamer010 from source I get a /opt/local/share/gir-1.0 directory containing various files: $ port contents gstreamer010 | grep gir-1.0 /opt/local/share/gir-1.0/Gst-0.10.gir /opt/local/share/gir-1.0/GstBase-0.10.gir /opt/local/share/gir-1.0/GstCheck-0.10.gir /opt/local/share/gir-1.0/GstController-0.10.gir /opt/local/share/gir-1.0/GstNet-0.10.gir $ but these are not present in the Mavericks package $ wget -q http://packages.macports.org/gstreamer010/gstreamer010-0.10.36_0.darwin_13.x86_64.tbz2 $ tar -tf gstreamer010-0.10.36_0.darwin_13.x86_64.tbz2 | grep gir-1.0 $ They do exist in all the other packages, just not for Mavericks. Does anyone understand why this would be the case? Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks gstreamer010 binary package missing some files
On Dec 17, 2013, at 21:09, Adam Mercer wrote: I was helping a colleague debug a build issue this afternoon and I found what seemed to be the problem. He had installed gstreamer010, on his Mavericks system, using the binary package and was getting a build error: Couldn't find include 'Gst-0.10.gir' (search path: ['.', 'gir-1.0', '/opt/local/share/gir-1.0', '/usr/share/gir-1.0', '/opt/local/share/gir-1.0']) when trying to build our collaboration software. I was able to build the same software without issue. I finally found that the only difference between our systems is that I'd configured MacPorts using buildfromsource always when he was using buildfromsource ifneeded When I build gstreamer010 from source I get a /opt/local/share/gir-1.0 directory containing various files: $ port contents gstreamer010 | grep gir-1.0 /opt/local/share/gir-1.0/Gst-0.10.gir /opt/local/share/gir-1.0/GstBase-0.10.gir /opt/local/share/gir-1.0/GstCheck-0.10.gir /opt/local/share/gir-1.0/GstController-0.10.gir /opt/local/share/gir-1.0/GstNet-0.10.gir $ but these are not present in the Mavericks package $ wget -q http://packages.macports.org/gstreamer010/gstreamer010-0.10.36_0.darwin_13.x86_64.tbz2 $ tar -tf gstreamer010-0.10.36_0.darwin_13.x86_64.tbz2 | grep gir-1.0 $ They do exist in all the other packages, just not for Mavericks. They are also missing on my Mavericks build from source system. Usually, missing files are because of an undeclared optional dependency that, when present, results in those files being created. In this case, I think that dependency is gobject-introspection. The dependency should be added, and the revision should be increased to rebuild the port. Any time you add gobject-introspection support, you have to switch the build command to gmake and add a gmake build dependency on Tiger, because the version of make its Xcode ships with is too old. See any other port using gobject-introspection for a block you can copy to do that. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks gstreamer010 binary package missing some files
On Tue, Dec 17, 2013 at 9:32 PM, Ryan Schmidt ryandes...@macports.org wrote: Any time you add gobject-introspection support, you have to switch the build command to gmake and add a gmake build dependency on Tiger, because the version of make its Xcode ships with is too old. See any other port using gobject-introspection for a block you can copy to do that. Thanks Ryan, I'll get a patch prepared. Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks gstreamer010 binary package missing some files
On Tue, Dec 17, 2013 at 9:32 PM, Ryan Schmidt ryandes...@macports.org wrote:
Any time you add gobject-introspection support, you have to switch the build
command to gmake and add a gmake build dependency on Tiger, because the
version of make its Xcode ships with is too old. See any other port using
gobject-introspection for a block you can copy to do that.
So you mean something like the following:
--- a/gnome/gstreamer010/Portfile
+++ b/gnome/gstreamer010/Portfile
@@ -10,6 +10,7 @@ PortGroup muniversal 1.0
namegstreamer010
set my_name gstreamer
version 0.10.36
+revision1
description \
GStreamer is a library for constructing graphs of media-handling components
long_description \
@@ -41,7 +42,8 @@ depends_lib \
port:flex \
port:gettext \
path:lib/pkgconfig/glib-2.0.pc:glib2 \
-port:libxml2
+port:libxml2 \
+port:gobject-introspection
use_bzip2 yes
@@ -69,4 +71,14 @@ if {[variant_isset universal]} {
--build=${build_arch}-apple-${os.platform}${os.major}
}
+# The rules enabled by gobject-introspection require GNU make 3.81+, #35200
+platform darwin 8 {
+depends_build-appendport:gmake
+build.cmd ${prefix}/bin/gmake
+}
+
+# gobject-introspection uses g-ir-scanner, which uses $CC from env
+build.args-append CC=${configure.cc} ${configure.cc_archflags}
+destroot.args-appendCC=${configure.cc} ${configure.cc_archflags}
+
livecheck.type none
It seems like the gstreamer1 port already has something similar to
this, apart the from platform darwin 8 block.
Cheers
Adam
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks gstreamer010 binary package missing some files
On Dec 17, 2013, at 21:45, Adam Mercer r...@macports.org wrote:
On Tue, Dec 17, 2013 at 9:32 PM, Ryan Schmidt ryandes...@macports.org wrote:
Any time you add gobject-introspection support, you have to switch the build
command to gmake and add a gmake build dependency on Tiger, because the
version of make its Xcode ships with is too old. See any other port using
gobject-introspection for a block you can copy to do that.
So you mean something like the following:
--- a/gnome/gstreamer010/Portfile
+++ b/gnome/gstreamer010/Portfile
@@ -10,6 +10,7 @@ PortGroup muniversal 1.0
namegstreamer010
set my_name gstreamer
version 0.10.36
+revision1
description \
GStreamer is a library for constructing graphs of media-handling
components
long_description \
@@ -41,7 +42,8 @@ depends_lib \
port:flex \
port:gettext \
path:lib/pkgconfig/glib-2.0.pc:glib2 \
-port:libxml2
+port:libxml2 \
+port:gobject-introspection
use_bzip2 yes
@@ -69,4 +71,14 @@ if {[variant_isset universal]} {
--build=${build_arch}-apple-${os.platform}${os.major}
}
+# The rules enabled by gobject-introspection require GNU make 3.81+, #35200
+platform darwin 8 {
+depends_build-appendport:gmake
+build.cmd ${prefix}/bin/gmake
+}
+
+# gobject-introspection uses g-ir-scanner, which uses $CC from env
+build.args-append CC=${configure.cc} ${configure.cc_archflags}
+destroot.args-appendCC=${configure.cc} ${configure.cc_archflags}
+
livecheck.type none
Yes, that should be it, just like that. When I add this platform darwin 8 block
to ports, I update the ticket reference to the ticket specific to this port,
or, since I don’t think there is one for this port, you could just remove the
ticket reference.
It seems like the gstreamer1 port already has something similar to
this, apart the from platform darwin 8 block.
I’m considering just making gmake the default make program for Tiger, given how
ubiquitous gobject-introspection is becoming… but until then, probably this
block is needed in gstreamer1 as well.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks gstreamer010 binary package missing some files
On Tue, Dec 17, 2013 at 9:53 PM, Ryan Schmidt ryandes...@macports.org wrote: Yes, that should be it, just like that. When I add this platform darwin 8 block to ports, I update the ticket reference to the ticket specific to this port, or, since I don’t think there is one for this port, you could just remove the ticket reference. Thanks: #41843 I’m considering just making gmake the default make program for Tiger, given how ubiquitous gobject-introspection is becoming… but until then, probably this block is needed in gstreamer1 as well. #41844 Cheers Adam ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Mavericks buildbot issue with dbus
I'm getting the following back when it tries to build a port that
depends on dbus:
{{{
Error: org.macports.activate for port dbus returned: could not set owner
for file /opt/local/var/run/dbus: user messagebus; does not exist
}}}
The dbus port contains the following code:
{{{
set dbus_user messagebus
set dbus_groupmessagebus
add_users ${dbus_user} group=${dbus_group} realname=Message\ Bus
set startup_root
}}}
Anyone have an idea what to do to fix this? - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks java recipe?
On Nov 15, 2013, at 14:04, Daniel J. Luke wrote: Before I do more work on #41378, I figured that I'd ask and see if anyone has worked up a nice recipe for detecting a java install on Mavericks yet? I'd like the subversion-javahlbindings port to be able to warn people and exit early if the appropriate java bits aren't present and I imagine other ports might want the same thing (possibly a candidate for a portgroup, too). We already have a java portgroup… is that for this, or for something else? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks java recipe?
Am 16.11.13 22:46, schrieb Ryan Schmidt: On Nov 15, 2013, at 14:04, Daniel J. Luke wrote: Before I do more work on #41378, I figured that I'd ask and see if anyone has worked up a nice recipe for detecting a java install on Mavericks yet? I'd like the subversion-javahlbindings port to be able to warn people and exit early if the appropriate java bits aren't present and I imagine other ports might want the same thing (possibly a candidate for a portgroup, too). We already have a java portgroup… is that for this, or for something else? Currently the java portgroup just tries various methods to find a JAVA_HOME and set it for configure.env, build.env and destroot.env. It does not detect if a JRE or JDK is installed nor does it exit if it can't find a suitable JAVA_HOME. -- Christoph ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks java recipe?
On Nov 16, 2013, at 2:45 PM, Christoph Iserlohn ciserl...@macports.org wrote: Am 16.11.13 22:46, schrieb Ryan Schmidt: On Nov 15, 2013, at 14:04, Daniel J. Luke wrote: Before I do more work on #41378, I figured that I'd ask and see if anyone has worked up a nice recipe for detecting a java install on Mavericks yet? I'd like the subversion-javahlbindings port to be able to warn people and exit early if the appropriate java bits aren't present and I imagine other ports might want the same thing (possibly a candidate for a portgroup, too). We already have a java portgroup… is that for this, or for something else? Currently the java portgroup just tries various methods to find a JAVA_HOME and set it for configure.env, build.env and destroot.env. It does not detect if a JRE or JDK is installed nor does it exit if it can't find a suitable JAVA_HOME. The java port group could stand to be enhanced. Among its lesser sins, it looks repeated for JAVA_HOME rather than looking once and caching that result. In any event, I think this code would be a place to start for enhancement: it’s so simplistic now that there shouldn’t be too much risk of breaking ports that use it. James ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Mavericks java recipe?
Before I do more work on #41378, I figured that I'd ask and see if anyone has worked up a nice recipe for detecting a java install on Mavericks yet? I'd like the subversion-javahlbindings port to be able to warn people and exit early if the appropriate java bits aren't present and I imagine other ports might want the same thing (possibly a candidate for a portgroup, too). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks java recipe?
On Nov 15, 2013, at 3:04 PM, Daniel J. Luke dl...@geeklair.net wrote: Before I do more work on #41378, I figured that I'd ask and see if anyone has worked up a nice recipe for detecting a java install on Mavericks yet? I'd like the subversion-javahlbindings port to be able to warn people and exit early if the appropriate java bits aren't present and I imagine other ports might want the same thing (possibly a candidate for a portgroup, too). I don't have a Mavericks system yet, but /usr/libexec/java_home always exists on Mountain Lion, even if no JVM is installed. If a JVM is available, /usr/libexec/java_home --failfast returns 0 and prints the appropriate $JAVA_HOME; otherwise, it returns 1 and prints nothing. % /usr/libexec/java_home -F /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home % echo $? 0 Testing for a whole JDK might be subtly different than just testing for a JVM; I'm not sure. Perhaps you could grep for jdk in the output. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #40852: qt4-mac does not build on OS X 10.9 Mavericks or later
https://trac.macports.org/ticket/40852#comment:101 Does anyone know why the binary library isn't part of the rsync tarball? It's coming in through SVN just fine ... Do I need to have a separate download for it, not just a patchfile? - MLD On Fri, Nov 1, 2013, at 10:56 PM, MacPorts wrote: #40852: qt4-mac does not build on OS X 10.9 Mavericks or later OK; thanks. The file libWebKitSysteminterfaceMavericks.a is indeed not part of the rsync tarball. I'll query the list as to what the best way is to get binary files like this one inserted into a build. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #40852: qt4-mac does not build on OS X 10.9 Mavericks or later
On Nov 1, 2013, at 22:00, Michael Dickens michae...@macports.org wrote: https://trac.macports.org/ticket/40852#comment:101 Does anyone know why the binary library isn't part of the rsync tarball? It's coming in through SVN just fine ... Do I need to have a separate download for it, not just a patchfile? - MLD I don’t know why it doesn’t work. Perhaps the process that creates the ports tarball for the rsync server excludes it by some criteria. But it’s unexpected that you would put a binary in the files directory. The files directory is meant to store small patches, not huge binaries. Remember that the files directory will be downloaded by all users, even those not using this port, so it should be kept as small as possible. If this binary is needed and cannot be built from the sources, then yes, I’d recommend uploading a compressed version of it somewhere and making the port download it when needed. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #40852: qt4-mac does not build on OS X 10.9 Mavericks or later
Probably because rsync's -C option gets used at one point. But a half meg file in the ports tree isn't a great idea to begin with. Is it really impossible to build from source *and* unavailable for download anywhere? On 2013-11-2 14:00 , Michael Dickens wrote: https://trac.macports.org/ticket/40852#comment:101 Does anyone know why the binary library isn't part of the rsync tarball? It's coming in through SVN just fine ... Do I need to have a separate download for it, not just a patchfile? - MLD On Fri, Nov 1, 2013, at 10:56 PM, MacPorts wrote: #40852: qt4-mac does not build on OS X 10.9 Mavericks or later OK; thanks. The file libWebKitSysteminterfaceMavericks.a is indeed not part of the rsync tarball. I'll query the list as to what the best way is to get binary files like this one inserted into a build. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #40852: qt4-mac does not build on OS X 10.9 Mavericks or later
On 11/01/2013 08:39 PM, Joshua Root wrote: Probably because rsync's -C option gets used at one point. But a half meg file in the ports tree isn't a great idea to begin with. Is it really impossible to build from source *and* unavailable for download anywhere? I agree. Where is the source? Where and how was it built? Maybe it needs its own port that qt4-mac can depend upon for 10.9. Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #40852: qt4-mac does not build on OS X 10.9 Mavericks or later
On 2013-11-2 14:41 , Blair Zajac wrote: On 11/01/2013 08:39 PM, Joshua Root wrote: Probably because rsync's -C option gets used at one point. But a half meg file in the ports tree isn't a great idea to begin with. Is it really impossible to build from source *and* unavailable for download anywhere? I agree. Where is the source? Where and how was it built? Maybe it needs its own port that qt4-mac can depend upon for 10.9. And also very importantly, what license is it under? I don't see any copyright notices being reproduced, which would be in violation of most open source licenses. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
clang-3.2 and earlier on Mavericks
Why are clang-3.2 and earlier not supported on Mavericks? This is inconvenient. It was very convenient to be able to install all versions of clang from 2.9 thru current on Mountain Lion, so that when bugs were reported on older Xcode versions I could simulate their environment without needing to change mine by changing configure.compiler to an earlier clang. Now to test for this I have to leave my primary machine and boot up another machine or VM with an earlier OS X version. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: clang-3.2 and earlier on Mavericks
On Oct 23, 2013, at 23:46, Ryan Schmidt ryandes...@macports.org wrote: Why are clang-3.2 and earlier not supported on Mavericks? This is inconvenient. It was very convenient to be able to install all versions of clang from 2.9 thru current on Mountain Lion, so that when bugs were reported on older Xcode versions I could simulate their environment without needing to change mine by changing configure.compiler to an earlier clang. Now to test for this I have to leave my primary machine and boot up another machine or VM with an earlier OS X version. They don't handle the 10.9 deployment target correctly. I think 3.3 may not as well and will require some patching. Using OSS versions of clang doesn't really simulate older Xcode clang versions. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: clang-3.2 and earlier on Mavericks
On Oct 24, 2013, at 0:19, Ryan Schmidt ryandes...@macports.org wrote: On Oct 24, 2013, at 02:09, Jeremy Huddleston Sequoia wrote: Using OSS versions of clang doesn't really simulate older Xcode clang versions. I realize they are not identical but I have successfully used this technique multiple times to reproduce issues users experienced with older versions of Xcode clang and to develop fixes. Also I would like for llvm-3.2 to exist on Mavericks because my port pure requires it; pure does not work properly on OS X when using llvm-3.3 and after discussion with the developer we decided to leave MacPorts pure at llvm-3.2. https://groups.google.com/forum/#!searchin/pure-lang/pure-gen/pure-lang/JelRk7YHEug/upS-XGboNT8J In the last message of the thread, the developer of pure declared this to be “a genuine incompatibility between the x86 assembler backend in LLVM 3.3 and at least some Xcode versions, and no fix is known right now.” And without any radar of bug report at llvm.org (at least not any referenced in that thread), it's quite unlikely that any progress would ever be made on fixing such a bug... Could you followup with that thread to see if the pure developer ever got around to reporting this genuine incompatibility between the x86 assembler backend in LLVM 3.3 and at least some Xcode versions And I'll see about backporting the 10.9 deployment target patches to 3.2 when I get some cycles next week. I think the main issue is just the switch to libc++ default. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Should you upgrade to Mavericks?
Moved to DEV On Oct 23, 2013, at 9:24 PM, Ryan Schmidt ryandes...@macports.org wrote: At this time, MacPorts does not offer a pre-compiled release for Mavericks. You can build MacPorts trunk from source and it appears to work on Mavericks. We will try to make a new release soon. so, you've been telling a bunch of people to use trunk - what's fixed in trunk that's broken in the latest release? I rebuilt the latest release (selfupdate -f) and ran port upgrade outdated and have 694 ports that look like they rebuild successfully :) [yes, I know that I didn't follow the migration instructions, but I'm prepared to fix anything that is broken] -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Should you upgrade to Mavericks?
On Thu, Oct 24, 2013 at 10:05:50AM -0400, Daniel J. Luke wrote: so, you've been telling a bunch of people to use trunk - what's fixed in trunk that's broken in the latest release? http://trac.macports.org/changeset/110985 That's pretty much the only change related to Mavericks on the release branch for 2.2.1 at the moment. A couple of other changes for 2.2.1 are documented in http://trac.macports.org/changeset/112486/branches/release_2_2/base but those aren't strictly required for Mavericks. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Should you upgrade to Mavericks?
On 2013-10-25 01:05 , Daniel J. Luke wrote: Moved to DEV On Oct 23, 2013, at 9:24 PM, Ryan Schmidt ryandes...@macports.org wrote: At this time, MacPorts does not offer a pre-compiled release for Mavericks. You can build MacPorts trunk from source and it appears to work on Mavericks. We will try to make a new release soon. so, you've been telling a bunch of people to use trunk - what's fixed in trunk that's broken in the latest release? I rebuilt the latest release (selfupdate -f) and ran port upgrade outdated and have 694 ports that look like they rebuild successfully :) [yes, I know that I didn't follow the migration instructions, but I'm prepared to fix anything that is broken] Yeah, I'd really rather not encourage users to install trunk, since all too often that means they keep running some random trunk revision and miss out on new base versions because selfupdate sees e.g. 2.2.99 2.2.1. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.2 on Mavericks
Joshua Root j...@macports.org wrote: Please use MacPorts trunk for Mavericks; MacPorts 2.2.0 is not supported on Mavericks. People keep saying that, but what are the actual problems with 2.2? I have just installed a fresh MacPorts 2.2.0 on Mavericks. So far, no problem. Except that atlas didn't compile (gnutar not found in the log). So I installed the gnutar port, and now atlas seems to be compiling fine so far. -- http://www.juliensalort.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.2 on Mavericks
On 2013-10-25 01:44 , Julien Salort wrote: Joshua Root j...@macports.org wrote: Please use MacPorts trunk for Mavericks; MacPorts 2.2.0 is not supported on Mavericks. People keep saying that, but what are the actual problems with 2.2? I have just installed a fresh MacPorts 2.2.0 on Mavericks. So far, no problem. Except that atlas didn't compile (gnutar not found in the log). So I installed the gnutar port, and now atlas seems to be compiling fine so far. Right, that's a problem with the atlas port. It defines a custom extract phase and runs gnutar specifically. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
2.2 on Mavericks
#40843: Cannot install ncurses with OS X mavericks -+--- Reporter: feranick@… | Owner: jmr@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports |Version: 2.2.0 Resolution: | Keywords: Port: ncurses | -+--- Changes (by ryandesign@…): Comment: Please use MacPorts trunk for Mavericks; MacPorts 2.2.0 is not supported on Mavericks. People keep saying that, but what are the actual problems with 2.2? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.2 on Mavericks
On Oct 23, 2013, at 05:25, Joshua Root j...@macports.org wrote: #40843: Cannot install ncurses with OS X mavericks -+--- Reporter: feranick@… | Owner: jmr@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports |Version: 2.2.0 Resolution: | Keywords: Port: ncurses | -+--- Changes (by ryandesign@…): Comment: Please use MacPorts trunk for Mavericks; MacPorts 2.2.0 is not supported on Mavericks. People keep saying that, but what are the actual problems with 2.2? Well, there’s the gnutar-does-not-exist problem. I thought perhaps this was people installing the Mountain Lion binary on Mavericks, but our installer prohibits that. Perhaps it’s people installing MacPorts on Mountain Lion, then upgrading to Mavericks without reinstalling MacPorts, like the Migration page says to do. Then there’s the libstdc++ vs stdc++ situation which IIRC only trunk addresses. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.2 on Mavericks
On 2013-10-23 23:00 , Ryan Schmidt wrote: On Oct 23, 2013, at 05:25, Joshua Root j...@macports.org wrote: #40843: Cannot install ncurses with OS X mavericks -+--- Reporter: feranick@… | Owner: jmr@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports |Version: 2.2.0 Resolution: | Keywords: Port: ncurses | -+--- Changes (by ryandesign@…): Comment: Please use MacPorts trunk for Mavericks; MacPorts 2.2.0 is not supported on Mavericks. People keep saying that, but what are the actual problems with 2.2? Well, there’s the gnutar-does-not-exist problem. I thought perhaps this was people installing the Mountain Lion binary on Mavericks, but our installer prohibits that. Perhaps it’s people installing MacPorts on Mountain Lion, then upgrading to Mavericks without reinstalling MacPorts, like the Migration page says to do. That is definitely people not having built base on the same OS version they're using it on. Then there’s the libstdc++ vs stdc++ situation which IIRC only trunk addresses. Won't anything built on 10.9 just use libc++ by default? I thought the cxx_stdlib stuff was so we could maybe switch to libc++ on 10.8 at some point. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.2 on Mavericks
On Wed, Oct 23, 2013 at 07:00:46AM -0500, Ryan Schmidt wrote: People keep saying that, but what are the actual problems with 2.2? Well, there’s the gnutar-does-not-exist problem. I thought perhaps this was people installing the Mountain Lion binary on Mavericks, but our installer prohibits that. People work around that by editing the installer. Perhaps it’s people installing MacPorts on Mountain Lion, then upgrading to Mavericks without reinstalling MacPorts, like the Migration page says to do. Yeah, a lot of people do that. Then there’s the libstdc++ vs stdc++ situation which IIRC only trunk addresses. I don't think that's particularly broken on Mavericks with 2.2, but we should really get 2.2.1 out there with this change if we're going to take the leap for libc++ now. This change seems to be needed to prevent crashes on Mavericks: http://trac.macports.org/changeset/112417/branches/release_2_2/base -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Mavericks
Apple released Mavericks today, and MacPorts works great on the new OS (assuming you use trunk/base). However, there is one big change that I want to point out to other MacPorts developers: the C++ runtime. The default C++ runtime is now libc++. libstdc++ is still available for binary compatibility, but newly built applications and frameworks should use libc++. This means that clang++ should be used for all C++ code since g++ does not support libc++. If a port uses C++ and fails to build with clang, it will not be supported on Mavericks (unless it does not export nor utilize C++ APIs to/from other ports). At this point, most C++ ports just work with libc++, so most users will be able to install their ports on Mavericks. One of the main reasons ports fail to build with libc++ is the tr1 namespace. If you see build errors about missing tr1 headers, please see this website for information: http://cplusplusmusings.wordpress.com/2013/06/03/whats-up-with-tr1-and-c11-and-libc/ Here is the list of ports which are currently listed as not working on Mavericks (mainly due to C++ issues). If you need any of these ports, please work with maintainers and developers to address the issues. aqua/qt4-mac archivers/libpar2 devel/openfst devel/quickfix gnome/mlview graphics/agave graphics/dcmtk graphics/enblend graphics/exact-image graphics/inkscape graphics/lib2geom graphics/podofo kde/krusader lang/chapel math/classias math/eigen math/gnudatalanguage math/octave multimedia/lmms multimedia/mp4v2 net/mediatomb net/obby science/arb science/bali-phy science/ds9 science/eo science/htcondor science/magicspp science/solid science/swarm textproc/cuneiform textproc/mgizapp textproc/opensp textproc/pialign textproc/sword Thanks, Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks
Am 22.10.2013 um 23:57 schrieb Jeremy Huddleston Sequoia: [..] Here is the list of ports which are currently listed as not working on Mavericks (mainly due to C++ issues). If you need any of these ports, please work with maintainers and developers to address the issues. [..] textproc/opensp [..] I raise my hand for textproc/opensp. I need opensp working under Maverick, together with p5-sgml-parser-opensp, as an essential part of a local installation of http://validator.w3.org. Regards, Sierk Bornemann signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks
In the blog post you link to, it mentions a tool called cpp11-migratehttp://clang.llvm.org/extra/cpp11-migrate.html, which has since been renamed to clang-modernizehttp://clang.llvm.org/extra/clang-modernize.html. Could we have this be a sub-port of at least one of the Macports clang ports, so as to make it easier for developers to make this transition? Heck, if we install the clang-modernize tool, we could even run it ourselves in the portfiles that need it while we wait for the developers to do it themselves... On Tue, Oct 22, 2013 at 5:57 PM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: Apple released Mavericks today, and MacPorts works great on the new OS (assuming you use trunk/base). However, there is one big change that I want to point out to other MacPorts developers: the C++ runtime. The default C++ runtime is now libc++. libstdc++ is still available for binary compatibility, but newly built applications and frameworks should use libc++. This means that clang++ should be used for all C++ code since g++ does not support libc++. If a port uses C++ and fails to build with clang, it will not be supported on Mavericks (unless it does not export nor utilize C++ APIs to/from other ports). At this point, most C++ ports just work with libc++, so most users will be able to install their ports on Mavericks. One of the main reasons ports fail to build with libc++ is the tr1 namespace. If you see build errors about missing tr1 headers, please see this website for information: http://cplusplusmusings.wordpress.com/2013/06/03/whats-up-with-tr1-and-c11-and-libc/ Here is the list of ports which are currently listed as not working on Mavericks (mainly due to C++ issues). If you need any of these ports, please work with maintainers and developers to address the issues. aqua/qt4-mac archivers/libpar2 devel/openfst devel/quickfix gnome/mlview graphics/agave graphics/dcmtk graphics/enblend graphics/exact-image graphics/inkscape graphics/lib2geom graphics/podofo kde/krusader lang/chapel math/classias math/eigen math/gnudatalanguage math/octave multimedia/lmms multimedia/mp4v2 net/mediatomb net/obby science/arb science/bali-phy science/ds9 science/eo science/htcondor science/magicspp science/solid science/swarm textproc/cuneiform textproc/mgizapp textproc/opensp textproc/pialign textproc/sword Thanks, Jeremy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Supported configurations once Mavericks is released
I would like to open a discussion about what configurations we intend to list as supported with the release of Mavericks. Currently, our webpage states: We provide a single software tree that attempts to track the latest release of every software title (port) we distribute, without splitting them into “stable” Vs. “unstable” branches, targeting mainly the current Mac OS X release (10.8, A.K.A. Mountain Lion) and the immediately previous two (10.7, A.K.A. Lion and 10.6, A.K.A. Snow Leopard). This is more a reflection of the maintainer base than it is a MacPorts policy, with older OS versions falling out of support due to lack of users and maintainers. The reality is that Snow Leopard remains a popular release. Many factors including rosetta support keep users on this old OS, and I'm not sure we want to drop support for SL with the release of Mavericks. We do, however, want to limit the number of configurations that we support in this world of more rapid OS release cycles. I suggest that we advertise a tiered support level breaking things down by OS version and architecture. Specifically: Tier 1 (Primary support platforms): 10.9.x / x86_64 (plus i386 for ports that don't support x86_64) 10.8.x / x86_64 (plus i386 for ports that don't support x86_64) 10.7.x / x86_64 (plus i386 for ports that don't support x86_64) 10.6.x / x86_64 (plus i386 for ports that don't support x86_64) Tier 2 (Will try hard not to break): 10.9.x / i386 10.8.x / i386 10.7.x / i386 10.6.x / i386 Tier 3 (YMMV. Expect to do a lot of the legwork if you want to get a fix): 10.6.x / ppc (Rosetta) 10.5.x / x86_64 10.5.x / i386 10.5.x / ppc 10.4.x / i386 10.4.x / ppc This allows us to push ppc out to YMMV-land (where it currently is in practice) while also keeping 10.6 available as a primary support platform. Additionally, 32bit intel machines (some of the first gen Intel Macs from 2006) would no longer be tier 1 supported, but they'll still be a rung above ppc machines. Thoughts? --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supported configurations once Mavericks is released
On Sep 25, 2013, at 4:20 PM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: I would like to open a discussion about what configurations we intend to list as supported with the release of Mavericks. Thoughts? I still think current + one previous (and best effort for before that) is reasonable. Is Apple even still sending out security updates for 10.6? -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supported configurations once Mavericks is released
On Sep 25, 2013, at 1:20 PM, Jeremy Huddleston Sequoia wrote: I would like to open a discussion about what configurations we intend to list as supported with the release of Mavericks. Currently, our webpage states: We provide a single software tree that attempts to track the latest release of every software title (port) we distribute, without splitting them into “stable” Vs. “unstable” branches, targeting mainly the current Mac OS X release (10.8, A.K.A. Mountain Lion) and the immediately previous two (10.7, A.K.A. Lion and 10.6, A.K.A. Snow Leopard). This is more a reflection of the maintainer base than it is a MacPorts policy, with older OS versions falling out of support due to lack of users and maintainers. The reality is that Snow Leopard remains a popular release. Many factors including rosetta support keep users on this old OS, and I'm not sure we want to drop support for SL with the release of Mavericks. We do, however, want to limit the number of configurations that we support in this world of more rapid OS release cycles. +1, still stuck with rosetta in some shops. Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supported configurations once Mavericks is released
I also like the concept but the distinction of tier 1: 64-bit unless only 32-bit seems a little odd at first glance. I know the exceptional reasons are valid, conveying them to users on the other hand... Do you think there is a clearer way we could present this distinction? I'm sure you've got better background in that area anyways ;-) On Sep 25, 2013, at 4:20 PM, Jeremy Huddleston Sequoia wrote: Tier 1 (Primary support platforms): 10.9.x / x86_64 (plus i386 for ports that don't support x86_64) 10.8.x / x86_64 (plus i386 for ports that don't support x86_64) 10.7.x / x86_64 (plus i386 for ports that don't support x86_64) 10.6.x / x86_64 (plus i386 for ports that don't support x86_64) Tier 2 (Will try hard not to break): 10.9.x / i386 10.8.x / i386 10.7.x / i386 10.6.x / i386 Tier 3 (YMMV. Expect to do a lot of the legwork if you want to get a fix): 10.6.x / ppc (Rosetta) 10.5.x / x86_64 10.5.x / i386 10.5.x / ppc 10.4.x / i386 10.4.x / ppc This allows us to push ppc out to YMMV-land (where it currently is in practice) while also keeping 10.6 available as a primary support platform. Additionally, 32bit intel machines (some of the first gen Intel Macs from 2006) would no longer be tier 1 supported, but they'll still be a rung above ppc machines. Thoughts? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supported configurations once Mavericks is released
Yes they are, actually! On Sep 25, 2013, at 4:31 PM, Daniel J. Luke wrote: I still think current + one previous (and best effort for before that) is reasonable. Is Apple even still sending out security updates for 10.6? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Supported configurations once Mavericks is released
I think there was one last Monday. 2013-004. Looks like they keep a KB article up to date with a list of updates here: http://support.apple.com/kb/HT1222. On Sep 25, 2013, at 3:40 PM, Jeremy Lavergne wrote: Yes they are, actually! On Sep 25, 2013, at 4:31 PM, Daniel J. Luke wrote: I still think current + one previous (and best effort for before that) is reasonable. Is Apple even still sending out security updates for 10.6? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
