[geos-devel] cmake detailed comments

Greg Troxel gdt at lexort.com
Fri Oct 15 15:48:23 PDT 2021


Paul Ramsey <pramsey at cleverelephant.ca> writes:

> I'm running your script now, but just from looking at it, this seems
> suspicious...
>
> cmake .. \
>            -DCMAKE_INSTALL_PREFIX=${PREFIX} \
>            -DCMAKE_BUILD_RPATH=${LIBDIR} \
>            -DCMAKE_INSTALL_RPATH=${LIBDIR}
>
> My understanding of the "build rpath" is that it exists in the built
> binaries PRE install, so for build testing, PRE install, you want it
> to point into the local library location. By over-riding it and
> setting it to LIBDIR, you're saying "no no no, please put this path
> into the rpath of of the PRE install binaries". I'd guess/hope that
> removing the CMAKE_BUILD_RPATH while leaving CMAKE_INSTALL_RPATH as
> you have it is closer to the intent, but I'll play with a build
> myself.

I am trying to figure out how to deal with cmake in the general case of
a packaging system.  While geos usually has no dependencies (except
pthreads which are usually part of base but not always), packages built
with cmake in general do have dependencies.   When packages with
dependencies build test programs, those programs will need to find those
dependency libraries.    So they need to have the prefix's libdir in
RPATH.

I think there is only one real bug, which is that cmake uses as RPATH in
the build tree:

 BUILD_RPATH:/path/to/build/tree/lib

when it should be doing

 /path/to/build/tree/lib:BUILD_RPATH

so that when a library is in both places it comes from the build tree.
I do not know if this is a cmake bug or a bug in geos's CMakeFiles, but
I lean to cmake because I don't see anything like this in geos
CMakeFiles.

Consider if geos happened to use libtiff.so and that was in the same
prefix we were talking about.  That's a concrete example of what I'm
speaking about generally.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20211015/462987a7/attachment.sig>


More information about the geos-devel mailing list