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