I checked the package for undefined reference and got undefined reference. For testing purposes LDFLAGS in /etc/make.conf was changed to LDFLAGS="${LDFLAGS} -Wl,-z,-defs -Wl,--no-undefined" The reported problem is in most cases a upstream problem - please report it upstream if it is so. Please use the man page to find the needed library. For example dlsym would need '-ldl' (libld.so) or cosf need '-lm' (libm.so). Current results are following: ------------------------------ ranlib libxmlrpc_client++.a x86_64-pc-linux-gnu-g++ -c -o XmlRpcCpp.osh -Iblddir/include -Isrcdir/include -Iblddir -Isrcdir/lib/util/include -DNDEBUG -Wall -Wundef -Wimplicit -W -Winline -Wundef -Woverloaded-virtual -Wsynth -O2 -pipe -fPIC XmlRpcCpp.cpp In file included from XmlRpcCpp.cpp:30: blddir/include/xmlrpc-c/oldcppwrapper.hpp:59: warning: ‘int XmlRpcFault::getFaultCode() const’ was used before it was declared inline blddir/include/xmlrpc-c/oldcppwrapper.hpp:54: warning: previous non-inline declaration here x86_64-pc-linux-gnu-g++ -shared -Wl,-soname,libxmlrpc_cpp.so.4 -o libxmlrpc_cpp.so.4.14 XmlRpcCpp.osh -Wl,-O1 -Wl,-z,-defs -Wl,--no-undefined XmlRpcCpp.osh: In function `XmlRpcEnv::XmlRpcEnv(XmlRpcEnv const&)': XmlRpcCpp.cpp:(.text+0x65): undefined reference to `xmlrpc_env_init' XmlRpcCpp.osh: In function `XmlRpcEnv::XmlRpcEnv(XmlRpcEnv const&)': XmlRpcCpp.cpp:(.text+0xb5): undefined reference to `xmlrpc_env_init' XmlRpcCpp.osh: In function `XmlRpcFault::XmlRpcFault(int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': XmlRpcCpp.cpp:(.text+0x10d): undefined reference to `xmlrpc_env_init' XmlRpcCpp.osh: In function `XmlRpcFault::XmlRpcFault(int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': XmlRpcCpp.cpp:(.text+0x15d): undefined reference to `xmlrpc_env_init' [...] XmlRpcCpp.osh: In function `XmlRpcFault::XmlRpcFault(int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': XmlRpcCpp.cpp:(.text+0x17e): undefined reference to `xmlrpc_env_set_fault' XmlRpcCpp.osh: In function `XmlRpcFault::XmlRpcFault(XmlRpcFault const&)': XmlRpcCpp.cpp:(.text+0x1c2): undefined reference to `xmlrpc_env_set_fault' XmlRpcCpp.osh:XmlRpcCpp.cpp:(.text+0x202): more undefined references to `xmlrpc_env_set_fault' follow collect2: ld returned 1 exit status make[2]: *** [libxmlrpc_cpp.so.4.14] Error 1 make[2]: Leaving directory `/var/tmp/portage/dev-libs/xmlrpc-c-1.14.07-r1/work/xmlrpc-c-1.14.07/src/cpp' make[1]: *** [cpp/all] Error 2 make[1]: Leaving directory `/var/tmp/portage/dev-libs/xmlrpc-c-1.14.07-r1/work/xmlrpc-c-1.14.07/src' make: *** [src/all] Error 2 Portage 2.2_rc14 (default/linux/amd64/2008.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.26-1-amd64 x86_64) ================================================================= System uname: Linux-2.6.26-1-amd64-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4200+-with-glibc2.2.5 Timestamp of tree: Fri, 14 Nov 2008 12:07:01 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.2-r8 dev-util/cmake: 2.6.1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,-z,-defs -Wl,--no-undefined" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bzip2 cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 isdnlog midi minimal mmx mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session spl sse sse2 ssl sysfs tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text"USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
LDFLAGS="-Wl,-O1 -Wl,-z,-defs -Wl,--no-undefined" Does it link properly when you use the default LDFLAGS?
Yes, because then it will not check for undefined symbols - but on systems without weak linkage the shared object will be broken.
And it is a possible problem when you use --as-needed on a plugin system. So the only possible way that it will work is is when the executable loads the needed shared object with the needed symbols. This can happen when it uses that shared objects (which is a ok but not a perfect situation then) or when it loads this shared object to workaround the problem that is caused by this missing linking to the needed shared object. So the current situation is "works by workaround, but can break everytime in the future"
So these are basically --as-needed bugs? I am merely trying to figure out what it is you're doing (and what the solution would be).
I am testing packages for their symbol linking in shared libraries. I need to build some of the packages on a system without the linux like dynamic loading behavior (so no weak type of dynamic linking where we only look at the symbols if everything is loaded and don't in a random way on the loaded symbols). I have the situation that a library/program must know where it needs to search for a symbol. And they are not only possible --as-needed bugs bug also bad behavior which needs to be workarounded by other packages. Let's say library x is using library y but doesn't link to it. Now program z wants to use library x. So natural way would be that program z links against x and everything is fine. But in this situation it must link against x and y - event when z is not using x directly. Now lets think about the problem that x noticed y is completely broken and implements it in a more sane way. But z is still linked against y - now what do you think which symbol will be used for the implementation of previous faulty functions from y? I would bet on murphy and would say that the faulty functions will still be used by z. Or the other way around when x uses the new functions of library e but don't link against it. Yes, your binary for z will be instant broken even if the usage of x's api should be transparent for z. What should be done? Relative easy it must be checked if it is a gentoo-only problem (patch or misusage of the build system) or if it is in upstream. When it is in upstream then inform them that they forgot to link their library y against z and show them how they can test it. If they release a patch for it then integrate a patch for it in your ebuilds. But their exist of course the possible situation that it was build that way and must be used in that way for a good reason.
+*xmlrpc-c-1.16.06 (03 Dec 2008) + + 03 Dec 2008; Peter Alfredsen <loki_val@gentoo.org> + -files/xmlrpc-c-1.16.04-abyss-disable.patch, + -files/xmlrpc-c-1.16.04-compile.patch, + -files/xmlrpc-c-1.16.04-cpplinking.patch, + -files/xmlrpc-c-1.16.04-linking-order.patch, + +files/xmlrpc-c-1.16.06-no-undefined.patch, -xmlrpc-c-1.16.04.ebuild, + +xmlrpc-c-1.16.06.ebuild: + Add new version. Upstream accepted our fixes from .04. New fixes included + fixing bug 246749. +