[gdal-dev] Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0
Jim Klassen
klassen.js at gmail.com
Wed May 15 12:52:48 PDT 2019
I know I am late to the party, but I ran into the same thing today
(Building Proj 6, GDAL 3 on Debian Stretch). I got around it by setting
LDFLAGS before running ./configure so the linker finds the proj 6
install first. Without setting LDFLAGS, ./configure would find the new
proj, but libtool would try to link to the system one (by full path no
less, not just -lproj).
So assuming proj 6 (and GDAL) is installed in $INSTALL_DIR:
export LDFLAGS="-L${INSTALL_DIR}/lib -Wl,-rpath,${INSTALL_DIR}/lib"
./configure \
--prefix="${INSTALL_DIR}" \
--with-proj="${INSTALL_DIR}"
I'm not sure if it matters, but I also set
CMAKE_INSTALL_RPATH=$INSTALL_DIR when I build proj.
On 5/8/19 6:54 PM, Simon Eves wrote:
> I removed the system libgdal-dev and proj-bin, and then this sequence
> worked, with ldd showing the local proj, and the apps all compile.
>
> Still convinced I'm doing something stupid and n00b, but what? Why
> didn't the local proj DSO take priority before?
>
> On Wed, May 8, 2019 at 9:29 AM Simon Eves <simon.eves at omnisci.com
> <mailto:simon.eves at omnisci.com>> wrote:
>
> $ ls -l /home/simon.eves/scratch/gdal3/install/lib/
> total 107536
> -rw-r--r-- 1 simon.eves mapd 79490260 May 8 09:06 libproj.a
> -rwxr-xr-x 1 simon.eves mapd 998 May 8 09:06 libproj.la
> <http://libproj.la>
> lrwxrwxrwx 1 simon.eves mapd 17 May 8 09:06 libproj.so ->
> libproj.so.15.0.0
> lrwxrwxrwx 1 simon.eves mapd 17 May 8 09:06 libproj.so.15
> -> libproj.so.15.0.0
> -rwxr-xr-x 1 simon.eves mapd 30610584 May 8 09:06 libproj.so.15.0.0
> drwxr-xr-x 2 simon.eves mapd 4096 May 8 09:06 pkgconfig
>
>
> On Wed, May 8, 2019 at 9:25 AM Simon Eves <simon.eves at omnisci.com
> <mailto:simon.eves at omnisci.com>> wrote:
>
> No, it shows /usr/lib/x86_64-linux-gnu/libproj.sso.12 (the
> system-installed Proj 5.2.0)
>
> I just did it all again from scratch...
>
> $ echo $LD_LIBRARY_PATH
> /home/simon.eves/scratch/gdal3/install/lib:/usr/local/mapd-deps/lib64:/usr/local/mapd-deps/lib:/usr/local/cuda/lib64
> $ cd /home/simon.eves/scratch/gdal3/
> $ rm -rf gdal-3.0.0 proj-6.0.0 install/*
> $ tar xzvf proj-6.0.0.tar.gz
> $ cd proj-6.0.0/
> $ ./configure --prefix=/home/simon.eves/scratch/gdal3/install
> $ make -j12
> [completes]
> $ make install
> [completes]
> $ cd ..
> $ tar xvf gdal-3.0.0rc2.tar
> $ cd gdal-3.0.0/
> $ ./configure --prefix=/home/simon.eves/scratch/gdal3/install
> --without-geos --with-kml=/usr/local/mapd-deps
> --with-proj=/home/simon.eves/scratch/gdal3/install
> [completes, shows Proj >= 6.0 yes]
> $ make -j12
> [fails in first app as before]
> $ ldd .libs/libgdal.so | grep proj
> libproj.so.12 => /usr/lib/x86_64-linux-gnu/libproj.so.12
> (0x00007f3d98cb3000)
>
> What am I doing wrong, such that the combination of
> $LD_LIBRARY_PATH priority and --with-proj still isn't making
> GDAL see the local Proj before the system one?
>
> Simon
>
> On Wed, May 8, 2019 at 12:41 AM Even Rouault
> <even.rouault at spatialys.com
> <mailto:even.rouault at spatialys.com>> wrote:
>
> On mardi 7 mai 2019 16:42:41 CEST Simon Eves wrote:
> > That's what I have, even if that's not what I wrote.
> >
> > simon.eves at football:~/scratch/gdal3/gdal-3.0.0$ echo
> $LD_LIBRARY_PATH
> >
> /home/simon.eves/scratch/gdal3/install/lib:/usr/local/mapd-deps/lib64:/usr/l
> > ocal/mapd-deps/lib:/usr/local/cuda/lib64:
> > simon.eves at football:~/scratch/gdal3/gdal-3.0.0$
> ./configure --without-geos
> > --with-libkml=/usr/local/mapd-deps
> > --with-proj=/home/simon.eves/scratch/gdal3/install
> > ...
> > simon.eves at football:~/scratch/gdal3/gdal-3.0.0$ make
> > ...
> > (cd apps; make)
> > make[1]: Entering directory
> '/home/simon.eves/scratch/gdal3/gdal-3.0.0/apps'
> > /bin/bash
> /home/simon.eves/scratch/gdal3/gdal-3.0.0/libtool --mode=link
> > --silent g++ gdalinfo_bin.lo
> /home/simon.eves/scratch/gdal3/gdal-3.0.0/
> > libgdal.la <http://libgdal.la> -o gdalinfo
> >
> /home/simon.eves/scratch/gdal3/gdal-3.0.0/.libs/libgdal.so:
> undefined
> > reference to `proj_alter_name'
> > [etc.]
>
> Look at the output of
>
> ldd
> /home/simon.eves/scratch/gdal3/gdal-3.0.0/.libs/libgdal.so
> | grep proj
>
> It should normally point to the libproj.so.15 of
> /home/simon.eves/scratch/gdal3/install/lib
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
>
>
> --
> <http://www.omnisci.com/>
>
> Simon Eves
> Senior Graphics Engineer, Rendering Group
> OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA
>
>
>
> Email: simon.eves at omnisci.com
> <mailto:simon.eves at omnisci.com> | Cell: 415.902.1996
>
>
>
>
>
> --
> <http://www.omnisci.com/>
>
> Simon Eves
> Senior Graphics Engineer, Rendering Group
> OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA
>
>
>
> Email: simon.eves at omnisci.com <mailto:simon.eves at omnisci.com> |
> Cell: 415.902.1996
>
>
>
>
>
> --
> <http://www.omnisci.com/>
>
> Simon Eves
> Senior Graphics Engineer, Rendering Group
> OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA
>
>
>
> Email: simon.eves at omnisci.com <mailto:simon.eves at omnisci.com> | Cell:
> 415.902.1996
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190515/994052e1/attachment-0001.html>
More information about the gdal-dev
mailing list