Created attachment 351688 [details] build log System updates today included net-libs/ptlib-2.12.4 and net-libs/opal-3.12.4. net-libs/opal-3.12.4 emerge fails the configure phase when checking for PTLib and states that a linkable PTLib is not found. The opal-3.12.4 configure phase states that PTLIB_REQUIRED_VERSION = 2.12.3.
Created attachment 351690 [details] config log
Created attachment 351692 [details] emerge --info
confirm, have such errors. >>> Emerging (2 of 2) net-libs/opal-3.12.4 >>> Failed to emerge net-libs/opal-3.12.4, Log file: >>> '/var/tmp/portage/net-libs/opal-3.12.4/temp/build.log' >>> Jobs: 1 of 2 complete, 1 failed Load avg: 2.91, 1.70, 1.14 * Package: net-libs/opal-3.12.4 * Repository: gentoo * Maintainer: neurogeek@gentoo.org voip@gentoo.org * USE: amd64 audio dtmf elibc_glibc examples fax ffmpeg h323 iax java kernel_linux plugins sip sipim ssl theora userland_GNU video wav x264 xml * FEATURES: preserve-libs sandbox * Using: oracle-jdk-bin-1.7 >>> Unpacking source... >>> Unpacking opal-3.12.4.tar.bz2 to /var/tmp/portage/net-libs/opal-3.12.4/work >>> Source unpacked in /var/tmp/portage/net-libs/opal-3.12.4/work >>> Preparing source in /var/tmp/portage/net-libs/opal-3.12.4/work/opal-3.12.4 ... * Applying opal-3.10.9-svn_revision_override.patch ... [ ok ] * Applying opal-3.10.9-labs_is_in_stdlib.patch ... [ ok ] * Applying opal-3.12.4-avoid_cflags_mixup.patch ... [ ok ] * Applying opal-3.12.4-java-ruby-swig-fix.patch ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/net-libs/opal-3.12.4/work/opal-3.12.4 ... ... ... checking for x86_64-pc-linux-gnu-ar... x86_64-pc-linux-gnu-ar checking for working bit scan intrinsic... no configure: Opal version is 3.12.4 PTLIB_REQUIRED_VERSION = 2.12.3 checking for PTLIB... yes CXXFLAGS = -march=native -O2 -pipe -fno-visibility-inlines-hidden -fno-strict-aliasing -Wall -Wextra -Wstrict-aliasing -Wfloat-equal -Wno-comment -Wno-unused -Winit-self -Wno-missing-field-initializers PKG_CONFIG_PATH = /usr/lib64/pkgconfig DL_LIBS = LIBS = checking linkable PTLib... not found PTLIB_VERSION=2.12.4 PTLIB_CFLAGS=-DP_64BIT -DPTRACING=0 -DPASN_NOPRINTON -DPASN_LEANANDMEAN -D_REENTRANT -D_GNU_SOURCE=1 -D_REENTRANT -fno-exceptions -I/usr/include/SDL PTLIB_CXXFLAGS=-felide-constructors -Wreorder PTLIB_LIBS=-lpthread -lrt -lssl -lcrypto -lexpat -lpcap -lresolv -ldl -lpt !!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-libs/opal-3.12.4/work/opal-3.12.4/config.log * ERROR: net-libs/opal-3.12.4 failed (configure phase): * econf failed *
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64/libpt.so: undefined reference to `SDL_Quit' Similar usually reads "revdep-rebuild required", though this particular case likely won't be detected. Try rebuilding ptlib, if that doesn't help, this bug will be against ptlib.
Rebuilding ptlib does not help, the error with opal persists after rebuilding ptlib.
If the error in opal config.log is the same, attach build log and config.log from ptlib build.
Created attachment 351734 [details] ptlib-2.12.4 build log
Created attachment 351736 [details] ptlib-2.12.4 config log
Same error here, rebuilding ptlib does not help.
(In reply to Jason Lamb from comment #7) > Created attachment 351734 [details] > ptlib-2.12.4 build log ...*verbose* build log, that is. Also, out of curiosity, 'ldd -r' on ptlib.
Created attachment 351752 [details] ptlib-2.12.4 build log (derived from using ebuild --debug option) ldd -r /usr/lib64/libpt.so.2.12.4 linux-vdso.so.1 (0x00007fff703ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5d2058c000) librt.so.1 => /lib64/librt.so.1 (0x00007f5d20384000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f5d20139000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f5d1ff29000) libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f5d1fcba000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f5d1f8d0000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f5d1f6a6000) libpcap.so.1 => /usr/lib64/libpcap.so.1 (0x00007f5d1f466000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f5d1f24e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f5d1f04a000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/libstdc++.so.6 (0x00007f5d1ed41000) libc.so.6 => /lib64/libc.so.6 (0x00007f5d1e995000) /lib64/ld-linux-x86-64.so.2 (0x00007f5d20db7000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f5d1e6c7000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f5d1e494000) libz.so.1 => /lib64/libz.so.1 (0x00007f5d1e27d000) libm.so.6 => /lib64/libm.so.6 (0x00007f5d1df87000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1 (0x00007f5d1dd71000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f5d1db6c000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f5d1d961000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f5d1d75d000) undefined symbol: SDL_Quit (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_UnlockYUVOverlay (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_CreateYUVOverlay (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_FreeYUVOverlay (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_Init (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_SetVideoMode (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_WM_SetCaption (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_WaitEvent (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_DisplayYUVOverlay (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_LockYUVOverlay (/usr/lib64/libpt.so.2.12.4) undefined symbol: SDL_PushEvent (/usr/lib64/libpt.so.2.12.4)
(In reply to Jason Lamb from comment #11) Not what I've meant (though 'ldd -r' shows what was expected). Something like 'V=1 emerge' should work for the log.
Created attachment 351764 [details] V=1 emerge ptlib-2.12.4 build log
OK, I'm still going through the tarball, but one thing is clear: ptlib-2.10.9-pkgconfig_ldflags.patch was always broken - if that problem was fixed correctly, this bug wouldn't happen. The upstream repo is bit messy - in v2_12 libSDL is added correctly since the first commit, but in the tarball it's not. Compare configure.ac for a patch.
*** Bug 474566 has been marked as a duplicate of this bug. ***
CC:'ing scarabeus as he committed 2.12.4 to the tree
Well yea I did, but I tested only with default useflags and it was happy that way :-) I have not much idea how insanely it is packaged so I can't think of easy patch for this.
(In reply to Chí-Thanh Christopher Nguyễn from comment #16) > CC:'ing scarabeus as he committed 2.12.4 to the tree That most likely maters little. While I haven't checked the older tarballs yet and can't find the bug, that resulted in the incorrect ptlib-2.10.8-pkgconfig_ldflags.patch (as that's according to sources.g.o was the first version), it was then the mistake was made. Probably upstream already had this problem back then and that patch simply masked it for most usecases.
Yes, but now the breakage became user-visible. We best remove it from visibility again by either p.masking the affected versions or the sdl USE-flag, while a proper solution is being investigated.
sdl flag is now masked for =ptlib-2.12* until the issue can be addressed.
Fixed in cvs. The upstream should really really rewrite their buildsystem properly. @chithead: if you spent the same time fixing it instead of figuring what to mask you would solve it too, took me ~15 minutes even with compiling on 800mhz cpu.
(In reply to Chí-Thanh Christopher Nguyễn from comment #19) > Yes, but now the breakage became user-visible. We best remove it from > visibility again by either p.masking the affected versions or the sdl > USE-flag, while a proper solution is being investigated. I already said the proper solution is in the mess, that's the upstream repo, i.e.: on v2_12 branch in configure.ac, things look right from the start; in trunk commit 20685 goes straight from AC_CHECK_LIB to a version that looks correct, even tag v2_12_1 looks fine. It simply looks as if the tarball for 2.12.4 was made from some unpublished branch. Still, comparing configure.ac from the tarball and v2_12 branch should give you an idea for a proper fix (and drop the broken patch while you're on it).
As my previous comment was a bit late, I'd need to repeat the part about dropping the old incorrect patch. Unless I'm missing something, the change it makes would doesn't really make sense at all.
Reopening for proper fix.
Sorry it took me some time to reach this bug. Scarabeus actually added the patch to fix this: 24 Jun 2013; Tomáš Chvátal <scarabeus@gentoo.org> +files/ptlib-2.12.4-sdl-linking.patch, ptlib-2.12.4.ebuild: Fix building when linking to sdl, the libs were not propagated properly. Wrt bug#474362. Thanks for that, Tomáš (In reply to Rafał Mużyło from comment #23) > As my previous comment was a bit late, I'd need to repeat the part about > dropping the old incorrect patch. > Unless I'm missing something, the change it makes would doesn't really make > sense at all. Well, this patch comes a long way. Some versions ago, LDFLAGS contained invalid flags for the linker, while ENDLDLIBS had the correct linking information. It seems that for this particular version, the fixed the problem with LDFLAGS while maintaining ENDLDLIBS as well. Unless I am missing something else, the patch is still valid, only maybe that without it, everything might work as expected. Closing this one.
...but with such patch, unless you're using '-Wl,--as-needed', you tend to overlink a lot. Of course, your choice.
