scons build not compatible with libtool

[GoogleCodeExporter]

What steps will reproduce the problem?

1. build serf 1.3.0 with scons, using an install prefix that is not in the 
standard library search path
2. build Subversion against serf 1.3.0 

Now Subversion binaries cannot run because libserf-1.so cannot be found.

Adding the $(PREFIX)/serf/lib directory to LD_LIBRARY_PATH works around the 
issue.
Manually passing an rpath to the Subversion build process works around the 
issue, too:
  make EXTRA_LDFLAGS="-Wl,-rpath,$(PREFIX)/serf/lib"

Before serf-1.3.0 this linker argument was handled by libtool.
Can serf please be fixed so that this works out of the box again?

Original issue reported on code.google.com by s...@elego.de on 7 Aug 2013 at 11:31

[GoogleCodeExporter]

This issue might be related to issue 112.

Original comment by s...@elego.de on 7 Aug 2013 at 11:32

[GoogleCodeExporter]

Original comment by chemodax@gmail.com on 9 Aug 2013 at 4:53

• Added labels: scons

[GoogleCodeExporter]

This is with scons-2.3.0.

Original comment by s...@elego.de on 10 Aug 2013 at 3:28

[GoogleCodeExporter]

Stefan,
can you confirm that your r2156 fixes this problem? It's included in serf 1.3.2.
Lieven

Original comment by lieven.govaerts@gmail.com on 5 Oct 2013 at 6:01

[GoogleCodeExporter]

No that doesn't solve the problem because he's not complaining about 
dependencies (which is what r2156 solves).  Rather he's complaining about the 
serf library itself.  The problem here is that Subversion was depending on 
libtool to add the rpath for us.  But serf no longer produces the libtool 
archive (.la) that contains the info for libtool to do that.  I'd guess that 
there would be some objection to generating .la files for serf given that 
you're trying to avoid using autoconf/automake/libtool.  So that means 
Subversion should fix this.

Right now Subversion is still working with serf in these scenarios only because 
we have fallback code that guesses as to the correct link flags when the .la 
file is missing.  This code doesn't add the appropriate rpath flag.  Our 
pkg-config support is fairly incomplete since it doesn't know how to look for 
.pc files under the prefix.  However, even if it did it doesn't really help us 
with this problem.  We could certainly get the path from pkg-config via 
`pkg-config --variable=libdir` but we'd have to know if the rpath is needed 
(library not on a system library path) and we'd have to know how to specify it 
to the compiler/linker.  libtool handled all of that for us and there's really 
no replacement for it.  pkg-config ultimately is really only useful for 
dependency handling of static builds.

I can add "-Wl,-rpath -Wl,$serf_prefix/lib" to our LDFLAGS in serf.m4 
(emulating what libtool does for most platforms) but that's not really 
portable.  So, unless serf wants to start generating .la files I think Stefan's 
workaround is the correct configuration for serf in these situations.  Which is 
unfortunate because now we've managed to push something off onto users that 
they never had to deal with before.

Original comment by breser on 10 Feb 2014 at 7:14