Summary: | dev-libs/xmlrpc-c-1.14.07-r1 - XmlRpcCpp.cpp:(.text+0x17e): undefined reference to `xmlrpc_env_set_fault' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Wohlrab <robert.wohlrab> |
Component: | New packages | Assignee: | Peter Alfredsen (RETIRED) <loki_val> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jer |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 246757 |
Description
Robert Wohlrab
2008-11-14 16:09:33 UTC
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. + |