libvorbisfile.so: undefined reference to symbol 'vorbis_block_init' see attached logs build goes fine when I downgrade to libvorbis-1.3.3 Reproducible: Always
1) Please attach the entire build log to this bug report. 2) Please post your `emerge --info' output in a comment.
Created attachment 368778 [details] emerge info
Created attachment 368780 [details] emerge pqv
Created attachment 368782 [details] build log
(In reply to Andreas Klauer from comment #4) > Created attachment 368782 [details] > build log OK, this log is quite clear. Now attach build log of media-libs/libvorbis.
Created attachment 368822 [details] Installing (1 of 1) media-libs/libvorbis-1.3.4
(In reply to Andreas Klauer from comment #6) > Created attachment 368822 [details] > Installing (1 of 1) media-libs/libvorbis-1.3.4 The log seems to look correct... What's the output of 'ldd -r /usr/lib64/libvorbisfile.so.3.3.6' and 'lddtree /usr/lib64/libvorbisfile.so.3.3.6' ?
mpd also runs fine with the merged libvorbis-1.3.4 - while playing ogg/vorbis files. It just want to build with it... # ldd -r /usr/lib64/libvorbisfile.so.3.3.6 linux-vdso.so.1 (0x00007fffdd1ff000) libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00007fd4ad7fa000) libogg.so.0 => /usr/lib64/libogg.so.0 (0x00007fd4ad5f3000) libc.so.6 => /lib64/libc.so.6 (0x00007fd4ad24e000) libm.so.6 => /lib64/libm.so.6 (0x00007fd4acf56000) /lib64/ld-linux-x86-64.so.2 (0x00007fd4adc5a000) # lddtree /usr/lib64/libvorbisfile.so.3.3.6 /usr/lib64/libvorbisfile.so.3.3.6 (interpreter => None) libvorbis.so.0 => /usr/lib64/libvorbis.so.0 libm.so.6 => /lib64/libm.so.6 libogg.so.0 => /usr/lib64/libogg.so.0 libc.so.6 => /lib64/libc.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
It just *does not* want to build with it...
Created attachment 369536 [details] emerge --info (oleid@mescharet.de) I'm hit by the very same problem.
$ nm -D --defined-only /usr/lib64/libvorbis.so.0.4.7 |grep vorbis_block_init 00000000000087b0 T vorbis_block_init so it comes from -lvorbis
copy'n'paste from the build.log showing -lvorbis is there, so it shouldn't return undefined reference for vorbis_block_init, futhermore because libvorbisfile has a NEEDED entry to libvorbis.so.0 <snip> -lvorbis -lvorbisfile -logg -lFLAC -lm -lmad -lm -lopus -logg -lavformat -lavcodec -lavutil -lfaad libmodplug_decoder_plugin.a -lmodplug libinput.a -lcurl -lcdio_paranoia -lcdio_cdda -lcdio -lm -lavformat -lavcodec -lavutil libarchive.a -lbz2 -liso9660 -lcdio -lm libtag.a -lid3tag -lz liboutput_plugins.a -lwrap -lao -lasound -lopenal -lshout -lvorbis -ltheora -logg -lspeex libfilter_plugins.a libpcm.a -lsamplerate libencoder_plugins.a -ltwolame -lFLAC -lm -lopus -logg -lvorbisenc libmixer_plugins.a libconf.a libevent.a libthread.a libsystem.a libutil.a libfs.a -lgthread-2.0 -pthread -lglib-2.0 -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../lib64/libvorbisfile.so: undefined reference to symbol 'vorbis_block_init' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../lib64/libvorbis.so: error adding symbols: DSO missing from command line </snip> you have made sure you don't have any *vorbis* stuff in /usr/local/lib or /usr/local/include? you have tried 'rm -rf /usr/lib/libvorbis*' and 'emerge -C libvorbis' and re-emerging them again?
I have no vorbis in /usr/local. find -name "*vorbis*" /usr/local does not find anything. 'locate vorbis' finds no files anywhere other than the /usr/lib{32,64}/libvobis*'. /usr/lib is -> lib64. > you have tried 'rm -rf /usr/lib/libvorbis*' and 'emerge -C libvorbis' and re-emerging them again? Just did that, it does not change anything. Problem remains. In the build output I see '-lvorbis' among the options. Your 'nm' command also returns for me that it's there ('008660 T vorbis_block_init'). Can no one reproduce this? I'll try again with a fresh stage3 in a chroot then.
There was no vorbis stuff in /usr/local/*. I deleted all libvorbis stuff in /usr/lib64 and unmerged libvorbis. ("find /usr/ | grep vorbis | grep -v portage" revealed only some gstreamer stuff) After that, I tried reemerging mpd -- and hit the very same error again.
Got exactly the same issue on Arch. Since there were practically no real code changes neither to libvorbis 1.3.4 nor mpd in regard to that lib, I figured it must be some linker change, and it indeed is. Reverting this libvorbis commit made mpd compile again for me: https://trac.xiph.org/changeset/18889 ie. https://trac.xiph.org/ticket/1759 resp. https://trac.xiph.org/raw-attachment/ticket/1759/libvorbis-pkgconfig.patch
Since this issue seems to be related to linking, I set LDFLAGS="" and it worked. -Wl,--as-needed is the culprit I haven't had any issues with those LDFLAGS so far...
*** Bug 500336 has been marked as a duplicate of this bug. ***
The problem is in the order the libraries are passed on the command line. The linker will picks up symbols from libraries based on unresolved dependencies it has encountered before, but not after. Moving all dynamic libraries (-lsomething) after all the static libraries (something.a), without changing the relative order between dynamic or between static libraries, resolves the problem. Normally the build system should do this correctly. It may require a bit of digging to find out what goes wrong, but it's probably a missing dynamic library dependency somewhere. By the way, it looks like the problem manifests itself only with the libbfd-based linker. GNU gold has no problems (I don't know why -- maybe it has relaxed requirements on library ordering), so an easy workaround is doing: binutils-config --linker ld.gold ... to select GNU gold as your linker, and resume the merge. If necessary, you can later switch back with: binutils-config --linker ld.bfd
Created attachment 369666 [details, diff] Patch to add libvorbis library dependency where it belongs. I traced this back to a missing dependency on libvorbis in the build rules for libencoder_plugins.a. I have tried to report this upstream, here: http://bugs.musicpd.org/view.php?id=3953 In the meantime, attached is a patch to add the dependency to Makefile.in.
This should be fixed in 0.18.8.
I see this on 0.18.8. The patch is still needed.
0.18.8 emerges fine for me. Thanks for following it up.
(In reply to Søren Dalby Larsen from comment #21) > I see this on 0.18.8. The patch is still needed. I can confirm this. Upstream added a test for libvorbis, but libogg needs to be added too. (By the way, this problem does not occur when the opus USE flag is enabled, because libogg already gets added to the library list for the Opus encoder.) I'll bug upstream about it again; they were willing to fix it quickly last time, so this shouldn't be a problem. (In the meantime, the patch or the workaround I posted above still work.)
(In reply to Maks Verver from comment #23) > (In reply to Søren Dalby Larsen from comment #21) > > I see this on 0.18.8. The patch is still needed. > > I can confirm this. Upstream added a test for libvorbis, but libogg needs > to be added too. > > (By the way, this problem does not occur when the opus USE flag is enabled, > because libogg already gets added to the library list for the Opus encoder.) > > I'll bug upstream about it again; they were willing to fix it quickly last > time, so this shouldn't be a problem. (In the meantime, the patch or the > workaround I posted above still work.) nah, you propably mean bug 500676. different underlinking, different bug.
(In reply to Maks Verver from comment #23) > (In reply to Søren Dalby Larsen from comment #21) > > I see this on 0.18.8. The patch is still needed. > > I can confirm this. Upstream added a test for libvorbis, but libogg needs > to be added too. > > (By the way, this problem does not occur when the opus USE flag is enabled, > because libogg already gets added to the library list for the Opus encoder.) > > I'll bug upstream about it again; they were willing to fix it quickly last > time, so this shouldn't be a problem. (In the meantime, the patch or the > workaround I posted above still work.) libogg needs the fix aswell
*** Bug 508584 has been marked as a duplicate of this bug. ***
*** Bug 508606 has been marked as a duplicate of this bug. ***
