Hi everyone, for loading las file and also processing las file data without converting to pod file, i add third-party library liblas to realize this function, but while add the following code lines:
... //read las file std::string filename = "F:/Data/2019-9-08-18.las"; //open file std::ifstream ifs; ifs.open (filename, std::ios::in | std::ios::binary); if (!ifs) return false; liblas::ReaderFactory f; liblas::Reader reader = f.CreateWithStream (ifs); ...
I meet some error: OS could not load G:\Microstation\MSCE-coding\applications\cdd.dll, error 127.MDL Loader: Unable to load library (DLL or MDL shared library) cdd
And i checked that the error occurs if i add "liblas::Reader reader = f.CreateWithStream (ifs);" and i also checked that the all dependency dlls are existed.
So i wander if anybody have meet the same problem?
liu li said:OS could not load G:\Microstation\MSCE-coding\applications\cdd.dll, error 127
Is the path G:\Microstation\MSCE-coding\applications included in MicroStation configuration variable MS_MDLAPPS?
G:\Microstation\MSCE-coding\applications
MS_MDLAPPS
Assuming your answer is 'yes', then that means your app cdd.dll depends on another DLL that Windows can't find. Most of us are unfamiliar with libLAS. What DLLs does that library provide? Where are they located? Try adding the libLAS library location to the Windows PATH variable.
cdd.dll
PATH
Is libLAS compatible with a 64-bit application such as MicroStation CONNECT? Does it require you to link to some 64-bit objects or libraries? Are its DLLs 64-bit or does it require you to download some additional 64-bit files?
The libLAS web site tells us, by the way, that libLAS is superseded by PDAL.
Regards, Jon Summers LA Solutions
Jon Summers said:Is the path G:\Microstation\MSCE-coding\applications included in MicroStation configuration variable MS_MDLAPPS?
The answer is yes
Jon Summers said:Try adding the libLAS library location to the Windows PATH variable.
And i have already done with that.
Jon Summers said:Does it require you to link to some 64-bit objects or libraries? Are its DLLs 64-bit or does it require you to download some additional 64-bit files?
I compile the liblas under vs2017, and a 64-bit project test is implemented to verify that. liblas required geotiff and libtiff which are all build myself under vs 2017.
I notice that in MSCE there is already a libtiff.dll and will this dll goes wrong?
liu li said:I notice that in MSCE there is already a libtiff.dll and will this dll goes wrong?
It's not in MSCE I think because the location you captured is 32bit DGNIndexer, that is not expected to be involved in CE runtime.
Regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Oh，my mistake...
Another idea: You can try is to use Process Explorer that allows to display loaded dll and to check what dlls are loaded before your application is loaded and after.
HTH Jan
Wow， thank you i will try Process Explorer as soon as possible
liu li said:liblas.dll is loaded with libgeotiff.dll(1.4.2) and libtiff.dll(4.0.10) and gdal.dll(2.3.2),and gdal i forgett to write in this post but added as well as libgeotiff ,libtiff.
GDAL itself depends on many other dll libraries, the dependency tree is quite complex in this case. At least what is see in Dependency Walker for gdal204.dll installed as part of osgeo4w64.
liu li said:liblas.dll is loaded with libgeotiff.dll(1.4.2) and libtiff.dll(4.0.10) and gdal.dll(2.3.2),and gdal
I notice this comment in libLAS about GDAL.
GDAL surreptitiously embeds a copy of libgeotiff in its library build but there is no way for you to know this. In addition to embedding libgeotiff, it also strips away the library symbols that libLAS needs, meaning that libLAS can’t simply link against GDAL. If you are building both of these libraries yourself, make sure you build GDAL using the “External libgeotiff” option, which will prevent the insanity that can ensue on some platforms. OSGeo4W users, including those using that platform to link and build libLAS themselves, do not need to worry about this issue.
Hi liu li,
Jan, Jon and Volker have provided a lot of good troubleshooting suggestions that I too find valuable. Here are a couple concise points to try to get to the bottom of these types of issues real quick.
For #1 - Can you open the MicroStation CONNECT Edition Developer Shell (run as admin), type and provide the output of the DLL in question with this quick and dirty test?
(for /f "tokens=*" %a in ('dir /s /b *.dll') do (echo Dir: %~dpa >> %temp%\dllinfo.txt & echo File: %~nxa >> %temp%\dllinfo.txt & dumpbin /headers %~sa | findstr "linker machine 2GB entry pdb Certificates" >> %temp%\dllinfo.txt)) && (start explorer.exe /e, /select,%temp%\dllinfo.txt)
For #2 - Dependency Walker (depends.exe 64-bit) and/or Process Monitor (procmon) are great tools to verify and gain insights into otherwise unknown reasons why: files can't be found, permissions silently denied, etc. Technically traditional debuggers (windbg, cdb, and Visual Studio) typically permit you to turn on/enable additional debugging options to provide additional information about module loading (loader snaps), first chance exceptions (sxe av), etc.; you can likewise use if comfortable using.
For #3 - A test case ensures everyone has the same chance to quickly, easily and precisely troubleshoot and make recommendations on the exact code in question. If submitting a test case you can attach a zip file to your post/response that contains your compiled binary dlls and dependencies to help with validation.
HTH,Bob
Hi Jon，recently i recompiled gdal and liblas using External libgeotiff option,but the result is just like always that occurs error 126 or 127.
And i have tried all the way you said before,but it seems like useless,and i have install msce update11 and its correspond sdk require vs 2015, the different environments meet the same error. So..
Finally i think there may be a bug between msce and liblas :(
Hi,
liu li said:Finally i think there may be a bug between msce and liblas :(
even when I am not C++ expert, I do not think such incompatibility exist. When there is source code available and it's possible to compile it using proper C compiler (Visual Studio 2017 in this case) with correct configuration, it has to be fine for MicroStation and the problem is probably somewhere else.
Because I do not know liblas source code, it's hard to guess what to test more, but I think using tools mentioned in the discussion (namely Dependency Walker and Process Monitor) plus check whether classes are exported from dll in the right way
With regards,
Hi Jan, i just using LASlib to load las files and this error vanishs, and i will keep digging this problem and thank you all.
liu li said:i just using LASlib to load las files and this error vanishes
If that solved your problem, please mark your original question as 'This Answered my Question'.