Hi all -
I've been banging away at converting code over from v8i MDL code to C++ native DLL and have (most) of it compiling without error. I've decided I need to get a portion of the code working to make sure I'm on the right track. So before I start rewriting modules to write text and add reference files, I'm trying to link modules together.
I was getting a bunch of errors with finding the OBJ files and figured that out, but now I'm getting the error above and don't understand why. Rather, in a general sense I understand that somewhere the BMAKE process is saying, "Make this for an x86 machine" and the link libraries are all compiled for an x64 machine, which is the cause of the error.
What I don't know how to do is find where to fix it.
When I compile, I'm using bmake <program> -v <enter>, which gave me one set of results, where the linker would choke on several of the OBJ files, not being able to find them to use functions in them. In the old make file, there's a command line that I figured I'd try to see if it gave different results:
bmake -a +dMDLDEBUG -dNO_COMPILERS_MKI=1 -dBUILD_USING_NoToolset liqdist.mke
This gave nicely formatted results, but materially changed what I get using the original bmake call, and now I'm getting the error message in the title. I have tried restarting the development environment, now I just get the new error.
So. Many. Questions. I know it's bad form to ask more than one, so I'm only going to be a little naughty.
I did see Jan Slegr's response to an earlier post and, while I followed most of it, what I got out was that it was for a different version of CE that needed VS2013 for C++ and not VS2017 for the version I'm running AND it's a configuration issue. I understand that, but I just don't know where to look for it.
If this were C#, I'd look at the target assembly and change it there, but I don't think BMAKE works with the build properties inside VS (and I tried changing that in several different places, producing the same effect).
Any suggestions (or magic bullets)?
Hi Gary,
Gary Shay said:Any suggestions (or magic bullets)?
My suggestion is to don not writing about thought and to start sharing concrete data. Unfortunately, your question is like to complain in long speech your car is broken somehow, because some light is red, describing what you think about this issue, possibilities and context, but you do tell nothing about car manufacturer, the car type, model and its configuration.
Please:
Gary Shay said:but I just don't know where to look for it.
The error message is very clear: The problem is produced by linker, so you should search in make file and/or in log file, for what modules this error is produced and how (using what arguments) they are compiled.
MicroStation SDK shell is configured to do things right, so when there is the problem with x86 files, they are external or make file is configured to compile x86 objects and not standard x64 variant.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Jan -
Thanks for the response. I expected you to ask for more information, and I will share everything, but I wasn't sure what would be needed. Trying to be respectful and hopeful that it's a dumb mistake.
I've got meetings today until mid-morning USEast, I will post that as soon as I can today. I want to try modifying a newer make file first to see if this is due to an old disordered MKE or if there's something else I missed updating the old file. Either way I'll post both the old and new.
Gary
Gary Shay said: but I wasn't sure what would be needed.
When development issue is discussed, source code and expected vs actual results are needed nearly always.
In the discussed case, source code is mke file (plus custome mki when used) and verbose make process log is the result. It should be enough to analyze problem in detail, without having the complete project available.
Gary Shay said:I want to try modifying a newer make file first to see if this is due to an old disordered MKE
It can be, but in such case the old mke is probably written incorrectly. It can happen, I saw several "over defined" make files, ignoring that SDK shell is set to do things in the right way by default. Both compiler and linker are called using a huge amount of parameters, so it is easy to set some from them incorrectly.
Or can it be (I do not know the project structure in detail) that there are V8i and CE versions side by side, and something is "cross linked", because of hardcoded path (or incorrectly set PATH variable)?
Regards,
In this case, the good news is that there's only one version of SDK/Microstation that's ever been installed on this development machine. CE was installed and then patched to 10.15.00.74. Visual Studio 2019 was originally installed, but when I figured out that wouldn't work for C++ development, I backed that off to a version that would work with the CE update level.
That doesn't mean the path or other environment variables are set correctly, although all of the example code compiles first time and correctly.
I'm creating the new MKE now, will update shortly.
G
Gary Shay said:That doesn't mean the path or other environment variables are set correctly
Open a Windows command prompt, type set > %TEMP%\env_vars.txt then examine env_vars.txt.
set > %TEMP%\env_vars.txt
env_vars.txt
Look for relevant definitions: e.g. MS or MSMDE.
MS
MSMDE
If you do that in the CONNECT SDK shell, you'll see the definitions of all the variables that Robert Hook and his team have created to make our lives easier.
Gary Shay said:CE was installed and then patched to 10.15.00.74. Visual Studio 2019 was originally installe
The versions of Viz Studio can be installed side-by-side, I believe. MicroStation CONNECT Update 17 uses Viz Studio 2019.
Regards, Jon Summers LA Solutions
Hi Gary Shay,
MicroStation CONNECT Update SDK 17.0 is available, the most current, recommended and preferred release to try to work with (whenever possible).
The Individual MicroStation SDK Announcements are listed on the MicroStation CONNECT Releases page and provide links and info wrt:
Download Link, Announcement, Resolved Issues, Version, Date, Size, Visual Studio Version, MSVCRT and .NET version requirements.
Each individual Announcement provides a Requirements section and essentially equate to:
Each time the MicroStation Developer Shell is started it provides a brief listing of "essential variables" like the section below. In case you have other build environments and need to know what critical shell variables need to be present (at minimum) it is available:
[SDK Environment] BMAKE_OPT=-IC:\PROGRA~1\Bentley\MICROS~2\mki\ MS=C:\PROGRA~1\Bentley\MICROS~1\MICROS~1\ MSMDE=C:\PROGRA~1\Bentley\MICROS~2\ MSMDE_OUTPUT=C:\Users\ROBERT~1.HOO\AppData\Local\Temp\Bentley\MICROS~1\ DEFAULT_TARGET_PROCESSOR_ARCHITECTURE=x64 DLM_NO_SIGN=1
Similar to Jon's advice to provide a copy of your environment variables for troubleshooting, the MicroStation CONNECT SDK provides a "build.bat" (with optional "verbose" argument) that you can use if your ProjectFolderName is the same as the MakeFileName convention that we typically use.
So, if you had trouble building the MyApp example you could then "send us your build output" by doing this:
When finished it will ask you if you want to view the log file generated, press Y to then examine the log file generated. If you use "verbose" as an argument to build your OS/Shell environment variables are listed first in the log file, followed by the most verbose output possible when using bmake on your project files. That sequential build output should provide enough information to know what variable and value is set in what file and line number to help you quickly and confidently find and resolve problems.
If by chance you are using one of the dozen+ Bentley vertical product SDKs that "consume" the MicroStation/PowerPlatform (MSPP) SDK and does not synchronize and provide a "build.bat verbose" option; you could accomplish the same build output using a command like below - substituting your own application make file name:
set > %temp%\build.txt & doskey /macros >> %temp%\build.txt & bmake +avilC YourAppName.mke >> %temp%\build.txt
HTH,Bob
Sorry for the delay in replying. Had a production issue that I was pulled into.
Ok - the Developer Shell startup script does not give me the same [SDK Environment] parts you show. It does display the following by default:
[SDK Environment] MS=C:\PROGRA~1\Bentley\MICROS~1\MICROS~1\ MSMDE=C:\PROGRA~1\Bentley\MICROS~2\ MSMDE_OUTPUT=C:\Users\SHAYGE\AppData\Local\Temp\Bentley\MicroStationSDK\ Path=C:\PROGRA~2\MIB055~1\2017\PROFES~1\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Common7\IDE\VC\VCPackages;C:\Program Files (x86)\Microsoft SDKs\TypeScript\3.1;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\PROGRA~2\MIB055~1\2017\PROFES~1\MSBuild\15.0\bin\Roslyn;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Team Tools\Performance Tools;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\;C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86;C:\Program Files (x86)\Windows Kits\10\bin\x86;C:\PROGRA~2\MIB055~1\2017\PROFES~1\\MSBuild\15.0\bin;C:\Windows\Microsoft.NET\Framework\v4.0.30319;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Common7\IDE\;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Common7\Tools\;C:\PROGRA~1\Bentley\MICROS~2\bin;C:\PROGRA~1\Bentley\MICROS~2\library;C:\PROGRA~1\Bentley\MICROS~1\MICROS~1\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\SHAYGE\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Users\SHAYGE\AppData\Local\Microsoft\WindowsApps;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\PROGRA~2\MIB055~1\2017\PROFES~1\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja;C:\PROGRA~1\Bentley\MICROS~2\bin\;C:\PROGRA~1\Bentley\MICROS~2\MigrationTools\;C:\PROGRA~1\Bentley\MICROS~1\MICROS~1\
So I looked at what's set to get the additional items you showed (just for comparison) and it looks like they're all similar enough to suggest that the environment is set up properly:
BMAKE_OPT=-IC:\PROGRA~1\Bentley\MICROS~2\mki\ MS=C:\PROGRA~1\Bentley\MICROS~1\MICROS~1\ MSMDE=C:\PROGRA~1\Bentley\MICROS~2\ MSMDE_OUTPUT=C:\Users\SHAYGE\AppData\Local\Temp\Bentley\MicroStationSDK\ DEFAULT_TARGET_PROCESSOR_ARCHITECTURE=x64 DLM_NO_SIGN=1
Looking at the path - is the issue with the first line, pointing at '..\Hostx86\x86' folder?
I was able to use the BUILD you mentioned and am digging into the output. Could this be the issue?
VSCMD_ARG_app_plat=Desktop VSCMD_ARG_HOST_ARCH=x86 VSCMD_ARG_TGT_ARCH=x86
__DOTNET_ADD_32BIT=1 __DOTNET_PREFERRED_BITNESS=32
It looks like both host and tgt arch should be x64? I don't think the DOTNET values need to be modified, as this is C++, but you'd know that better than I. So I made the change manually in the command shell from x86 to x64 and am not getting the x86/x64 error, but it's still not finding the other obj files, throwing unresolved external symbol errors. Until I'm sure this isn't dumb error messages, I'm going to hold off posting the verbose log file.
Going to try the make file rebuild first, see if cleaning that up will clarify the issue.
Everyone has helped a lot on this - I don't feel like I'm trying to decipher an alien language any more. Not understanding and trying to slog through it alone is quite challenging. Thanks for the responses so far.
This make file is old enough that it still defines and calls the linker manually. From what I've read, that's no longer necessary, and this is using additional files that are no longer required. Still working on it!
Gary Shay said:This make file is old enough that it still defines and calls the linker manually
Examine the delivered examples. They typically define these macros...
#------------------------------------------------ # Set up to use dlmcomp.mki and dlmlink.mki #------------------------------------------------ dlmObjs = \ $(o)$(appName)$(oext) DLM_NAME = $(appName) DLM_DEST = $(mdlapps) DLM_OBJECT_FILES = $(dlmObjs) DLM_OBJECT_DEST = $(o) DLM_SPECIAL_LINKOPT = -fixed:no # Notify linker this library does not require a fixed base address to load DLM_NO_DLS = 1 # USE DLLEXPORT IN .CPP DLM_NO_DEF = 1 DLM_NOENTRY = 1 DLM_NO_MANIFEST = 1 # If not set linker embeds your current (developer) patched MSVCRT version manifest in output dll. This is not desirable and produces side-by-side CLIENT ERROR: 14001) DLM_NO_SIGN = 1 # If not set and no certificate found, ERROR: 'singleton' is not recognized as an internal or external command LINKER_LIBRARIES = $(mdlLibs)bentley.lib \ $(mdlLibs)mdlbltin.lib \ $(mdlLibs)BentleyGeom.lib \ $(mdlLibs)DgnPlatform.lib \ $(mdlLibs)dgnview.lib \ $(mdlLibs)RmgrTools.lib
Then invoke the linker like this...
%include $(MDLMKI)dlmlink.mki
Macro dlmObjs is a list of compiled objects (*.obj) that feed into the linker.
dlmObjs
*.obj
In contrast to many include files, dlmlink.mki is full of comments.
dlmlink.mki
Gary Shay said: it still defines and calls the linker manually. From what I've read, that's no longer necessary
As far as I remember, it was never necessary, because mke / mki files exist always, from the time MDL was invented and added to MicroStation V4 (I think official SDK was released in 4.0.3 ;-)
Gary Shay said:and this is using additional files that are no longer required.
I recommend to start from scratch and to add, step by step, definitions (macros and conditions) that are required to solve error messages. My experience is that nearly every time, when something is added as "extra", at the end it is wrong, because it breaks something or the functionality is already available somewhere in mki files.
Follow Jon's advice and check how makefiles of SDK examples are written. DLM_* definitions are typically the only mandatory definitions (in addition to definition of compiled files of course).