• State Verified Answer
  • Replies 12 replies
  • Subscribers 30 subscribers
  • Views 909 views
  • Users 0 members are here

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

Gary Shay
Offline

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.

  • Mstn CE 10.15.00.74
  • VS2017
  • Using C++
  • Have 3 different cpp source code files, linking them together
  • Have several RSC files, same
  • Using the appropriate Microstation CONNECT Edition SDK command prompt (as Administrator) to set up the environment and start Visual Studio

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.

  • Have I broken the bmake configuration now or is it working and the new problem is the incompatibility between x86 and x64 modules?
  • How do I toggle the build to create x64 so it all links and not x86 and throws this error?

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

  • +1 Offline

    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

    Answer Verified By: Gary Shay 

  • 0 Offline in reply to Gary Shay

    Hi ,

    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 



Communities
Support and Services
Training and Learning
Social Media