Confirming that setting LDFLAGS as above just for the GDAL
configure-and-build resolves the problem.
Our build guy thinks it's a little hacky, so I'd like to ask again what
changed that made this necessary.
This was all on Ubuntu 18.04, by the way. I need to try it on our other
supported Linux flavors too...
On Wed, May 15, 2019 at 12:52 PM Jim Klassen <klassen...@gmail.com> wrote:
> 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.e...@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
>> 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.e...@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.roua...@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@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@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@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 -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.e...@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.e...@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.e...@omnisci.com | Cell: 415.902.1996
>
>
> _______________________________________________
> gdal-dev mailing
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA
Email: simon.e...@omnisci.com | Cell: 415.902.1996
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
