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