|
Description
tim
2005-04-27 06:50:27 UTC
*** Bug 90615 has been marked as a duplicate of this bug. *** Please reopen when you have added an url and a comment about what the application does. Just requesting something without providing the necessary information is not friendly. Created attachment 57388 [details]
ebuild
having a browser not responding if is not friendly ... specific ebuild is attached Oh sorry, overlooked the attached ebuild :) Created attachment 57409 [details]
updated ebuild
sorry, i haven't had a good internet connection for a few monthes ... of course, i'm volunteering to maintain the ebuilds that i submitted Created attachment 95807 [details]
media-libs/portmidi-060828.ebuild
Updated and improved ebuild.
Includes some bugfixes from Debian.
Also installs shared libraries and test applications.
Created attachment 100760 [details]
media-libs/portmidi-061023.ebuild
Version bump.
Created attachment 100761 [details, diff]
files/portmidi-061023.diff
PortMidi-061023 patch.
Daniel: an 8 kb undocumented patch is not very good. Can you tell me what exactly it does? It seems to fix a whole bunch of things, are there any split-out-patches? Are these sent upstream? Created attachment 101587 [details]
media-libs/portmidi-061023.ebuild
Install the shared libraries correctly.
Created attachment 101588 [details]
files/portmidi-061023.diff
Correct dependencies on shared libraries.
It's the patch that Debian's had sitting around for years, updated to work with the newer releases. It includes a couple of small bugfixes, a handful of warning fixes, and adds shared library support to the Makefile. I'm in contact with upstream, and sent him this diff about two months ago. His release last month didn't include any of them, so I emailed him again, and this time he said that he'd look into it. (this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq *** Bug 298256 has been marked as a duplicate of this bug. *** Created attachment 214074 [details]
portmidi-199.ebuild
Created attachment 214075 [details, diff]
patch to install in /usr/lib
Created attachment 218907 [details]
ebuild portmidi-200
Created attachment 218909 [details]
patch to install in /usr/lib
hm... v199 and v200 are not compiling here, (x86 or amd64) will attach build.log and emerge --info Created attachment 218915 [details]
build.log amd64 v200
Created attachment 218917 [details]
emerge --info amd64
Created attachment 224827 [details]
portmidi-200.ebuild without java part
portaudio-200.ebuild without java part (because it's too broken).
Created attachment 224829 [details, diff]
portmidi-200-Makefile.patch
patch for above ebuild.
Latest ebuild and patch work fine for me here.
>=media-sound/mixx-1.8.0 is going to depend on this ebuild (see bug 310821), so it would be nice to have it in the tree soon.
Florian
Created attachment 225995 [details]
portmidi-200.ebuild
less evasive and more complete version of the media-libs/portmidi ebuild. Please test.
(In reply to comment #27) > Created an attachment (id=225995) [details] > portmidi-200.ebuild > > less evasive and more complete version of the media-libs/portmidi ebuild. > Please test. > The ebuild is still using `cmake` directly instead of using the inherited cmake-utils.eclass, so this is a no-go. Created attachment 226031 [details]
portmidi using cmake eclass
Ebuild modified to use cmake eclass. This ebuild still calls javac and jar directly via the pm_linux/Makefile
Created attachment 226033 [details]
cmake-utils_src_compile =P
Created attachment 226035 [details]
media-libs/portmidi-200.ebuild
hm last ebuild (id 226035) ... not working here (amd64): No rule to make target `/opt/icedtea6-bin-1.7.1/include/../jre/lib/AMD64/server/libjvm.so', needed by `pm_common/Gentoo/libpmjni.so'. Stop. build.log: http://pastebin.com/hGbbakQH emerge --info: http://pastebin.com/fUy7CRYa on x86 i get a sandbox violation... build.log: http://pastebin.com/Kwt19TjS emerge --info: http://pastebin.com/gnbuYJ70 Created attachment 226047 [details]
fixed amd64 case issue
tested on both x86 amd64
oops... on x86 I used a wrong ebuild... now works on both architectures, thanks :) Alright, new problem. This thing builds fine with cmake but its doesn't work. For some reason it will not work unless CMAKE_BUILD_TYPE=Release or Debug. I have tried to patch the build files but its not helping and I don't know why. If CMAKE_BUILD_TYPE is set correctly the native libs build fine, however the jni library segfaults. Again I have no idea why. I will keep tinkering with it but if someone has an idea please let me know. Created attachment 226335 [details, diff]
Java removal Patch
Created attachment 226337 [details]
ebuild
Ok after reviewing the issues with the Java/JNI portion of this code I have come the to conclusion that its broken upstream. The code fails most of the time but will start sometimes after the midi driver is freshly loaded but fail after it tries to refresh the list. The jar file and JNI library are not needed for this library to function so I have created a patch to strip out all the Java I could find. I know its not a grate solution but this should be fixed upstream; bug was filed.
Please report any issues
Created attachment 226339 [details]
ebuild
as a side effect of not needing Java we can build without -j1
It creates only: --- /usr/ --- /usr/share/ --- /usr/share/doc/ --- /usr/share/doc/portmidi-200/ >>> /usr/share/doc/portmidi-200/CHANGELOG.txt.bz2 >>> /usr/share/doc/portmidi-200/README_LINUX.txt.bz2 >>> /usr/share/doc/portmidi-200/README.txt.bz2 --- /usr/local/ --- /usr/local/include/ >>> /usr/local/include/porttime.h >>> /usr/local/include/portmidi.h --- /usr/local/lib/ >>> /usr/local/lib/libportmidi.a >>> /usr/local/lib/libportmidi.so No libporttime.a and libporttime.h which are needed to compile mixxx-9999. I meant libportime.a and libportime.SO. I found the answer (http://comments.gmane.org/gmane.linux.audio.mediaapi/370) but I can't explain why mixxx-9999 do not compile... (In reply to comment #39) > It creates only: > --- /usr/ > --- /usr/share/ > --- /usr/share/doc/ > --- /usr/share/doc/portmidi-200/ > >>> /usr/share/doc/portmidi-200/CHANGELOG.txt.bz2 > >>> /usr/share/doc/portmidi-200/README_LINUX.txt.bz2 > >>> /usr/share/doc/portmidi-200/README.txt.bz2 > --- /usr/local/ > --- /usr/local/include/ > >>> /usr/local/include/porttime.h > >>> /usr/local/include/portmidi.h > --- /usr/local/lib/ > >>> /usr/local/lib/libportmidi.a > >>> /usr/local/lib/libportmidi.so > > > No libporttime.a and libporttime.h which are needed to compile mixxx-9999. > Technically no, porttime is now compiled into portmidi. There is an upstream patch to solve the problem. For the time being use the patch in the beta1 ebuild on your 9999 ebuild. If you can wait until tonight I will post my 9999 ebuild along with an update beta1 ebuild that does a better job of fixing the cflag disaster. Thank you, for the moment I solved adding this to the 9999 ebuild from proaudio:
src_unpack() {
[...]
# portmidi only has libportmidi.so, libporttime.so is included there, upstream notified.
sed -i -e "s:if not platform == 'osx':if not platform == platform:" \
${S}/src/SConscript || die "sed failed"
}
It also did not have portmidi among the dependencies, so I think it's not much updated (like all the 9999 shit on proaudio). I will wait your ebuilds.
Created attachment 228581 [details, diff]
renamed patch file
same patch file, just changed the name from -Java to -Makefile to be a little more specific.
Created attachment 228585 [details]
updated ebuild
updated ebuild to fix the installation location issues and the porttime issues.
Port time is now included inside of portmidi but every distribution on the planet seems to ship them separated. I have included a symlink to portmidi for porttime which appears to satisfy some of these other packages (thanks Darkbasic).
Additionally I have removed the cmake installation and opted for dolib and dolib.a to install the libs. cmake was requiring to much patching to get the libraries to install correctly.
Created attachment 251163 [details, diff]
portmidi-217-Makefile.patch
Created attachment 251165 [details]
portmidi-217.ebuild
I have not throughly tested this build. I would consider 200 stable.
Created attachment 251167 [details, diff]
portmidi-217-Makefile.patch
I am using ebuild modified from here with some ideas taken from the Fedora spec. Patch attached is a mixture of things that Gentoo/Fedora needs for normalising the cmake install, it can specify the library and jar dir with this and switch java on/off. Also a python module can be installed. Files follow. Thanks. Created attachment 251211 [details]
portmidi-217.ebuild
Created attachment 251213 [details, diff]
portmidi-217-cmake-libdir-java-opts.patch
(In reply to comment #49) > I am using ebuild modified from here with some ideas taken from the Fedora > spec. Patch attached is a mixture of things that Gentoo/Fedora needs for > normalising the cmake install, it can specify the library and jar dir with this > and switch java on/off. Also a python module can be installed. > Files follow. Thanks. > java still fails for me... If you can get it to build, try running it, quit, and run it again. It was giving me a segfault on the second try for version 200. make[2]: *** No rule to make target `/opt/sun-jdk-1.6.0.22/jre/lib/amd64/client/libjvm.so', needed by `build/Release/libpmjni.so'. Stop. make[1]: *** [pm_common/CMakeFiles/pmjni.dir/all] Error 2 make: *** [all] Error 2 !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.22" JAVACFLAGS="-source 1.6 -target 1.6" COMPILER="" I tested this on x86, I did have a lot of problems with the java part but at the moment this one seems to work for me. I recently got amd64 but am running on x86 until I can build enough of a workable system. I'll see if I can build a bit more and test this. I'm not sure where the libjvm.so file is supposed to be on amd64 so the path is most likely wrong, a locate libjvm.so might find something, also I built this with the icedtea vm. Thanks for testing. Update: Just built it with =dev-java/icedtea6-bin-1.9.1 and =dev-java/sun-jdk-1.6.0.22 successfully, it seems an amd64 thing. I will have a go at building portmidi on amd64 soon and see if I can find out what the problem with libjvm.so is there. Created attachment 251309 [details]
portmidi-217.ebuild
Updated ebuild. Stole code from =sci-chemistry/tinker-0.6.ebuild for libjvm.so search, tested a bit with sun-jdk-1.6 and icedtea-bin on x86 and amd64 and seems ok here. Also added a dep for cython to build python modules.
(In reply to comment #55) > Created an attachment (id=251309) [details] > portmidi-217.ebuild > > Updated ebuild. Stole code from =sci-chemistry/tinker-0.6.ebuild for libjvm.so > search, tested a bit with sun-jdk-1.6 and icedtea-bin on x86 and amd64 and > seems ok here. Also added a dep for cython to build python modules. > Works well on amd64 with java. I didn't test python. (In reply to comment #55) > Created an attachment (id=251309) [details] > portmidi-217.ebuild > > Updated ebuild. Stole code from =sci-chemistry/tinker-0.6.ebuild for libjvm.so > search, tested a bit with sun-jdk-1.6 and icedtea-bin on x86 and amd64 and > seems ok here. Also added a dep for cython to build python modules. > Sorry one more thing to add. Can you please sent the patches upstream? > Works well on amd64 with java. I didn't test python. Thanks for testing it. > Sorry one more thing to add. Can you please sent the patches upstream? Just sent patch to the portmedia mailing list. bug from http://bugs.gentoo.org/attachment.cgi?id=253019&action=view on x86 for 217. looks like it maybe a result of use python? (In reply to comment #59) > bug from http://bugs.gentoo.org/attachment.cgi?id=253019&action=view on x86 for > 217. looks like it maybe a result of use python? > with -python it's ok Oops. python worked for me because I actually had portmidi installed. I'm adding patch for cmake that I actually sent upstream which differs to my first one, added another patch for distutils setup.py to attempt fix of python to find the header and libs in the build tree. Files follow. Thanks. Created attachment 253397 [details]
portmidi-217.ebuild
Created attachment 253399 [details, diff]
portmidi-217-cmake-libdir-java-opts.patch
Created attachment 253401 [details, diff]
portmidi-217-python-setup.py.patch
Created attachment 268205 [details]
portmidi-217.ebuild (creates the symlink for libporttime.so)
Since porttime merged into portmidi, the portmidi lib handles all the things that porttime lib provides. So we need to symlink portmidi.so to porttime.so. Otherwise some apps fail to compile with error:
"ld: cannot find -lporttime"
This ebuild does just create the porttime symlink in ebuild:
dosym libportmidi.so /usr/$(get_libdir)/libporttime.so
Comment on attachment 268205 [details]
portmidi-217.ebuild (creates the symlink for libporttime.so)
Patched obsoleted because the bug is in the apps, not portmidi, then.
(In reply to comment #66) > Comment on attachment 268205 [details] > portmidi-217.ebuild (creates the symlink for libporttime.so) > > Patched obsoleted because the bug is in the apps, not portmidi, then. Ok. I did not think that way, but you are right. For the time dev-python/pygame-1.9.1-r1::gentoo fails to emerge with: "ld: cannot find -lporttime" But, currently I am short of time for a bug report for pygame. Thanks. Hey I've been trying (unsuccessfully) to compile Gavin's ebuild (with the two patches applied) to a fairly fresh gentoo amd64 install. I don't have the exact errors in front of me, but will append them to this message soon, so what I'm wondering is the current status of this particular ebuild. Anyone else still having trouble installing it? I think an open bug with such a low bug # shows the kind of status :) Please paste at least a bit of your build errors and I'll see if I can help. Sunrise is suggested for this, can someone please help me get on it? I didn't get a response last few times I was on IRC and asked. I have a few updates for other packages in my overlay too. I know for a fact there are a few packages in pro-audio overlay and others that automagically depend on portmidi, pygame was mentioned above, it could be a potential mine field. I'm not surprised this package was not included in portage sooner. Anyway, sorry for the noise... problem with this is that an ebuild in the trunk depends on this one. I was going to put it in sunrise but we need to get permission from the maintainer of the other ebuild to move that over as well. As far as I know this has been building fine for people including my self. Please post a build log and your emerge --info or at least an error. Ill look into getting sunrise rolling again this morning. Hey... I knew my first message didn't have enough information, but I wanted to make sure that there wasn't some larger issue that everyone but me was already aware of--wouldn't be the first time I assure you. Anyway, here's what I'm seeing. Whenever I attempt to emerge portmidi my install fails: distutils_pkg_postrm() called illegally call stack: ebuild.sh, line 56: Called pkg_postrm() environment, line 5258: Called distutils_pkg_post environment, line 1643: Called die The specific snippet of code: die "$(FUNCNAME)()called illegally"; Later on the compiler spits out, "The 'postrm' phase of the 'media-libs/portmidi-217' package has failed with exit value 1". That's all I have--I'm actually typing from a video I took of the failed compile since the supposed build log (/var/tmp/portage/media-libs/portmidi-271/temp/build.log) isn't there. I'm assuming it's being deleted as part of the cleanup process. Any advice or help is greatly appreciated. -JLR Can not reproduce this. USE="-python" emerge -v1 portmidi might get it to install for you, minus the python modules. The files in /var/tmp/portage will be wiped unless you have FEATURES=noclean but I would not recommend setting that permanently. For saving logs, in /etc/make.conf I have: PORT_LOGDIR=/var/log/portage PORTAGE_ELOG_CLASSES="info warn error log qa *" PORTAGE_ELOG_SYSTEM="save" and then find /var/log/portage/ -name '*portmidi*' should show you some logs after you try emerge portmidi again. Also, what version of portage are you using? the output of emerge --info may help some. FWIW I'm on 2.1.9.42 (In reply to comment #72) > Can not reproduce this. > > USE="-python" emerge -v1 portmidi > might get it to install for you, minus the python modules. I was able to reproduce the issue with USE="-python java" emerge -v1 portmidi. I have a fixed the problem locally and will be migrating this ebuild to sunrise shortly. For those that cant wait the fix is adding the following (thanks to floppym): pkg_postinst() { # prevent distutils_pkg_postinst from being called autmatically if # python is disabled use python && distutils_pkg_postinst } pkg_postrm() { # prevent distutils_pkg_postrm from being called autmatically if # python is disabled use python && distutils_pkg_postrm } (In reply to comment #73) > > I was able to reproduce the issue with USE="-python java" emerge -v1 portmidi. > I have a fixed the problem locally and will be migrating this ebuild to sunrise > shortly. > This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/media-libs/portmidi Just want to say thanks to all involved especially Alex for the head start, testing and the push to sunrise.
A small thing to add.
If I change the default python interpreter to python2.7 or python3.1 using eselect, and emerge portmidi I get following errors:
eselect python set python2.7
emerge -v1 portmidi
[100%] Building C object pm_dylib/CMakeFiles/portmidi-dynamic.dir/__/pm_common/portmidi.c.o
Linking C shared library ../build/Release/libportmidi.so
[100%] Built target portmidi-dynamic
/var/tmp/portage/media-libs/portmidi-217/work/portmidi/pm_python /var/tmp/portage/media-libs/portmidi-217/work/portmidi
python2.7 setup.py build
WARNING:root:Cython is preferred over pyrex for python3 compatibility.
Traceback (most recent call last):
File "setup.py", line 11, in <module>
from Pyrex.Distutils import build_ext
ImportError: No module named Pyrex.Distutils
* ERROR: media-libs/portmidi-217 failed (compile phase):
* Building failed
*
* Call stack:
* ebuild.sh, line 56: Called src_compile
* environment, line 7256: Called distutils_src_compile
* environment, line 1723: Called die
* The specific snippet of code:
* "$(PYTHON)" "${setup_file#*|}" "${_DISTUTILS_GLOBAL_OPTIONS[@]}" build "$@" || die "Building failed";
eselect python set python3.1
emerge -v1 portmidi
[100%] Building C object pm_dylib/CMakeFiles/portmidi-dynamic.dir/__/pm_common/portmidi.c.o
Linking C shared library ../build/Release/libportmidi.so
[100%] Built target portmidi-dynamic
/var/tmp/portage/media-libs/portmidi-217/work/portmidi/pm_python /var/tmp/portage/media-libs/portmidi-217/work/portmidi
python3.1 setup.py build
File "setup.py", line 145
print "Found Win32 platform"
^
SyntaxError: invalid syntax
* ERROR: media-libs/portmidi-217 failed (compile phase):
* Building failed
*
* Call stack:
* ebuild.sh, line 56: Called src_compile
* environment, line 7256: Called distutils_src_compile
* environment, line 1723: Called die
* The specific snippet of code:
* "$(PYTHON)" "${setup_file#*|}" "${_DISTUTILS_GLOBAL_OPTIONS[@]}" build "$@" || die "Building failed";
(In reply to comment #75) > A small thing to add. > If I change the default python interpreter to python2.7 or python3.1 using > eselect, and emerge portmidi I get following errors: I am able to reproduce the error with python 3. It seems to be cause by "Print Is A Function" ( http://docs.python.org/release/3.0.1/whatsnew/3.0.html ). This should probably be fixed up stream, I will file a bug. Now for the python 2 version. This seems to build fine for me. Please check to see if you have cython and/or pyrex installed. I currently only have cython installed, and it should probably be required. With python2.7 it was a PEBKAC issue here, please disregard. I held off python2.7 upgrade for a while because of some problem with setting it as main interpreter some time ago, I should have ran python-updater afterwards to rebuild all of the required python dependencies. It seems to build fine now with python2.7 after running python-updater. The python3.1 issue remains. Thanks again. Created attachment 289943 [details]
portmidi-217 failed compile with java flag on
Created attachment 289945 [details]
emerge --info
For some reason I have trouble compiling portmidi-217 with the java flag on. Without it everything compiles fine. I have attached the build log with java flag on and my emerge --info. (In reply to comment #80) > For some reason I have trouble compiling portmidi-217 with the java flag on. > Without it everything compiles fine. I have attached the build log with java > flag on and my emerge --info. Please try with Oracle JDK not IcedTea. Let me know if there is still an issue. (In reply to comment #81) > (In reply to comment #80) > > For some reason I have trouble compiling portmidi-217 with the java flag on. > > Without it everything compiles fine. I have attached the build log with java > > flag on and my emerge --info. > > Please try with Oracle JDK not IcedTea. Let me know if there is still an > issue. Thank you for the quick response. These are the java vms I have installed: The following VMs are available for generation-2: 1) IcedTea6-bin 1.10.3 [icedtea6-bin] *) Oracle JDK 1.7.0 [oracle-jdk-bin-1.7] 3) Sun JDK 1.6.0.27 [sun-jdk-1.6] I have also tried with oracle-jdk-bin-1.7 and sun-jdk-1.6. The compile fails also. Let me know if you need the build logs or any additional info. Created attachment 290041 [details]
Portmidi fails against Oracle-JDK-1.7 with java flag on
Just did an emerge -v1 portmidi and it compiled ok with sunrise ebuild and USE=java on icedtea amd64. Just curious but has this ebuild been modified in place? The line doesnt' look right, there is no pm_java in the pm_java directory cd: /var/tmp/portage/media-libs/portmidi-217/work/portmidi/pm_java/pm_java: No such file or directory I have noticed that line too but I can't seem to make it go away. I thought it was an ebuild error. I tried cleaning the directories and download a clean copy of portmidi but the problem persists. Is there any java checks I could run? (In reply to comment #85) > I have noticed that line too but I can't seem to make it go away. I thought it > was an ebuild error. I tried cleaning the directories and download a clean copy > of portmidi but the problem persists. Is there any java checks I could run? Strange thing is I build though fine without errors. Sounds like cmake is messing up when it generates the makefiles on your system for some reason. Can you do me a favor and tar up /var/tmp/portage/media-libs/portmidi-217/work/portmidi and email it to me after it fails. Of course, I have emailed you the portmidi work dir in a tar.gz archive after a failure with Oracle jdk 1.7. (In reply to comment #80) > For some reason I have trouble compiling portmidi-217 with the java flag on. > Without it everything compiles fine. I have attached the build log with java > flag on and my emerge --info. Well let this be a lesson to you ACCEPT_KEYWORDS="* ~*". This is a problem with cmake ~2.8.6-r1 and absolute paths vs relative paths. This could be a gentoo cmake bug and not related to the current pm_java/CMakeLists.txt file. I'll work on it when I have time, if you want to mess around with it try removing all the "WORKING_DIRECTORY pm_java" lines in the file. Remember do not remove the ')'. (In reply to comment #88) > Well let this be a lesson to you ACCEPT_KEYWORDS="* ~*". This is a problem > with cmake ~2.8.6-r1 and absolute paths vs relative paths. This could be a > gentoo cmake bug and not related to the current pm_java/CMakeLists.txt file. > I'll work on it when I have time, if you want to mess around with it try > removing all the "WORKING_DIRECTORY pm_java" lines in the file. Remember > do not remove the ')'. Well, thanks for pointing that out Alex, I will try to mess around as you say and see what happens. (In reply to comment #89) > (In reply to comment #88) > > Well let this be a lesson to you ACCEPT_KEYWORDS="* ~*". This is a problem > > with cmake ~2.8.6-r1 and absolute paths vs relative paths. This could be a > > gentoo cmake bug and not related to the current pm_java/CMakeLists.txt file. > > I'll work on it when I have time, if you want to mess around with it try > > removing all the "WORKING_DIRECTORY pm_java" lines in the file. Remember > > do not remove the ')'. > > Well, thanks for pointing that out Alex, I will try to mess around as you say > and see what happens. I talked with some people in #cmake on freenode and a bug report should be filed as this is a cmake issue. please test with ~2.8.5-r2 as well and see if it still fails. Created attachment 297469 [details] Patch for current stable cmake I can confirm the compile failure from comment #83. I'm using stable cmake-2.8.6-r4. If this is a cmake issue, it is not resolved in tree. Removing the workdir stuff as suggested seems to fix the problem: compilation and installation work. Patch appended. (In reply to comment #91) > Created attachment 297469 [details] > Patch for current stable cmake > > I can confirm the compile failure from comment #83. > I'm using stable cmake-2.8.6-r4. > If this is a cmake issue, it is not resolved in tree. > Removing the workdir stuff as suggested seems to fix the problem: compilation > and installation work. > Patch appended. I just ran a battery of tests against your patch and it appears to function correctly. I will update sunrise. Added to CVS. |
