apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 55860] apr build process fails because wrong headers found in directory /usr/local/include
Date Sun, 08 Dec 2013 18:00:13 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=55860

--- Comment #1 from Rainer Jung <rainer.jung@kippdata.de> ---
This doesn't look like a header issue. In that case the compile would have
failed. I also check my local compile output, and it contains the right "-I"
flags.

What is happening here is either that during the linking of "testall" the wrong
(on old) apr library gets found instead of the new one, or - more likely - that
during the test execution the runtime linker uses an old installed apr library.

Can you look first for the linker line in the "make check" output. Mine is
something like:

... /build/path/libtool --silent --mode=link gcc ... -DHAVE_CONFIG_H 
-DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE  
-I../include -I/source/path/test/../include   -no-install    -o testall abts.lo
testutil.lo testtime.lo teststr.lo testvsn.lo testipsub.lo testshm.lo
testmmap.lo testud.lo testtable.lo testsleep.lo testpools.lo testfmt.lo
testfile.lo testdir.lo testfileinfo.lo testrand.lo testdso.lo testoc.lo
testdup.lo testsockets.lo testproc.lo testpoll.lo testlock.lo testsockopt.lo
testpipe.lo testthread.lo testhash.lo testargs.lo testnames.lo testuser.lo
testpath.lo testenv.lo testprocmutex.lo testfnmatch.lo testatomic.lo
testflock.lo testsock.lo testglobalmutex.lo teststrnatcmp.lo testfilecopy.lo
testtemp.lo testlfs.lo testcond.lo testescape.lo ../libapr-1.la   -luuid
-lsendfile -lrt -lsocket -lnsl  -lpthread

Look for the output line containing "-o testall". We see that it references
"../libapr-1.la". The ".." is relative to the test subdirectory. The
libapr-1.la file in the main build directory in turn contains


# The name that we can dlopen(3).
dlname='libapr-1.so.0'

# Names of this library.
library_names='libapr-1.so.0.5.0 libapr-1.so.0 libapr-1.so'

...

# Directory that this library needs to be installed in:
libdir='install/path/lib'


Now we inspect the resulting binary file test/testall:

% elfdump -d test/testall

...
       [0]  NEEDED            0x1704              libapr-1.so.0
...
      [10]  RUNPATH           0x1756             
/build/path/.libs:/install/path/lib
      [11]  RPATH             0x1756             
/build/path/.libs:/install/path/lib

so when running test/testall it would load libapr-1.so first from
/build/path/.libs and if not found there from /install/path/.libs.

Let's check that:

% ldd test/testall
        libapr-1.so.0 =>         /build/path/.libs/libapr-1.so.0

That's correct and the test succeeds during my build.

Can you verify where the above starts to differ for your build?

Do you have any LD_LIBRARY_PATH set during the build (and are there old APR
libraries in one of the dircetories referenced in LD_LIBRARY_PATH)? That would
explain the behavior, because LD_LIBRARY_PATH has stronger preference for the
runtime linker than the RPATH set in the binary itself. There's noting we could
do against that except train users not to set LD_LIBRARY_PATH to a directory
that contains a kitchen sink collection of libraries.

Regards,

Rainer

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message