[CONNECT C++] Fatal link error: module machine type 'x64' conflicts with target machine type 'x86'

Hi Gary Shay,

Glad you find build.bat to be a helpful troubleshooting tool and hear you are making progress in both the development shell build and migration progress.  I would like to point out another migration tip or two that may help you navigate the SDK resources efficiently wrt a migration set of eyes.

1. In your CPP modules, comment out all includes and start by only including: <Mstn\MdlApi\MdlApi.h>. MdlApi.h is essentially the V8 era equivalent of the old msvar.fdf that would include the most common "high-level" includes (fdfs and where needed .h files) to help reduce the amount of time searching for dependent header files for missing definitions. Of course you will require additional includes (.fdf and/or .h) but using the tools below can help quickly ensure only the correct list of dependencies is identified vs. some headers that should not be included like .r.h (hence the new file extension).
2. The SDK provides a couple convenience scripts and macros to help navigate and display information you need during migration (in the proper locations and order from a developers perspective), so try using these convenient ways to interrogate our SDK using SDKSearch and SDKMacros available:
   
   
   1. SDKSEARCH SearchTerm - this script will dive down: migration remap file(s), examples, includes, binary libraries, the current (your) source code folder, and even (MicroStation) product paths (text and binaries); listing potential matches found to use, reference or explore in more detail. After sdksearch exhausts local resources (think I have done my homework), it then askes a simple Y/N if you want to look on the SDK's respective online Bentley Community listing the most recent SearchTerm hits first; in case there are "known issues" or "best code snips/recommendations" to save you additional time and effort otherwise lost.
   2. qs SearchTerm - a recent macro added to provide targeted quick searches (qs) of only examples, includes and remap files
   3. sd SearchTerm - a recent macro added to provide targeted searches (for) definitions (sd).

My goal with the environment and SDK tools is to provide you with the same tools and techniques I use to provide convenient, quick, correct and helpful information for any given topic (searchterm).

Good luck and HTH,
Bob 

All,

Thank you so much for all your help.  I have (qualified) good news on this request, see below.  I've been hesitating adding this update while I worked through a few remaining issues, mostly because I'm not doing very well migrating it, mostly because I continue to struggle finding information that I think I should be able to find, but I've just not got the hang of it yet.

So I think I've been able to get past the x64 conflict, and I've still got some weird linkage issues around MSTXTFIL.H routines for mdlTextFile_XXX functions.  It appears that I'm doing what I should, but the link is failing to find the mdlTextFile_xxx routines.  For the time being, I'm going to mark an answer to this issue and follow up separately for the mdlTextFile_xxx problem if I can't find what I need.  It's incredibly frustrating to not have things where I think they should be, but that's not the documentation or the SDK's problem, I don't think.

So thanks for all the help, I'm continuing to plug away at this.  

Resolution:

I took the Dialog Box example MKE file and modified it to compile all the files and configure the linker.  In that MKE, it also uses a resource MKI file that I copied.

Comparing the old MKE to the updated one, I had several issues where object file locations are different.  The linker MKI redefines the $(o) and looks for the obj files in a different location than I was putting them - the old MKE did all that 'manually' and was telling it to go someplace else.

Probably one of the biggest helps was build verbose.  It really does give a LOT of information, but it definitely told me where the issue was occurring.

G

Hi Gary,

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

Regards,

  Jan

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.

In contrast to many include files, dlmlink.mki is full of comments.

Jan -

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!

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

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:

1. Install required Microsoft Visual Studio version, configuring the necessary Workloads requirements and Components listed
2. Install closely matched MicroStation product version
3. Install closely matched MicroStation SDK version; ensuring (remaining conditions/requirements):
   
   1. Microsoft 8DOT3NAMES enabled for source code folders
   2. Microsoft Run As Administrator enabled when directing binary output files to system folders, like C:\Program Files\Bentley\...
   3. Build project source code using the MicroStation Developer Shell (Run as Admin)

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:

1. Open the developer shell running as admin
2. From the default Examples folder, type: pushd DialogBoxes\Myapp
3. Type: build verbose

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

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.

Look for relevant definitions: e.g. MS or 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.

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:

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,

  Jan