Rosegarden-4 0.9.9 released - now officially in beta! 2004-07-30 09:31 http://sourceforge.net/mailarchive/forum.php?thread_id=5235226&forum_id=11769 It sufficed to cp rosegarden-4.0.9.8.ebuild rosegarden-4.0.9.9.ebuild in local portage overlay for the version bump, thus I don't post an ebuild here. In official portage, it will probably be masked as ~x86 again. Reproducible: Always Steps to Reproduce: Actual Results: The Rosegarden File->Open dialog now starts in the examples directory when launched for the first time, which revealed a new runtime dependency: when opening e.g. /usr/share/apps/rosegarden/examples/children.rg, an information dialog pops up with: The following plugins could not be loaded: -- Xsynth (from xsynth-dssi.so) A related thread about that brand new "Disposable Soft Synth Interface" can be found on the [Rosegarden-devel] list at http://sourceforge.net/mailarchive/forum.php?thread_id=5076398&forum_id=271 The dssi and especially xsynth-dssi that Rosegarden depends on seems not to be in portage. The url http://dssi.sourceforge.net/ provides a link to the "xsynth-dssi package" at http://sourceforge.net/project/showfiles.php?group_id=104230&package_id=124101&release_id=253509 The README says among other things: "Xsynth-DSSI requires the following: - a working DSSI host. Xsynth-DSSI has been tested with the example DSSI host available at the dssi.sourceforge.net address above. The xsynth-dssi package was released on 2004-07-15. I first thought "these guys working on Rosegarden are astonishingly fast in adopting the cutting-edge technologies available" and then, remembering some names at [Rosegarden-devel], realized that they actually *set* the state of the art -> the Xsynth dependency seems to be out of topic for this version bump posting ;-)
Ok, I've been working on this for about an hour now, and I need to go... there's an initial ebuild for 4.0.9.9, but there are still compilation problems. I fixed the -fPIC and gcc-3.4 issues, but the Makefiles are still using -fno-exceptions when it is needed... Can you please work with upstream to get this fixed as I don't have the time to do this as I'm going on vacation for 2 weeks... What I've done has been committed to portage (in package.mask) Thanks.
any response from people upstream?
I tried the new ebuild after adding sed -i 's/-fno-exceptions/-fexceptions/g' `grep -lr "\-fno\-exceptions" .` to it after the epatch lines, and it goes along fine until it gets to the linking stage. /bin/sh ../libtool --silent --mode=link g++ -DRGKDE3 -Wnon-virtual-dtor -Wno-long-long -Wu ndef -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -ansi -D_XOPEN _SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -O2 -march=pentium4 -Os -pipe -fPIC -fr educe-all-givs -momit-leaf-frame-pointer -finline-limit=25 -finline-functions -ffinite-math -only -fno-trapping-math -msse3 -ffast-math -fweb -fexceptions -fno-check-new -fno-gcse - o rosegardensequencer -L/usr/X11R6/lib -L/usr/qt/3/lib -L/usr/kde/3.3/lib -R /usr/kde/3.3/ lib -R /usr/qt/3/lib -R /usr/X11R6/lib mmappedcontrolblock.o mmappedsegment.o rosegardenseq uencer.o main.o sequencermapper.o -lkdeui -lkdecore -lqt-mt -lpng -lz -lm -lXext -lX11 -l SM -lICE -lpthread ../sound/libRosegardenSound.la ../sound/libRosegardenSequencer.la ../ba se/libbase.la -lkio -lmad -llrdf -lrt -lasound -lm -ldl -lpthread *** Warning: Linking the executable rosegardensequencer against the loadable module *** libRosegardenSequencer.so is not portable! rosegardensequencer.o(.text+0x301b): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `vtable for RosegardenSequencerApp' rosegardensequencer.o(.text+0x31a5): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x31c9): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x31df): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3207): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x327b): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `vtable for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3405): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3429): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x343f): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3467): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x34d3): In function `RosegardenSequencerApp::~RosegardenSequen cerApp()': : undefined reference to `vtable for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3714): In function `RosegardenSequencerApp::RosegardenSequenc erApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x374b): In function `RosegardenSequencerApp::RosegardenSequenc erApp()': : undefined reference to `vtable for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3d3b): In function `RosegardenSequencerApp::RosegardenSequenc erApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3d56): In function `RosegardenSequencerApp::RosegardenSequenc erApp()': : undefined reference to `VTT for RosegardenSequencerApp' rosegardensequencer.o(.text+0x3e0d): In function `RosegardenSequencerApp::RosegardenSequenc erApp()': : undefined reference to `vtable for RosegardenSequencerApp' ../sound/.libs/libRosegardenSequencer.so: undefined reference to `vtable for Rosegarden::Mi diFile' ../sound/.libs/libRosegardenSequencer.so: undefined reference to `vtable for Rosegarden::Au dioFileManager' ../sound/.libs/libRosegardenSequencer.so: undefined reference to `Rosegarden::MidiFile::set Progress(int)' ../sound/.libs/libRosegardenSequencer.so: undefined reference to `Rosegarden::PeakFile::set Progress(int)' ../sound/.libs/libRosegardenSequencer.so: undefined reference to `vtable for Rosegarden::Pe akFile' ../sound/.libs/libRosegardenSequencer.so: undefined reference to `vtable for Rosegarden::Pe akFileManager' collect2: ld returned 1 exit status make[2]: *** [rosegardensequencer] Error 1 make[2]: Leaving directory `/var/tmp/portage/rosegarden-4.0.9.9/work/rosegarden-4-0.9.9/seq uencer' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/rosegarden-4.0.9.9/work/rosegarden-4-0.9.9' make: *** [all] Error 2
>any response from people upstream? There are some threads about compiling 4.0.0.9 on the rg mail archives; the former seems to be the most interesting: 2004-09-05 compile error 0.9.9 http://sourceforge.net/mailarchive/forum.php?thread_id=5518590&forum_id=11769 There is something about the CXXFLAGS="$CXXFLAGS -fno-exceptions") issue. 2004-08-04 Patchs to compile agains gcc 3.4.1 and Qt 3.3.1 http://sourceforge.net/mailarchive/forum.php?thread_id=5258414&forum_id=271
Gave that gcc 3.4.1 patch a try (I'm using 3.4.1-r2), and still no go. I get the same error I reported above.
Created attachment 39783 [details] [LOG] rosegarden 4.0.9.8 fails w/ gcc 3.4.x this may be unrelated, but i just had a compile failure of media-sound/rosegarden-4.0.9.8 with gcc 3.4.x details attached
Response from upstream: 0.9.8 is no longer supported. At some point along the way, someone submitted a number of patches for building with gcc 3.4.x and those patches have been incorporated into 0.9.9, so please start there. Better yet, use the 1.0 beta from CVS. See also Bug 64276: http://bugs.gentoo.org/show_bug.cgi?id=64276 about removing the kdemultimedia dependency.
Just thought I'd mention for the record, given the recent history of QT/GCC bugs, that I'm now able to build a rosegarden using gcc 3.4.x and qt 3.3.x from the rosegarden sourceforge CVS. No changes were necessary on a fresh CVS checkout. I don't know the status of the 4.0.9.9 ebuild. I do know that my straight './configure' used '-fexceptions' during the build.
> I don't know the status of the 4.0.9.9 ebuild. I do know that > my straight './configure' used '-fexceptions' during the build. As far as I can see, the 4.0.9.9 ebuild dated Oct 1 compiles with neither gcc 3.3 nor gcc 3.4, due to a failed attempt to make it compile with gcc 3.4. Simply adapting the 4.0.9.8 ebuild without such a patch works fine with gcc 3.3, which is the stable x86 gentoo compiler. I think the current ebuild that compiles for nobody should be replaced by the simple one that compiles with gcc 3.3, giving users of stable x86 gcc an easy way to use 4.0.9.9 (which has worked better for me than 4.0.9.8 in that it did not crash in several hours of use).
that's why it has in KEYWORDS="-*" If someone wants to make a gcc-3.4 patch, I'll gladly use it... otherwise, we're waiting for the next rosegarden release.
> that's why it has in KEYWORDS="-*" Ok, that means the broken ebuild is not forced down users' throats. But it still means there is no working 4.0.9.9 ebuild in portage, forcing users to roll their own if they want the improved stability, or if they want to participate in rosegarden mailing lists, which does not make sense with an outdated version. > If someone wants to make a gcc-3.4 patch, I'll gladly use it... This seems pointless, as apparently the work has been done upstream already (albeit not released as a version yet). > otherwise, we're waiting for the next rosegarden release. There is no point in waiting with a completely broken ebuild when the straightforward adoption of the preceding ebuild would at least work for stable gentoo users (who have gcc 3.3). To actively break that ebuild for everybody makes no sense to me.
With gcc-3.4 in stable, both of them are just as broken. If you are willing to get me a gcc-3.4 patch (from the upstream cvs if you so desire), then I'll gladly incorporate it. Otherwise, it's going to have to wait until I get some time to do it myself (whith looks like it's going to be a long tims as I maintain about 500 other packages and have more pressing bugs on my hands.
Created attachment 43659 [details, diff] gcc 3.4 fix still doesn't work, but fails in a more mysterious way...
Created attachment 43660 [details] 4.0.9.9 ebuild this uses the new 3.4 patch and fixes the -fno-exceptions problem
Created attachment 43663 [details] [LOG] 4.0.9.9 fails during linking I've added a patch from the rosegarden-devel list to fix the gcc-3.4 issues. Compiling with the new 4.0.9.9 ebuild (see above) it now fails when linking and the cause is beyond me :/
Created attachment 44404 [details] 4.9.91 release : RC2 test tarball Compiling rosegarden-4-0.9.91rc2.tar.bz2 worked with 4.0.9.8.ebuild and gcc 3.3.4 (unlike 4.0.9.9)
in portage.
>in portage. Mmh. I should have posted a more verbose comment. My "4.9.91 release : RC2 test tarball"-file was not really meant to be directly commited, as it uses a directly hacked URI: #SRC_URI="mirror://sourceforge/${PN}/${MY_P}.tar.gz" SRC_URI="http://www.telegraph-road.org/rosegarden/rosegarden-4-0.9.91rc2.tar.bz2" It was more meant as an opportunity to test it aganist gcc 3.4 or other archs before 4.0.9.91 will be finally released, such that perhaps less portage patches will be needed.
Re-opening so Eradicator can fix the URL problem
the SRC_URI is not broken... this releasse isn't available on the rosegarden sf.net download site because it's a snapshot release... unfortunately older releases don't even compile anymore, so this is what we're stuck with until the next upstream release... that being said, I put the tarball on the gentoo mirrors, so it won't tax the site mentioned in SRC_URI anyways...
