Summary: | media-sound/rezound-0.12.3_beta-r2 build fails on linking problem with -O2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petr Novak <che> |
Component: | Current packages | Assignee: | Professional Audio Applications Maintainers <proaudio> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | dhp_gentoo, florian.berger, jesse, luisav.ferreira, Martin.vGagern, polynomial-c |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 340997 | ||
Attachments: |
build log with -02
Instantiate createPool<sample_t> Proposed new ebuild Proposed patch for new ebuild (same as previous patch, but renamed) Let gcc handle template instantiation |
Description
Petr Novak
2010-08-27 11:13:46 UTC
Created attachment 244917 [details]
build log with -02
It even fails with -O1 IF USE=portaudio :) When USE=-portaudio, it's ok with -O1, but not with -O2 *** Bug 340997 has been marked as a duplicate of this bug. *** *** Bug 341011 has been marked as a duplicate of this bug. *** #CFLAGS="-O2 -march=athlon64 -pipe -fomit-frame-pointer" CFLAGS="-O1 -march=athlon64 -pipe -fomit-frame-pointer" fixed it for me (for one shot). Some detective work: The symbol in question, TStaticPoolAccesser<float, TPoolFile<unsigned long, unsigned long> > TPoolFile<unsigned long, unsigned long>:: createPool<float>(string, bool) has the mangled name _ZN9TPoolFileImmE10createPoolIfEE19TStaticPoolAccesserIT_S0_ESsb This name is referenced in CNativeSoundClipboard.o, as the error message states. In the -O1 build, the name is defined in CSound.o. Towards the end of CSound.cpp there is a number of explicit template initializations, none of which matches the version mentioned above, as they use a different template parameter for the createPool itself. My guess is that some other code in this file uses createPool<float>. Seems to be via some typedef, perhaps createPool<sample_t> or some such. In the -O1 build, the function is instantiated, its code generated, and other code can reference it. In the -O2 build, the compiler inlines the function, therefore sees no reason to generate function code for it, therefore the symbol remains unreferenced. http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html might be interesting reading. And adding the correct explicit instantiation to CSound.cpp should do the trick. Haven't tried yet, though. *** Bug 351317 has been marked as a duplicate of this bug. *** Created attachment 259521 [details, diff] Instantiate createPool<sample_t> This patch does seem to fix the issue for me. Please test. Reported this whole issue upstream: https://sourceforge.net/tracker/?func=detail&aid=3155234&group_id=5056&atid=105056 (In reply to comment #8) > This patch does seem to fix the issue for me. Please test. Fixes this for me as well. Thank you! Created attachment 259698 [details]
Proposed new ebuild
Created attachment 259699 [details, diff]
Proposed patch for new ebuild (same as previous patch, but renamed)
Could this find it's way into the tree? Compiles fine here.
It would seem that development upstream has stalled. http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTindNh5rpbHaXgH6irMnzeVNLf4KQhHF9yXoyQpJ%40mail.gmail.com&forum_name=rezound-users (no response to friendly query regarding development status) No SVN updates for 13 months. http://rezound.svn.sourceforge.net/viewvc/rezound/ And, no response from upstream (publicly) on the SF Rezound bugtracker to patch submitted in comment #8. Perhaps this package should be put out to pasture? (In reply to comment #12) > Perhaps this package should be put out to pasture? Meaning remove it from tree? I would hate to see it go. There is a patch, it has twice been confirmed to work, why not simply include it in portage and close this bug? I see no urgent reason to stop supporting the package unless bigger problems occur and neither the devs nor the community seem willing to write patches for it. Jesse; Gentoo distributes software for people who want them; not because of people who write them. We shall not remove apps just because upstream died; apps may keep working ... especially if WE maintain them. Especially if some other people wrote patches to keep them working. Ebuild and patch work fine here. +1 for keeping Rezound in the tree and adding the patch to files/. I'd be happy to fix this bug but... Martin, the patch doesn't work for me. It fails with this error message: /var/tmp/portage/media-sound/rezound-0.12.3_beta-r2/work/rezound-0.12.3beta/src/frontend_fox/../../src/PoolFile/TStaticPoolAccesser.cpp:79: undefined reference to `void TPoolFile<unsigned long, unsigned long>::removeAccesser<float>(TStaticPoolAccesser<float, TPoolFile<unsigned long, unsigned long> > const*)' ../../src/backend/.libs/libbackend.a(CMIDISDSSoundTranslator.o): In function `~TStaticPoolAccesser': /var/tmp/portage/media-sound/rezound-0.12.3_beta-r2/work/rezound-0.12.3beta/src/backend/../../src/PoolFile/TStaticPoolAccesser.cpp:79: undefined reference to `void TPoolFile<unsigned long, unsigned long>::removeAccesser<short>(TStaticPoolAccesser<short, TPoolFile<unsigned long, unsigned long> > const*)' collect2: ld returned 1 exit status make[2]: *** [rezound] Error 1 This is with gcc-4.6.3 on a octacore machine (MAKEOPTS="-j8"). If you can provide a working patch I'd be happy to commit it so we can finally close this bug. Created attachment 312751 [details, diff]
Let gcc handle template instantiation
OK, here is an alternative patch. Instead of adding yet more explicit template instantiations, and hoping that those will be sufficient this time, this patch here goes for implicit template instantiation. It makes the template source code available wherever it might be required. This should be more robust across various gcc versions and settings. It will cause slight increases in build time resource demand, as templates will be instantiated several times, but the linker should remove duplicates so the final result should be the same.
Please EVERYONE subscribed to this bug, give this patch a try. As my previous patch doesn't work for everybody, it would be good to know that this patch here is not inferior to that one.
Thank you for your quick reply Martin. That new patch works for me. I hope we get some more feedback soon so I can commit this patch ASAP. I've just tried to emerge the package again using portage ebuild and it no longer fails for me, so I'm afraid I can't help in this matter :/ Finally fixed in the tree. Thanks for your contributions and your patience :) |