Hello All- The problem can be illustrated by trying this out: osc co openSUSE:Factory attr cd openSUSE:Factory/attr quilt setup attr.spec cd attr-2.4.39/ ./configure make strace getfattr/getfattr / Here is a snip from that strace: open("/home/philips/projects/openSUSE/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/philips/projects/openSUSE/x86_64", 0x7ffffec11540) = -1 ENOENT (No such file or directory) open("/home/philips/projects/openSUSE/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/home/philips/projects/openSUSE", 0x7ffffec11540) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/tls/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/tls/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) open("Factory/attr/attr-2.4.39/libattr/.libs/x86_64/libattr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) Not ideal! The process is trying to load obviously non-existent libraries. This is because libtool creates a wrapper for getfattr so it will be executed using local libraries built in the source tree instead of the system libraries: # Add our own library path to LD_LIBRARY_PATH LD_LIBRARY_PATH="/home/philips/projects/openSUSE:Factory/attr/attr-2.4.39/libattr/.libs:$LD_LIBRARY_PATH" But it is breaking because LD_LIBRARY_PATH uses colon characters as a separator like PATH... I talked to the libtool maintainer about this and he said: On 07:37 Thu 18 Dec 2008, Ralf Wildenhues wrote:
I have found that libtool generates temporary wrappers with improperly escaped LD_LIBRARY_PATH. If the current directory path contains a colon. For example /home/philips/test:directory/attr-2.4.43/
Where is it documented that LD_LIBRARY_PATH is interpreted as with backslash escaping for colons in the names? I've never heard of that before.
The ld.so(1) man page on my Debian testing system documents that LD_LIBRARY_PATH is interpreted similarly to PATH. I confirmed now that PATH uses this kind of colon escaping, surprisingly. I cannot find it documented anywhere though, certainly not in the Posix pages (but hey, I overlooked things before).
We can think about supporting it when and where this is suitably safe to do so, but my gut reaction would be "don't do it when it hurts".
Ralf's first point is correct. ld doesn't accept \: as a literal colon like PATH does. So, we will need to fix this first. _ OR _ Instead of taking on the pain of fixing ld and all of the tools and scripts to generate and understand slash escaped colon characters we could stop using colon as a separator in build service project names. Upstream maintainers are not going to be excited about fixing the colon character problem up because the build service is probably the only thing using it. So, can we please use another separator? Perhaps the dash "-". This character is well accepted and works across http/dns/sh/etc without escaping or special consideration. Doing nothing about this isn't an option. Many packages use this trick to test programs as they sit in the source tree without doing a `make install`. If we do nothing developers who are new to OBS and unaware of the issue will waste time, as I did, trying to figure out why their library fixes aren't working. Thoughts? Thanks, Brandon P.S. I first filed a bug against libtool here: https://bugzilla.novell.com/show_bug.cgi?id=460044 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org