incompatibility between liblas and MSCE

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? 

  • Hi,

    incompatibility between liblas and MSCE

    Well, no information what you provided shows there is incompatibility between the library and MicroStation (even when it can exist). It seems to be about wrongly compiled and configured your project.

    i add third-party library liblas to realize this function

    you have not provided too much information and frankly, what you say is a bit fuzzy and chaotic. Please provide more detail and clearer description of the situation.

    • Where you download the liblas library from? Do you expect everybody know this library and how it's structured?
    • Do you use precompiled dll / lib files or you compile your own version of liblas When the first option is true, do you ensure you use right dll file(s), compiled also with VS2017 (because what I see in some doc on web, only up to VS2010 was mentioned).
    • Do you use bmake or Visual Studio to compile your project?
    • How do you add the liblas file(s) to your project? Manually or as NuGet package?
    • How workspace is configured (e.g. MS_MDL variable)?
    I meet some error: OS could not load G:\Microstation\MSCE-coding\applications\cdd.dll, error 127.

    What is cdd.dll? Where it comes from? If it's the project you compiled, the whole problem is probably not about liblas, but how your project is built. Dll error 127 is usually shown when function (e.g. entry point) cannot be found in dll file. Is .ma loader used in your application and how entry point (MdlMain) is implemented?

    So i wander if anybody have meet the same problem? 

    No.

    I assume you should do some tests to isolate situation:

    • Place your project to mdlapps folder and test it again.
    • (If possible) Change your project to be exe to test whether your code can access liblas without influence of MicroStation.
    • Create simple "Hello world" MicroStation application to ensure your project configuration and the way how it's built is correct.

    With regards,

      Jan

  • thank you Jan.

    Where you download the liblas library from?

    I just compile liblas myself with it's dependent(geotiff\libtiff).

    Do you expect everybody know this library and how it's structured?

    And this is a open source library that i didn't edit the source code.

    Do you use precompiled dll / lib files or you compile your own version of liblas When the first option is true, do you ensure you use right dll file(s), compiled also with VS2017 (because what I see in some doc on web, only up to VS2010 was mentioned).

    I have already test my dll using, because i want to fusion my existed algorithms to msce, which means that the precompiled dll works well in my pc under vs2017.

    Do you use bmake or Visual Studio to compile your project?

    bmake. and it works well without error, and just could not be loaded in MSCE.

    How do you add the liblas file(s) to your project? Manually or as NuGet package?

    manully nad just like using opencv or something else.

    How workspace is configured (e.g. MS_MDL variable)?

    MS_MDL is all set correctlly.

    What is cdd.dll? Where it comes from? If it's the project you compiled, the whole problem is probably not about liblas, but how your project is built. Dll error 127 is usually shown when function (e.g. entry point) cannot be found in dll file. Is .ma loader used in your application and how entry point (MdlMain) is implemented

    cdd.dll is my project compiled. And while i am not using the code line "liblas::Reader reader = f.CreateWithStream (ifs);" in my mdl project. the whole dll could be loaded correctlly. And i think that means my build process is correct.

    • Place your project to mdlapps folder and test it again.
    • (If possible) Change your project to be exe to test whether your code can access liblas without influence of MicroStation.
    • Create simple "Hello world" MicroStation application to ensure your project configuration and the way how it's built is corre

    Besides, i have tried all your suggestions.

    For 1. place into mdlapps is not work.

    For 2. my exe could run and get what i wish.

    For3. the whole build way is corrected that i have develop many mdl projects and all work well

  • And i think that means my build process is correct

    I guess you are right ;-)

    There was similar discussion, but I think it's another case.

    I would try tools like dllexp and Dependency Walker to check how dll are linked together, but the only idea I have right now.

    Maybe , or will be able to provide some insights what to check or try.

    Regards,

      Jan

  • I would try tools like dllexp and Dependency Walker to check how dll are linked together

    I have tried these tools and none dll seem to be ignored

    Anyway thank you very much, Jan. I will continue to search...

  • Maybe , or will be able to provide some insights what to check or try.

    Quite a pressure from you, Jan :-)
    Ok, I think you have worked through the most important points. What comes to my mind: "wrong dll found" This is a nasty problem, which we also stumble over from time to time.

    MicroStation uses its own path search system, so it can happen that another instance of the DLL is loaded than the one you think.

    This helps us then:

    1. search and delete all DLLs in all pathes
    2. checking the variables:

    • MS_MDL
      MS_LIBRARY_PATH
    • MS_ADDINPATH
      MS_ADDIN_DEPENDENCYPATH
    • MS_RSRCPATH

    Mit freundlichen Grüßen / Best regards
    Volker Hüfner

    |  AB_DATE Engineering  Software   |  ab-date.de  |

  • MS_MDLAPPS, PATH and DLLs

    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?

    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.

    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?

    libLAS is Obsolete

    The libLAS web site tells us, by the way, that libLAS is superseded by PDAL.

     
    Regards, Jon Summers
    LA Solutions

  • Is the path G:\Microstation\MSCE-coding\applications included in MicroStation configuration variable MS_MDLAPPS?

    The answer is yes

    Try adding the libLAS library location to the Windows PATH variable.

    And i have already done with that.

    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 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.

    Which should be fine and ideal situation in my opinion.

    An idea: Can be in "dll search path" (which I am not sure how it looks like for dll loaded into MicroStation) the same library (dll dependency), but old version, so MicroStation loaded this (wrong) one and does not find expected exported function?

    I am not very good in rules and tricks how native dll files are located and loaded :-(

    Regards,

      Jan