Summary: | net-misc/curl[rtmp] forces rebuild of media-libs/raptor and app-office/libreoffice after media-video/rtmpdump update | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nikoli <nikoli> |
Component: | Current packages | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | base-system, gregkh, hwoarang, jstein, sound |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://sourceforge.net/p/curl/bugs/1325/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 498396 | ||
Bug Blocks: | |||
Attachments: |
libcurl.pc
raptor-2.0.9.ebuild.patch |
Description
Nikoli
2014-01-13 05:04:41 UTC
(In reply to Nikoli from comment #0) > After updating media-video/rtmpdump from version 2.3 to 2.4_p20131018 > 'emerge @preserved-rebuild' wants to rebuild raptor because > /usr/lib64/libraptor2.so.0.0.0 links to libcurl.so.4 and librtmp.so.0 (after > rebuild it links to librtmp.so.1) > > 'grep rtmp -Ri .' finds nothing in raptor2-2.0.9 sources, so most likely the > problem is curl related. > There is nothing wrong in the R/DEPENDS of curl. If this is a bug, then its in the way @preserved-rebuild is resolving things. Having said that, I'm not sure its a bug. What does the linkage for all the libraries involved look like? Ie run ldd on libraptor2.so.0.0.0, libcurl.so.4 and librtmp.so.0. (Sorry I don't have your configuration.) # ldd /usr/lib64/librtmp.so.0 linux-vdso.so.1 (0x000002f7a243c000) libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x000002f7a1f2a000) libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x000002f7a1c9f000) libz.so.1 => /lib64/libz.so.1 (0x000002f7a1a86000) libc.so.6 => /lib64/libc.so.6 (0x000002f7a16dd000) libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x000002f7a14a9000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x000002f7a122c000) libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x000002f7a0ffb000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000002f7a0ddf000) libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x000002f7a0bcc000) libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x000002f7a09c7000) /lib64/ld-linux-x86-64.so.2 (0x000002f7a243d000) # ldd /usr/lib64/libcurl.so.4 linux-vdso.so.1 (0x000002fede12f000) libidn.so.11 => /usr/lib64/libidn.so.11 (0x000002feddc5e000) librtmp.so.0 => /usr/lib64/librtmp.so.0 (0x000002fedda43000) libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x000002fedd778000) libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x000002fedd54c000) libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x000002fedd2db000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x000002fedcebb000) libz.so.1 => /lib64/libz.so.1 (0x000002fedcca3000) librt.so.1 => /lib64/librt.so.1 (0x000002fedca9b000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000002fedc87e000) libc.so.6 => /lib64/libc.so.6 (0x000002fedc4d5000) libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x000002fedc24a000) libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x000002fedc015000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x000002fedbd99000) libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x000002fedbb68000) libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x000002fedb955000) libdl.so.2 => /lib64/libdl.so.2 (0x000002fedb751000) /lib64/ld-linux-x86-64.so.2 (0x000002fede130000) libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x000002fedb54b000) # ldd /usr/lib64/libraptor2.so.0.0.0 linux-vdso.so.1 (0x000002f4ec7ec000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x000002f4ec2e5000) libidn.so.11 => /usr/lib64/libidn.so.11 (0x000002f4ec0b0000) librtmp.so.0 => /usr/lib64/librtmp.so.0 (0x000002f4ebe94000) libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x000002f4ebbca000) libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x000002f4eb99e000) libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x000002f4eb72c000) libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x000002f4eb30d000) libicuuc.so.51 => /usr/lib64/libicuuc.so.51 (0x000002f4eaf76000) libxslt.so.1 => /usr/lib64/libxslt.so.1 (0x000002f4ead36000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x000002f4ea9af000) libz.so.1 => /lib64/libz.so.1 (0x000002f4ea797000) libdl.so.2 => /lib64/libdl.so.2 (0x000002f4ea592000) libm.so.6 => /lib64/libm.so.6 (0x000002f4ea293000) librt.so.1 => /lib64/librt.so.1 (0x000002f4ea08b000) libc.so.6 => /lib64/libc.so.6 (0x000002f4e9ce1000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000002f4e9ac5000) libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x000002f4e983a000) libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x000002f4e9605000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x000002f4e9389000) libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x000002f4e9158000) libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x000002f4e8f45000) libicudata.so.51 => /usr/lib64/libicudata.so.51 (0x000002f4e77f9000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x000002f4e74d5000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x000002f4e72bd000) liblzma.so.5 => /lib64/liblzma.so.5 (0x000002f4e7097000) /lib64/ld-linux-x86-64.so.2 (0x000002f4ec7ed000) libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x000002f4e6e91000) So why libraptor2.so.0.0.0 links to librtmp.so.0? please paste the contents of your /usr/lib64/pkgconfig/libcurl.pc Created attachment 367786 [details]
libcurl.pc
What's the output of "curl-config --libs" # curl-config --libs -lcurl -lidn -lrtmp -lz -lgnutls -lssh2 -lssh2 -lssl -lcrypto -lssl -lcrypto -lz -lrt (In reply to Nikoli from comment #2) > So why libraptor2.so.0.0.0 links to librtmp.so.0? Because you have to follow through on the full link chain. If libA links to libB and libB links to libC then ldd libA lists libC. Try using readelf -d and looking at the (NEEDED) section. I think this bug should be closed resolved invalid. I don't see anything wrong here. I used 'objdump -p' and looked at NEEDED before opening this bug. And i think this sure is bug: # objdump -p /usr/lib64/libraptor2.so.0.0.0 |grep NEEDED|sort NEEDED libcrypto.so.1.0.0 NEEDED libc.so.6 NEEDED libcurl.so.4 NEEDED libdl.so.2 NEEDED libgnutls.so.26 NEEDED libicuuc.so.51 NEEDED libidn.so.11 NEEDED libm.so.6 NEEDED librtmp.so.0 NEEDED librt.so.1 NEEDED libssh2.so.1 NEEDED libssl.so.1.0.0 NEEDED libxml2.so.2 NEEDED libxslt.so.1 NEEDED libz.so.1 It should not link to libcrypto.so.1.0.0, libgnutls.so.26, libidn.so.11, librtmp.so.0, libssh2.so.1, libssl.so.1.0.0 Example of correct and expected behaviour for --as-needed: /usr/lib64/libwx_gtk2u_core-2.8.so has libjpeg.so.62 and a lot other libs in NEEDED; /usr/lib64/hugin/libhuginbasewx.so.0.0 has libwx_gtk2u_core-2.8.so.0 in NEEDED, but does not have libjpeg.so.62 and other dep of libwx_gtk2u_core-2.8.so.0. (In reply to Nikoli from comment #8) > I used 'objdump -p' and looked at NEEDED before opening this bug. And i > think this sure is bug: > # objdump -p /usr/lib64/libraptor2.so.0.0.0 |grep NEEDED|sort > NEEDED libcrypto.so.1.0.0 > NEEDED libc.so.6 > NEEDED libcurl.so.4 > NEEDED libdl.so.2 > NEEDED libgnutls.so.26 > NEEDED libicuuc.so.51 > NEEDED libidn.so.11 > NEEDED libm.so.6 > NEEDED librtmp.so.0 > NEEDED librt.so.1 > NEEDED libssh2.so.1 > NEEDED libssl.so.1.0.0 > NEEDED libxml2.so.2 > NEEDED libxslt.so.1 > NEEDED libz.so.1 > > It should not link to libcrypto.so.1.0.0, libgnutls.so.26, libidn.so.11, > librtmp.so.0, libssh2.so.1, libssl.so.1.0.0 > > Example of correct and expected behaviour for --as-needed: > /usr/lib64/libwx_gtk2u_core-2.8.so has libjpeg.so.62 and a lot other libs in > NEEDED; /usr/lib64/hugin/libhuginbasewx.so.0.0 has libwx_gtk2u_core-2.8.so.0 > in NEEDED, but does not have libjpeg.so.62 and other dep of > libwx_gtk2u_core-2.8.so.0. Isn't this a problem in raptor then? Even so, I see libcurl.so.4 in there and that links to librtmp.so.0 so ldd would still show libraptor needing librtmp. Okay as discussed on IRC, this is a problem in curl-config. curl-config --libs gives -lcurl -lrtmp ... which means you need -lrtmp on the linker line when building against libcurl, but you don't. In fact libcurl.pc is correct with. I'll submit this upstream. Upstream at https://sourceforge.net/p/curl/bugs/1325/ Upstream answer: "curl-config should only list the full set of libraries if libtool indicates that the target system requires that. What is the output of: libtool --config | grep link_all_deplibs on this system? If it's anything other than "link_all_deplibs=no" then curl is doing the right thing, according to libtool." In Gentoo we have: $ libtool --config | grep link_all_deplibs link_all_deplibs=unknown I think it would be better to change link_all_deplibs= to 'no' in libtool package, Debian did so years ago, but this change may break some packages. (In reply to Nikoli from comment #12) > Upstream answer: > "curl-config should only list the full set of libraries if libtool indicates > that the target system requires that. What is the output of: > > libtool --config | grep link_all_deplibs > > on this system? If it's anything other than "link_all_deplibs=no" then curl > is doing the right thing, according to libtool." > > In Gentoo we have: > $ libtool --config | grep link_all_deplibs > link_all_deplibs=unknown > > I think it would be better to change link_all_deplibs= to 'no' in libtool > package, Debian did so years ago, but this change may break some packages. These -config scripts cause no end of issues! 1) Can raptor et al. swtich to using pkgconfig which is the sane way to go? 2) I don't thing switching link_all_deplibs is the way to go here. While I haven't tested I'm certain this will break a lot. We'd have to open a tracker and follow packages that break. Just to save the buggy -config's? (In reply to Anthony Basile from comment #13) i see no reason as to why they can't switch to the pkg-config file. it's the sane answer. the libtool link thing is bug 498396 already (listed as a blocker here). (In reply to Anthony Basile from comment #13) > These -config scripts cause no end of issues! > > 1) Can raptor et al. swtich to using pkgconfig which is the sane way to go? curl and raptor has been using pkg-config since forever, any -config's are just for backwards compability (switch happened years ago) $ pkg-config --exists raptor2 $ echo $? 0 $ pkg-config --exists libcurl $ echo $? 0 (In reply to Samuli Suominen from comment #15) > (In reply to Anthony Basile from comment #13) > > These -config scripts cause no end of issues! > > > > 1) Can raptor et al. swtich to using pkgconfig which is the sane way to go? > > curl and raptor has been using pkg-config since forever, any -config's are > just for backwards compability (switch happened years ago) > > $ pkg-config --exists raptor2 > $ echo $? > 0 > $ pkg-config --exists libcurl > $ echo $? > 0 I didn't look myself. So where is the curl-config script causing the problem? (In reply to Anthony Basile from comment #16) > I didn't look myself. So where is the curl-config script causing the > problem? You started talking about it at Comment #10 at this bug, referencing some IRC discussion. You tell us. :-) (In reply to Samuli Suominen from comment #17) > (In reply to Anthony Basile from comment #16) > > I didn't look myself. So where is the curl-config script causing the > > problem? > > You started talking about it at Comment #10 at this bug, referencing some > IRC discussion. You tell us. :-) Were we barking up the wrong tree in comments #5 thorugh #10? dilfridge asked in comment #5 about "curl-config --libs" so I assumed that was the culprit. If none of the packages described in comment #0 use curl-config then is it purely link_all_deplibs? Created attachment 368162 [details, diff]
raptor-2.0.9.ebuild.patch
$ equery f curl|grep curl-config
/usr/bin/curl-config
/usr/share/man/man1/curl-config.1.bz2
If you read raptor2-2.0.9/configure.ac, you will see that build system by default is using /usr/bin/*-config for most deps instead of pkg-config, but for some deps you can force using of pkg-config by adding '--with-foo-config=no' to configure options:
$ grep '\-config' configure.ac
# for raptor-config.in
AC_CHECK_PROGS(PKG_CONFIG, pkg-config)
AC_ARG_WITH(xml2-config, [ --with-xml2-config=PATH Location of libxml xml2-config []], xml2_config="$withval", xml2_config="")
AC_CHECK_PROGS(XML_CONFIG, xml2-config)
AC_MSG_CHECKING(for libxml via xml2-config)
libxml_source="xml2-config"
AC_MSG_CHECKING(for libxml via pkg-config)
libxml_source="pkg-config"
AC_ARG_WITH(xslt-config, [ --with-xslt-config=PATH Location of libxslt xslt-config []], xslt_config="$withval", xslt_config="")
AC_CHECK_PROGS(XSLT_CONFIG, xslt-config)
AC_ARG_WITH(curl-config, [ --with-curl-config=PATH Location of libcurl curl-config []], curl_config="$withval", curl_config="")
AC_CHECK_PROGS(CURL_CONFIG, curl-config)
AC_MSG_CHECKING(for libcurl via curl-config)
libcurl_source="curl-config"
AC_MSG_CHECKING(for libcurl via pkg-config)
libcurl_source="pkg-config"
AC_ARG_WITH(icu-config, [ --with-icu-config=PATH Location of ICU icu-config []], icu_config="$withval", icu_config="")
dnl Note there is NO automated searching for icu-config
AC_ARG_WITH(www-config, [ --with-libwww-config=PATH Location of W3C libwww libwww-config []], libwww_config="$withval", libwww_config="")
$ grep '"Xno"' configure.ac
if test "X$xml2_config" != "Xno" ; then
if test "X$xslt_config" != "Xno" ; then
if test "X$curl_config" != "Xno" ; then
if test "X$icu_config" != "Xno" -a "X$icu_config" != "X" ; then
if test "X$libwww_config" != "Xno" -a "X$libwww_config" != "X" ; then
'-with-xml2-config=no --with-curl-config=no' works fine for me and disables linking to curl deps (libcrypto.so.1.0.0 libidn.so.11 libssh2.so.1 libssl.so.1.0.0), but when --with-xslt-config=no or --with-icu-config=no is used raptor does not link to xslt or icu libs.
(In reply to Nikoli from comment #19) > Created attachment 368162 [details, diff] [details, diff] > raptor-2.0.9.ebuild.patch Nikoli thanks. I think with the next bump of curl, I may try to just not install curl-config and tack what packages break and offer fixes along the line of pkgconfig. Tracker for migrating away from curl-config to pkg-config feasible? (In reply to Samuli Suominen from comment #21) > Tracker for migrating away from curl-config to pkg-config feasible? Yes. Tom made a patch for libreoffice and I've added it in ~arch and later (no revbump). Patch added to raptor. (libreoffice already fixed.) Nothing else to do here. @blueness: do you still want to make a tracker? If not I guess we can close this... (In reply to Andreas K. Hüttel from comment #24) > Patch added to raptor. (libreoffice already fixed.) > > Nothing else to do here. > > @blueness: do you still want to make a tracker? If not I guess we can close > this... I don't know if we caught them all, but what I'll do when 7.36 comes out is simply remove curl-config. As packages break people will open bugs and I'll start tracking them then. I don't think we have a huge amount of breakage coming (eg as we do with a glibc bump or gcc bump) so we can get them one at a time. net-misc/curl-7.45.0 is the latest version in the tree now. Is the bug still active, or can we close the ticket? I've never observed this problem, cannot reproduce it, and it's been a couple years with new versions of things released since... If this behavior is observed again, please reopen. |