Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 246749 - dev-libs/xmlrpc-c-1.14.07-r1 - XmlRpcCpp.cpp:(.text+0x17e): undefined reference to `xmlrpc_env_set_fault'
Summary: dev-libs/xmlrpc-c-1.14.07-r1 - XmlRpcCpp.cpp:(.text+0x17e): undefined referen...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Peter Alfredsen (RETIRED)
Depends on:
Blocks: 246757
  Show dependency tree
Reported: 2008-11-14 16:09 UTC by Robert Wohlrab
Modified: 2008-12-03 00:42 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Robert Wohlrab 2008-11-14 16:09:33 UTC
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' ( or cosf need '-lm' (

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,   -o 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]: *** [] 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-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"
CFLAGS="-O2 -pipe"
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"
FEATURES="distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch"
LDFLAGS="-Wl,-O1 -Wl,-z,-defs -Wl,--no-undefined"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
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"
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-14 16:32:22 UTC
LDFLAGS="-Wl,-O1 -Wl,-z,-defs -Wl,--no-undefined"

Does it link properly when you use the default LDFLAGS?
Comment 2 Robert Wohlrab 2008-11-14 16:35:13 UTC
Yes, because then it will not check for undefined symbols - but on systems without weak linkage the shared object will be broken.
Comment 3 Robert Wohlrab 2008-11-14 16:42:58 UTC
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"
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2008-11-14 17:12:40 UTC
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).
Comment 5 Robert Wohlrab 2008-11-14 17:34:38 UTC
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.
Comment 6 Peter Alfredsen (RETIRED) gentoo-dev 2008-12-03 00:42:03 UTC
+*xmlrpc-c-1.16.06 (03 Dec 2008)
+  03 Dec 2008; Peter Alfredsen <>
+  -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.