"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes:
> I am alarmed by messing with CMake and RPATH. But maybe things could be
I think what we have now probably made sense for earlier cmake but I
think ti's changed a lot. But your concern is noted and I am reluctant
to cause trouble.
> improved. I just want to raise a voice that I am working on Linux and
> it's crucial that the RPATH _I_ hand into pkgsrc is present in built
> binaries. This means not just the prefix (/usr/pkg/lib equivalent) but
> also toolchain stuff I install beforehand as I do not start out with
> the system gcc and replace some core libs.
What do you mean by "RPATH that you hand into pkgsrc"? Or rather, how
do you specify it, and how does pkgsrc process it?
> I am hazy on the details, but I remember battling CMake not to mess up
> the library paths. So much that I purged the memory to hide the pain, I
> guess. Also, that CMake really likes not to use search paths for
> libraries and pass them to the linker, but rather it searches directly
> for the library and passes /full/path/to/libname.so around. That may be
> why -L does not matter often.
I am not sure if that is cmake itself or CMakeFile culture, but I have
seen that too. I think the binaries end up the same either way.
> So, anything we do to change that … please let's make sure that the
> case of a Linux install with added RPATHDIRS for pkgsrc doesn't break.
> I guess I'll have to do some test pkgsrc building in the near future …
Having dug into this more, I now believe:
cmake wants to manage RPATH explicitly, but does provide knobs
cmake puts one RPATH in the build tree (for running tests) and another
in installed files (or perhaps relinks before install)
cmake appears not to extract RPATH from "-Wl,-R" in LDFLAGS
So I think the right thing is for pkgsrc to know the ordered set of
dirs that should be in RPATH, and pass in eg.
CMAKE_BUILD_RPATH="/usr/pkg/lib"
CMAKE_INSTALL_RPATH="/usr/pkg/lib"
and for your toolchain that would be
CMAKE_{BUILD,INSTALL}_RPATH="/usr/pkg/lib:/path/to/toolhain/lib"
The INSTALL is for the usual reasons in the instal. The BUILD is
necessary so that when test programs are run, they will find the
dependency.
There is a bug in cmake, or perhaps in geos's CMakeFiles, where in the
build tree one gets RPATH set to
/usr/pkg/lib:/path/to/build/dir/lib
instead of
/path/to/build/dir/lib:/usr/pkg/lib
The point is that when running make test, the dependencies still need to
be found (including the toolchain's libstdc++), but the libs that are
part of the current package need to be the new, just built, bring tested
version, not the previous installed version.
So my proposal is:
Don't pass any -Wl,-R LDFLAGS to cmake
pass CMAKE_BUILD_RPATH and CMAKE_INSTALL_RPATH to the full rpath set
fix the cmake bug about the order that build-dir is added
and that perhaps requires some adjustments to pkgsrc to work in terms of
lists of dirs for RPATH, but perhaps that's already there and there's
code to change them into -Wl,-R/foo/lib.
And, cmake might extract RPATH from LDFLAGS and use it for both
variables, or it might just pass them, and if cmake were to put the
build dir -Wl,-R before user-provided LDFLAGS, then things would
probably work.
Attachment:
signature.asc
Description: PGP signature