[pdal] PDAL 2.0.1 build issue

[Jim Klassen]

I found the difference.

The way to reproduce it is to call cmake with "-DBUILD_SHARED_LIBS=ON -DWITH_TESTS=ON".  Without BUILD_SHARED_LIBS, gtest only builds a '.a' file under the lib directory in the build directory which is fine.  With BUILD_SHARED_LIBS=ON, gtest also tries to build a .so in /src which fails due to permissions.

As PDAL builds shared libs by default anyway, the BUILD_SHARED_LIBS option isn't necessary and can just be dropped from my build script.

Thanks for the help and encouragement to sort this out.

Jim

On 9/16/19 10:26 AM, Andrew Bell wrote:
> I'll just suggest again that there's something special about this environment, because this is not an issue on other similar systems.
>
> On Mon, Sep 16, 2019, 17:23 Howard Butler <howard at hobu.co <mailto:howard at hobu.co>> wrote:
>
>
>
>     > On Sep 16, 2019, at 10:02 AM, Jim Klassen <klassen.js at gmail.com <mailto:klassen.js at gmail.com>> wrote:
>     > After multiple attempts at rummaging around, I think the culprit is in 'cmake/gtest.cmake'.  I suspect that ${gtest_BINARY_DIR} is unset.  Based on comments in 'vendor/gtest/CMakeLists.txt' it appears that it may also use this variable internally.
>
>     Interesting. We're definitely doing non-sudo builds on other platforms. I wonder how gtest_BINARY_DIR is getting properly set in those cases.
>
>     Howard
>     _______________________________________________
>     pdal mailing list
>     pdal at lists.osgeo.org <mailto:pdal at lists.osgeo.org>
>     https://lists.osgeo.org/mailman/listinfo/pdal
>
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20190917/c5b7d4bd/attachment.html>