Summary: | [Bump] Rosegarden-4.0.9.9 ebuild | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toni Arnold <toni__arnold> |
Component: | New packages | Assignee: | Jeremy Huddleston (RETIRED) <eradicator> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | jared, sound, will |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.rosegardenmusic.com | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
[LOG] rosegarden 4.0.9.8 fails w/ gcc 3.4.x
gcc 3.4 fix 4.0.9.9 ebuild [LOG] 4.0.9.9 fails during linking 4.9.91 release : RC2 test tarball |
Description
Toni Arnold
2004-07-31 06:05:06 UTC
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... |