Liblas@1.8.1-20200508: Undefined symbols for architecture x86_64: 264 "OGRSpatialReference::GetRoot()

[dershow]

I had liblas @1.8.1-20200508+proj7 installed. I just upgraded gdal from 3.1.3_2 to 3.2.0_0 that, and it built, but generated this:

--->  Cleaning gdal
--->  Scanning binaries for linking errors
--->  Found 34 broken files, matching files to ports
--->  Found 5 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 py27-gdal @3.1.0
 PDAL @2.1.0+postgresql12+python38
 OpenSceneGraph @3.6.5
 liblas @1.8.1-20200508+proj7
 grass7 @7.8.4+gui+postgresql12+proj6+python38
Continue? [Y/n]: Y

liblas then gave an error:

--->  Fetching distfiles for liblas
--->  Attempting to fetch libLAS-e12742f4152146d3a71f9b2de573257e91736c93.tar.gz from https://distfiles.macports.org/liblas
--->  Verifying checksums for liblas
--->  Extracting liblas
--->  Applying patches to liblas
--->  Configuring liblas
--->  Building liblas
Error: Failed to build liblas: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_liblas/liblas/main.log for details.
Error: rev-upgrade failed: Error rebuilding liblas
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

I've attached the logfile

[kencu (Ken)]

263	:info:build Undefined symbols for architecture x86_64:
264	:info:build   "OGRSpatialReference::GetRoot()", referenced from:
265	:info:build       SetCitationToSRS(gtiff*, char*, int, geokey_t, OGRSpatialReference*, int*) in gt_citation.cpp.o
266	:info:build       _GTIFGetOGISDefn in gt_wkt_srs.cpp.o
267	:info:build       _GTIFSetFromOGISDefn in gt_wkt_srs.cpp.o
268	:info:build ld: symbol(s) not found for architecture x86_64

[gwright83]

I am also seeing this error on Mojave (10.14.6) during a "port rebuild" phase after upgrading outdated ports.

The error I see is:

:info:build Undefined symbols for architecture x86_64:
:info:build   "OGRSpatialReference::importFromWkt(char const*)", referenced from:
:info:build       liblas::SpatialReference::GetWKT(liblas::SpatialReference::WKTModeFlag, bool) const in spatialreference.cpp.o
:info:build       liblas::SpatialReference::GetProj4() const in spatialreference.cpp.o
:info:build       _GTIFSetFromOGISDefn in gt_wkt_srs.cpp.o
:info:build   "OGRSpatialReference::GetRoot()", referenced from:
:info:build       SetCitationToSRS(gtiff*, char*, int, geokey_t, OGRSpatialReference*, int*) in gt_citation.cpp.o
:info:build       _GTIFGetOGISDefn in gt_wkt_srs.cpp.o
:info:build       _GTIFSetFromOGISDefn in gt_wkt_srs.cpp.o
:info:build   "OGRSpatialReference::GetLinearUnits(char const**) const", referenced from:
:info:build       _GTIFSetFromOGISDefn in gt_wkt_srs.cpp.o
:info:build   "OGRSpatialReference::GetAngularUnits(char const**) const", referenced from:
:info:build       SetGeogCSCitation(gtiff*, OGRSpatialReference*, char const*, int, short) in gt_citation.cpp.o
:info:build       _GTIFSetFromOGISDefn in gt_wkt_srs.cpp.o
:info:build   "OGRSpatialReference::GetPrimeMeridian(char const**) const", referenced from:
:info:build       SetGeogCSCitation(gtiff*, OGRSpatialReference*, char const*, int, short) in gt_citation.cpp.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [bin/MacPorts/liblas.2.4.0.dylib] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gis_liblas/liblas/work/build'
:info:build make[1]: *** [src/CMakeFiles/las.dir/all] Error 2

If it helps I can send the whole log.

[Veence (Vincent)]

Darn. Let me have a look

[dershow]

Any luck with this? I have a need for liblas and the installed port no longer works due to the link error and I can't get it to rebuild. So, any suggestions are appreciated.

[gwright83]

Hi Veence, I found at least one of the problems and fixed it.

If you ever installed a binary of qgis from qgis.org, you may have a stale gdal framework in /Library/Frameworks/GDAL.framework. When building liblas it can be found first, rather than macports gdal. Some old versions of gdal are missing the symbols needed by liblas.

The solution is to delete /Library/Frameworks/GDAL.framework, run port clean liblas, rebuild and all is right with the world.

(The OGRSpatialReference symbols are defined in libgdal; the invocation of the compiler just before the error showed the wrong libgdal being linked in. Yet another reason to read the log file. :-) )

[dershow]

I do have that gdal framework. So, I tried what you suggested, but it's still giving me errors. I uninstalled libels then did this:

 % sudo port install liblas
--->  Computing dependencies for liblas
--->  Fetching archive for liblas
--->  Attempting to fetch liblas-1.8.1-20200508_1+proj7.darwin_19.x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/liblas
--->  Attempting to fetch liblas-1.8.1-20200508_1+proj7.darwin_19.x86_64.tbz2.rmd160 from https://ywg.ca.packages.macports.org/mirror/macports/packages/liblas
--->  Installing liblas @1.8.1-20200508_1+proj7
--->  Activating liblas @1.8.1-20200508_1+proj7
--->  Cleaning liblas
--->  Scanning binaries for linking errors
--->  Found 332 broken files, matching files to ports
--->  Found 4 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 liblas @1.8.1-20200508+proj7
 vtk @8.2.0+qt5
 libpcl @1.9.1+openmp
 grass7 @7.8.4+gui+postgresql12+proj6+python38
Continue? [Y/n]: Y
--->  Computing dependencies for liblas
--->  Cleaning liblas
--->  Computing dependencies for vtk
--->  Fetching archive for vtk
--->  Attempting to fetch vtk-8.2.0_3+qt5.darwin_19.x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/vtk
--->  Attempting to fetch vtk-8.2.0_3+qt5.darwin_19.x86_64.tbz2 from https://mse.uk.packages.macports.org/vtk
--->  Attempting to fetch vtk-8.2.0_3+qt5.darwin_19.x86_64.tbz2 from https://lil.fr.packages.macports.org/vtk
--->  Building vtk
Error: Failed to build vtk: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_vtk/vtk/main.log for details.
Error: rev-upgrade failed: Error rebuilding vtk
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

So, it seems to install, but then shows up a broken port.

[gwright83]

dershow, it looks as if you are having a failure building vtk, which does not have a dependency on liblas. At first glance, this seems to be unrelated to the missing symbol problem from liblas. Have you looked at the vtk build log?

[kencu (Ken)]

vtk has a PR for a fix ​https://github.com/macports/macports-ports/pull/9502

[dershow]

Yes. There's a ticket for vtk: ​https://trac.macports.org/ticket/61840

But, I tried to just install liblas, and it does seem to install but then finds that it is broken. Finally, while trying to repair liblas and vtk I get the vtk error. If liblas is working OK, it should not be finding a problem with it as a broken port. So, if I have both vtk and liblas are broken and I reinstall a fixed liblas, why should vtk matter, and why should liblas still show as a broken port? Or, is there something that I'm missing from the install process?

[gwright83]

Hi dershow, I believe that this is what is happening: the port system has detected that grass7 needs to be rebuilt and this requires rebuilding liblas. It also detects an (unrelated) issue requiring vtk to be rebuilt. liblas is successfully rebuilt, but the port system doesn't necessarily rebuild ports in dependency order and it tries rebuilding vtk before grass7, which fails for other reasons. This failure brings the rebuilding to a halt.

You could try to uninstall and clean grass7, then rebuild and reinstall it. Note that the variants have changed -- grass7 should now use the +proj7 variant. (This change in default variant for grass7 and liblas is probably what is triggering these rebuilds.)

In short: liblas is still showing as "broken" because grass7 needs to be rebuilt. grass7 needs to rebuild liblas so it can ensure a version with compatible variants. vtk fails to rebuild for unrelated reasons, which wedges the whole process. Note that the port system doesn't store state for partially completed rebuilds. It's all or nothing, and if anything goes wrong, it has to start over again from scratch.

[dershow]

That allowed liblas to build.

[dershow]

I see that liblas got updated from 1.8.1-20200508_1 to 1.8.1-20200508_2 so I tried to build that and it failed with the same problem.

[Veence (Vincent)]

I have updated the code to the latest GIT commit, hope that helps

[cooljeanius (Eric Gallager)]

Replying to Veence:

I have updated the code to the latest GIT commit, hope that helps

Unfortunately now I get this error:

1 warning generated.
make[2]: *** No rule to make target `/lib.dylib', needed by `bin/MacPorts/liblas.2.4.0.dylib'.  Stop.
make[2]: *** Waiting for unfinished jobs....
[ 39%] Building CXX object src/CMakeFiles/las.dir/tifvsi.cpp.o

[Veence (Vincent)]

Do you still have that problem?

[cooljeanius (Eric Gallager)]

Replying to Veence:

Do you still have that problem?

This one?

Replying to cooljeanius:

Unfortunately now I get this error:

1 warning generated.
make[2]: *** No rule to make target `/lib.dylib', needed by `bin/MacPorts/liblas.2.4.0.dylib'.  Stop.
make[2]: *** Waiting for unfinished jobs....
[ 39%] Building CXX object src/CMakeFiles/las.dir/tifvsi.cpp.o

Yes, I do still get that error.

[Veence (Vincent)]

Could you post the entire log? Thanks

[cooljeanius (Eric Gallager)]

main.log for liblas

[cooljeanius (Eric Gallager)]

main.log for liblas when attempting to build with trace mode

[cooljeanius (Eric Gallager)]

Replying to Veence:

Could you post the entire log? Thanks

Sure, I did one from a normal build, and also one with trace mode

[Veence (Vincent)]

The problem is obviously the wrong path the configure script thinks GDAL is located in. Do you have ${prefix}/gdal-config installed? If yes, what is the output of gdal-config --libs and gdal-config --cflags? (I hate spellcheckers)

[cooljeanius (Eric Gallager)]

$ which -a gdal-config | uniq
/opt/local/bin/gdal-config
$ gdal-config --libs
-L/opt/local/lib -lgdal
$ gdal-config --cflags
-I/opt/local/include
$

[Veence (Vincent)]

This is weird. Can you setenv GDAL_HOME to /opt/local or whatever you use, then do port -v configure liblas and post the log? Thanks!

[Veence (Vincent)]

LibLAS compiles on the buildbot. It should probably work for you now.

[cooljeanius (Eric Gallager)]

Replying to Veence:

LibLAS compiles on the buildbot. It should probably work for you now.

Yeah I can fetch the version from the buildbot, but trying to build it manually with the +debug variant still fails, though... but anyways, whatever; I should probably open a separate ticket instead of continuing to use this bug...