[gdal-dev] Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Simon Eves
I have never had trouble with this before, most recently Proj 5.2 and GDAL 2.4.1, but the same build workflow doesn't work with the newest stuff...

I have a complete build of Proj 6.0.0 from a default ./configure (although to a local --prefix)

I then do our standard ./configure of GDAL 3.0.0RC2...

--without-geos --with-kml=<known good KML install> --with-proj=<local Proj install>

The build works all the way up to and including lib-target, and I see the .a and .so and related symlinks in the .libs subdir.

It's apps-target that falls over. Every app build fails when linking against libgdal.so with "undefined reference" against a bunch (perhaps all) of "proj_<blah>" symbols.

config.log and make.log attached.

I am undoubtedly doing something stupid, but I can't see what! :(

This is on Ubuntu 18.04 with GCC 7.4.0

I saw http://trac.osgeo.org/gdal/wiki/BuildingOnUnixGDAL25dev but I don't think it applies any more.

The <local Proj install> path is in $LD_LIBRARY_PATH

--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

config.log.gz (29K) Download Attachment
make.log.gz (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Even Rouault-2
> The <local Proj install> path is in $LD_LIBRARY_PATH

For $LD_LIBRARY_PATH, this should be <local Proj install>/lib


--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Simon Eves
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/local/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.]

On Tue, May 7, 2019 at 2:21 PM Even Rouault <[hidden email]> wrote:
> The <local Proj install> path is in $LD_LIBRARY_PATH

For $LD_LIBRARY_PATH, this should be <local Proj install>/lib


--
Spatialys - Geospatial professional services
http://www.spatialys.com


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Peter Schmitt
> 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'

I had a similar problems linking recently. I was building GDAL against a version of libcurl I built myself & got "undefined reference" to a few curl symbols. I was able to get past the link errors by running "configure --without-libtool ....". Later, I revisited the problem and found a potentially better solution: I made sure to uninstall my OS libcurl, build my own curl, then built GDAL. If the OS libcurl made it back onto the system after install, I needed to set LD_LIBRARY_PATH=/path/to/my/libcurl/lib:$LD_LIBRARY_PATH to avoid runtime errors.

Hope that helps!
Pete

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Even Rouault-2
In reply to this post by Simon Eves
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
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Simon Eves
No, it shows /usr/lib/x86_64-linux-gnu/libproj.sso.12 (the system-installed Proj 5.2.0)

I did not expect the system libs to come into play at all if I used --with-proj for the GDAL configure, and $LD_LIBRARY_PATH had the Proj 6 DSO directory first.

I'll try it all again from scratch.

Simon

On Wed, May 8, 2019 at 12:41 AM Even Rouault <[hidden email]> 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


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Simon Eves
In reply to this post by Even Rouault-2
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 <[hidden email]> 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


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Simon Eves
$ 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 <[hidden email]> 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 <[hidden email]> 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


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996




--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Simon Eves
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996




--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996




--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

James Klassen-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>
> [hidden email] 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:
> [hidden email] ./configure --without-geos
> --with-libkml=/usr/local/mapd-deps
> --with-proj=/home/simon.eves/scratch/gdal3/install
> ...
> [hidden email] 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


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell:  415.902.1996




--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell:  415.902.1996




--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell:  415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

Simon Eves
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
>
> [hidden email] 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:
> [hidden email] ./configure --without-geos
> --with-libkml=/usr/local/mapd-deps
> --with-proj=/home/simon.eves/scratch/gdal3/install
> ...
> [hidden email] 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


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell:  415.902.1996




--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell:  415.902.1996




--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell:  415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: [hidden email] | Cell: 415.902.1996



_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev