On 04/28/2012 07:50 PM, Darrell Anderson wrote: I don't know exactly which are required. There are only one or two packages I need to add LDPATH with /opt/trinity/lib/trinity. The big issues have been with the use of /opt/trinity/lib/trinity instead of /opt/trinity/lib/kde, but most of those issues are already fixed. If you are having issues with /opt/trinity/lib/trinity, I'd make sure something isn't looking for /opt/trinity/lib/kde. -- David C. Rankin, J.D.,P.E.

Try running ldconfig against /opt/trinity/lib/trinity and then retry opening it to see if you still get the message. Jay On Sun, Apr 29, 2012 at 2:13 AM, Darrell Anderson <humanreadable(a)yahoo.com>wrote;wrote:

I don't understand the full technical aspects of what you wrote, :-) but what you wrote matches the particular error messages I'm seeing. Although I asked the question, I was leaning toward /opt/trinity/lib/trinity not being necessary in /etc/ld.so.conf because the equivalent /usr/lib/kde[3] never was needed with KDE3 and everything works as expected. The peculiar thing about this problem is only kword and kpresenter are affected. Possibly there are other "undefined symbol" problems in my builds that I have not yet noticed, but I'm guessing kword and kpresenter are not linking correctly during my builds. I don't know how to debug further or what to look for. Darrell

On 29 Apr 2012, Darrell Anderson uttered the following: Sounds like I was incomprehensible as usual. Job done! :P Stripping away some of my redundant geekberish, the rule is simple enough: If you link against a shared library via -L/some/dir/here -lfoo, then the dynamic linker is going to be locating your library itself, at process startup (or shared library load), so the directory in which that library is located must exist in /lib/ld.so.conf, and /sbin/ldconfig must be rerun to update /etc/ld.so.cache. If you load a shared library via dlopen(), you have to give the path to the library there, so there is no need to update ld.so.conf or update ld.so.cache. (Plugins, like the stuff in /usr/lib/kde3 or /opt/trinity/lib/trinity, are invariably opened via dlopen().) Some extra complexities, rarely important, ludicrously overdesigned, partly undocumented (I should fix that): - you can override the load path for shared libraries with the LD_LIBRARY_PATH environment variable. This is prepended to the list in ld.so.conf. Don't put a lot in here: it can't be cached and has to be searched on every process startup. Older Unixes with no ld.so cache often grew insanely long paths in their LD_LIBRARY_PATH. These days this is a sign of bad taste. - there is a 'system list', normally /lib and /usr/lib, which is searched anyway, even if not named in ld.so.conf. If you link with -z nodefaultlib, this is left out. - there are two ELF tags DT_RPATH and DT_RUNPATH which can also specify colon-separated paths for libraries linked with that executable or shared library. DT_RPATH is strongly deprecated because it is applied *before* LD_LIBRARY_PATH et al, so if it points into a dead network share you will freeze solid whenever you try to start the program. DT_RUNPATH is recommended instead: it is searched later. (In general it is rare to see either used, thank goodness.) There are a few magic tags that can be used in the paths in DT_RPATH and DT_RUNPATH. $ORIGIN means "." (and is only valid in non-setuid programs for hopefully obvious reasons); $PLATFORM is the platform name (which used to be the value returned by 'uname -p', but since this is almost always 'unknown' these days is now a value derived from the AT_PLATFORM entry in the ELF auxiliary vector supplied by the kernel: something like 'x86_64'); $LIB is the system library directory (/lib, /lib64, something like that). - the dynamic linker additionally searches a number of other directories under each directory named in ld.so.conf, in response to the hardware capabilities of the system (hence the glibc geek name for this 'hwcaps'). The underlying data for this consists of a 32-bit long passed down from the kernel in the ELF auxiliary vector: running any program with the LD_SHOW_AUXV=t environment variable set will show you this vector. The hwcap string is decoded by code in sysdeps/*/dl-procinfo.[ch] (e.g. sysdeps/i386/dl-procinfo.h): if present, subdirectories named after hwcaps found on the machine are searched before the directories named in ld.so.conf. (The hwcaps are often named the same as the flags in the flags string in /proc/cpuinfo, so you don't need to go through all this rigmarole just to figure out what your machine's hwcaps are). (There is an additional fake hwcap 'tls' which is present only if glibc is capable of thread-local storage, but this is rather irrelevant these days when virtually every system, desktop or not, has TLS support.) (Shared libraries can also add names to the currently-valid list of hwcaps, but I've never seen this feature used. You can mask out hwcaps you don't want the system to pay attention to using the DL_HWCAP_MASK environment variable, but this is really only a debugging aid, or at least I can't imagine another circumstance when you'd want to set it.) The upshot of all this is that if you have both e.g. MMX and non-MMX-capable versions of a library, you can put the MMX version in a subdirectory of the libdir named 'mmx' and it will be picked up automatically if the hardware is capable of MMX. This is most commonly used on 32-bit x86 to allow support of 686-class machines that do not support the CMOV instruction (e.g. the Geode LX) by putting CMOV-capable libraries in a cmov/ subdirectory, but it has other uses. - But that's not all! Any shared libraries named in the LD_PRELOAD environment variable will be loaded before *any* others. This means they can get in first and override symbols in those other libraries, (often deferring to the original symbols later via dlsym (RTLD_NEXT, ...). This is a useful hooking technique for all sorts of obscure purposes: e.g. fakeroot relies on it, as does the Electric Fence malloc debugger. - But that's not all! Any shared libraries named in /etc/ld.so.preload will be loaded before any others *systemwide*. Using this for anything at all is generally a sign of galloping insanity or being a toolchain or kernel developer (but I repeat myself). So library loading happens in the order (initial executable load only) (executable mapped by kernel) /lib/ld-linux.so.2 (or whatever is specified in the DT_INTERP section of the executable: mapped by kernel) /etc/ld.so.preload from LD_PRELOAD (executables and shared libraries below here) from DT_RPATH tag (with all the $ORIGIN/$PLATFORM/$LIB madness) from LD_LIBRARY_PATH from DT_RUNPATH tag (as for DT_RPATH) /etc/ld.so.conf (with all the hwcap searching madness) If all of these things are in use at the same time, expect to get very, very seriously confused! Thankfully almost all you ever need to pay attention to is /etc/ld.so.conf, and (on proprietary systems) LD_LIBRARY_PATH. You might find the linker flag --no-undefined (-Wl,--no-undefined in LDFLAGS) to be useful. (I thought Trinity was passing it already, but I could be wrong.) Other more-or-less-obscure things you might find useful in this hunt: - dynamic linker symbol debugging, set LD_DEBUG=symbols before running the program: very verbose: see also LD_DEBUG=help (then run any dynamically-linked program at all, e.g. LD_DEBUG=help ls) - linker symbol tracing, -Wl,--trace-symbol=SYMBOL in LDFLAGS, which prints every file the named symbol appears in -- NULL && (void)

On 30 Apr 2012, Darrell Anderson spake thusly: Windows PE's path searching and symbol resolution rules are much too simplistic. ELF's are, I think all agree, much too complicated. :) Oh. Well, if --no-undefined is used, it should be impossible to have undefined symbols after you've finished linking. If you have them, it is probable that the shared libraries you are running against (as shown via ldd) are not the same as the ones you linked against. If you extract the link line for one of the failing programs and rerun it from the same directory wihout --silent, you'll get a gcc command: re-execute that with -Wl,--verbose attached, and you'll see what libraries are being picked up, and from where. The symbol whose resolution is failing :) but it's likely it won't appear there at all, except as an undefined symbol being searched for. It is true that running it on a KDE program is likely to be suicidal, it produces insane amounts of output even when you run it on ls(1) :) As above, run the link command for the failing program by hand without --silent to get the GCC command used to link, then re-execute that with -Wl,--trace-symbol=FOO (where FOO is the symbol reported as being undefined). That'll tell you what library it was found in at link time. I bet you'll find that you've got two copies of that library on your system somehow, and the library ldd tells you it's picking up when you run ldd on the failing binary is the other one... or that at least it's not got the same contents as the one that the --trace-symbol reports that the symbol is found in. -- NULL && (void)

Whew. So much information.... Thanks. I'll have to chew my way slowly through all of this. I don't want to spend time chasing wild geese. The problem is (presumably) limited to kword and kpresenter. I haven't yet found any other apps that behave this way or seem to have built with undefined symbols. I should launch every single app and verify the problem is limited to those two apps. I hate crap like this. PITFA. Darrell