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

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:

• share your .mke file (and .mki, if you use any custom one)
• create and share make process verbose log file (when don't know how, search for "build verbose" phrase)

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

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

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,

  Jan

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.

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.

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!

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.

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