Opened 5 years ago

Closed 20 months ago

#550 closed defect (outdated)

OSGeo4W-64 bit: lasinfo crashes with an entry point not found

Reported by: hellik Owned by: osgeo4w-dev@…
Priority: critical Component: Package
Version: Keywords: las
Cc:

Description

lasinfo --help in the OSGeo4W-64 bit-shell crashes with:

procedure entry point "?get_error@LASzipper@@QEBAPEBDXZ" couldn't find in the DLL "C:\OSGEO$~1\bin\liblas.dll".

starting a dependency walker session in the OSGeo4W-64 bit-shell shows following issues:

Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

having a closer look into the dependency walker results, it seems the isse seems to be within laszip.dll

??0LASunzipper@@QEAA@XZ
??0LASzip@@QEAA@XZ
??0LASzipper@@QEAA@XZ
??1LASunzipper@@QEAA@XZ
??1LASzip@@QEAA@XZ
??1LASzipper@@QEAA@XZ
?close@LASunzipper@@QEAA_NXZ
?get_error@LASunzipper@@QEBAPEBDXZ
?get_error@LASzip@@QEBAPEBDXZ
?get_error@LASzipper@@QEBAPEBDXZ
?get_name@LASitem@@QEBAPEBDXZ
?open@LASunzipper@@QEAA_NAEAV?$basic_istream@DU?$char_traits@D@std@@@std@@PEBVLASzip@@@Z
?open@LASzipper@@QEAA_NAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@PEBVLASzip@@@Z
?pack@LASzip@@QEAA_NAEAPEAEAEAH@Z
?read@LASunzipper@@QEAA_NPEBQEAE@Z
?seek@LASunzipper@@QEAA_NI@Z
?setup@LASzip@@QEAA_NEGG@Z
?unpack@LASzip@@QEAA_NPEBEH@Z
?write@LASzipper@@QEAA_NPEBQEBE@Z

attachted the dependency walker profiling output.

Attachments (1)

dependency_walker.zip (3.1 KB ) - added by hellik 5 years ago.
dependency walker profiling results

Download all attachments as: .zip

Change History (15)

by hellik, 5 years ago

Attachment: dependency_walker.zip added

dependency walker profiling results

in reply to:  description comment:1 by hellik, 5 years ago

Replying to hellik:

having a closer look into the dependency walker results, it seems the isse seems to be within laszip.dll

looking at the OSGeo4W download, there was a laszip update 2 months ago:

[ ]	laszip-2.2.0-1.tar.bz2	08-Jun-2014 13:39 	89K	 
[ ]	laszip-2.2.0-2.tar.bz2	05-Aug-2014 11:17 	58K	 
[ ]	laszip-2.2.0-3.tar.bz2	05-Aug-2014 11:21 	58K	 
[ ]	laszip-3.1.1-1.tar.bz2	12-Oct-2017 07:35 	109K	 
[ ]	laszip-3.1.1-2.tar.bz2	12-Oct-2017 08:09 	109K	 
[ ]	laszip-3.1.1-3.tar.bz2	12-Oct-2017 08:13 	110K	 

comment:2 by hobu, 5 years ago

This was caused by me. I updated LASzip, but libLAS hasn't been updated to use the new LASzip API. You'll have to revert to the LASzip 2.2.0 version to use libLAS

in reply to:  2 comment:3 by hellik, 5 years ago

Replying to hobu:

This was caused by me. I updated LASzip, but libLAS hasn't been updated to use the new LASzip API. You'll have to revert to the LASzip 2.2.0 version to use libLAS

it's possible to downgrade manually, but osgeo4w will download latest version.

e.g. GRASS GIS uses OSGeo4W as build environment. build environment can be downgraded.

but everytime a user updates his OSGeo4W stack, the GRASS lidar modules and eventually QGIS (e.g GRASS lidar commands in procesing) will be likely broken on runtime.

no chance to fix the broken liblas/laszip stack?

comment:4 by hobu, 5 years ago

no chance to fix the broken liblas/laszip stack?

There is a significant amount of software development to catch it up to the latest LASzip release. The LASzip API that libLAS used is no longer supported, and the new LASzip API is very different from the one that libLAS (and previously PDAL) used.

It would be better long term to get GRASS using PDAL. There was some effort on that topic, but I think it has stalled.

in reply to:  4 comment:5 by hellik, 5 years ago

Replying to hobu:

no chance to fix the broken liblas/laszip stack?

There is a significant amount of software development to catch it up to the latest LASzip release. The LASzip API that libLAS used is no longer supported, and the new LASzip API is very different from the one that libLAS (and previously PDAL) used.

It would be better long term to get GRASS using PDAL. There was some effort on that topic, but I think it has stalled.

thanks for the information.

the was a GSoC 2017 project to integrate PDAL into GRASS. will cite your comment in the related GRASS ticket.

in reply to:  2 ; comment:6 by hellik, 5 years ago

Replying to hobu:

You'll have to revert to the LASzip 2.2.0 version to use libLAS

tried with the OSGEo4W setup here, can't revert back to the earlier version.

in reply to:  6 ; comment:7 by jef, 5 years ago

Replying to hellik:

tried with the OSGEo4W setup here, can't revert back to the earlier version.

Now you can.

in reply to:  7 ; comment:8 by hellik, 5 years ago

Replying to jef:

Replying to hellik:

tried with the OSGEo4W setup here, can't revert back to the earlier version.

Now you can.

http://download.osgeo.org/osgeo4w/x86_64/release/laszip/setup.hint

sdesc: "The LASzip compression library"
ldesc: "LASzip is a compression library for ASPRS LAS LiDAR data"
maintainer: hobu
category: Libs Commandline_Utilities
requires: shell msvcrt2015
prev: 2.2.0-3
curr: 3.1.1-3

I've seen that you changed the setup.hint.

IMHO it doesn't solve the fundamental issue regarding compiling/runtime in all the user's OSGeo4W stack.

in reply to:  8 comment:9 by jef, 5 years ago

Replying to hellik:

I've seen that you changed the setup.hint.

IMHO it doesn't solve the fundamental issue regarding compiling/runtime in all the user's OSGeo4W stack.

I agree.

comment:10 by martinl, 5 years ago

I took liberty to create the new laszip2 package (1) and updated liblas setup.hint for new laszip2 dependency. I did these changes only for x64_64. So we can finally re-enable liblas support in GRASS.

It would be better if we could force version dependency in liblas setup.hint file. To my knowledge it's not possible, right?

Let me know if laszip2 package as workaround is OK for you. Then I would ask @hobu to remove laszip v2 packages from laszip directory (I don't have rights to do it).

(1) http://download.osgeo.org/osgeo4w/x86_64/release/laszip2/

in reply to:  10 comment:11 by hellik, 5 years ago

Replying to martinl:

I took liberty to create the new laszip2 package (1) and updated liblas setup.hint for new laszip2 dependency.

thanks for the work around

I did these changes only for x64_64. So we can finally re-enable liblas support in GRASS.

yes

It would be better if we could force version dependency in liblas setup.hint file. To my knowledge it's not possible, right?

Let me know if laszip2 package as workaround is OK for you. Then I would ask @hobu to remove laszip v2 packages from laszip directory (I don't have rights to do it).

(1) http://download.osgeo.org/osgeo4w/x86_64/release/laszip2/

comment:12 by hobu, 5 years ago

I took liberty to create the new laszip2 package (1) and updated liblas setup.hint for new laszip2 dependency. I did these changes only for x64_64. So we can finally re-enable liblas support in GRASS.

Were there any patches to LASzip's CMakeLists.txt to support this? Please upstream them and I'll merge.

Let me know if laszip2 package as workaround is OK for you. Then I would ask @hobu to remove laszip v2 packages from laszip directory (I don't have rights to do it).

Done. I have hidden them so they could be restored if necessary, however.

Thanks for the work on this topic. Sorry for making a mess.

comment:13 by jef, 5 years ago

See also #561

comment:14 by jef, 20 months ago

Resolution: outdated
Status: newclosed
Note: See TracTickets for help on using tickets.