I'm porting a 32-bit C++ app to 64-bit (using VS2008).
I'm not sure what does this field mean in the VS2008 ::
Visual studio ->Configuration Properties-> Linker-> Advanced Options->Target Machine.
By default it's value is set to "Not set".
Is it compulsory to change it's value to "MACHINEx64" if I want my application to be ported to 64-bit executable.
Yes, this is a very important option. It sets the IMAGE_FILE_HEADER.Machine field in the executable file. The very first field of the EXE or DLL header.
Windows check this when it loads an EXE and knows whether it needs to create a 32-bit or a 64-bit process from that field. The only reason it is a the Linker + Advanced property page is because you don't normally change it. The setting is pre-selected by the project configuration you created. If you get "Not Set" then you are basically doing it wrong, hard to guess what you are doing.
Assuming you have a properly configured project that builds a working 32-bit build for your program, you create the 64-bit build with Build + Configuration Manager. In the "Active solution platform" combobox at the upper right, select <New...>. Pick "x64" in the dialog. Hopefully the other defaults (Copy settings from = Win32, Create new project platforms ticked) are correct for yours. Go back to the Linker + Advanced property page and the setting should have changed to MachineX64.
This option relates to the linker option /MACHINE and is a hint for the linker for what target architecture to link the object code if he (the linker) cannot determine this from the object file. As MSDN states you usually have not to specify this. So no you don't need to explicitly specify this flag when porting your code.
Related
I am trying to follow this guide
to configure VC++ for WxWidgets. I got stuck here.
So for Core wxWidgets libraries to include, I did include wxmsw31u[d]_core.lib and wxbase31u[d].lib under Linker>>Input>>Additional Depenedencies. That is all to it right?
As for Linking with correct runtime library, can someone tell me how that is done? I manage to get here but don't know how to set the indicated settings.
Please help. I really appreciate it.
When you want to debug your app the debugger must know where in the compiled code is each function used. In jargon, the "debugging symbols". Windows puts these symbols in the compiled executable, while Linux uses another, .devfile.
When you compile code (your app or wxWidgets library) you must tell the compiler whether you want a "Debug" version or a "Release" one.
If you want the debugger to be able to step into wxWidgets code, then you must compile wxWidgets in "debug" mode, which will add the character d to the library files built. So, you must add, for example, wxmsw31ud_core.lib to your app dependencies. Notice the d between u and _. Use the file explorer to see all files generated by wxWidgets compilation process.
Perhaps you don't want all this wxWidgets "debug". Then use another wxWidgets compilation route and add wxmsw31u_core.lib instead of the d'd version. Still you can compile your own app in debug mode, but not being able to step through wxWidgets internals.
Now for your app, a) do you want a single executable file also containing wxWidgets code? or b) let your app in a .exe file which uses as needed external .dll files?
a) is called "static linkage" while b) is called "dynamic linkage"
As you can see, there are four combinations of debug/release & static/dynamic. You must choose one "runtime library" to link to your app.
The table in the wiki shows the switch and MSVC lib (select the desired combination in the 'properties' page) to use in your app; and macro definition required to build wxWidgets if you use nmake instead of the already provided configurations in VS.
Take a look at docs\msw\install.txt for more info.
The best advice I give is that you look into "minimal" sample project. Load it into VS and read every option. You can even make a copy, change some file names and use it for your own app.
I recommend using the official instructions instead of the wiki, they're simpler and, if you look at the last paragraph, you can see that you don't even have to link the libraries manually with MSVC.
You also don't need to do anything special to link with the correct version of the CRT, the defaults are just fine.
I want to add different version of Crystal Reports as a setup prerequisite using InstallShield depending on platform. For x86 32bit version should be installed, for x64 - 64bit.
What kind of condition should I add to do so? I've found that I can select particular OS as condition but there is no option to just select 32 or 64 bit.
Thanks in advance.
UPD1: In InstallShield I can choose the following types of condition:
Check if registry entry exists. I wanted to check for WoW6332Node
but then I found that this node can be listed in 32bit OS:
http://support.microsoft.com/kb/2582176 Also I found that I can
check some registry entries
https://superuser.com/questions/290906/check-if-32-or-64-bit-windows-os-via-registry/290929
but I'm not sure that they present in all windows versions.
Check if certain file exists. I can check some file in Program Files
(x86) folder to detect 64bit OS, but it's not a good idea in my
opinion.
I think you can use the VersionNT64 property for this.
More details can be found here:
http://msdn.microsoft.com/en-us/library/aa372497(v=vs.85).aspx
Edit: As it can be seen in the documentation, this property is only set on a 64-bit computer otherwise it is empty.
EDIT: 13.VIII.2014
After the prerequisite has been selected to be added to your installation package, a feature has been assigned.
So, you can go in the "Features" view and select the created feature. I can see it has a Condition field, most likely there you can use the VersionNT64 property.
I program a embedded Linux on a separate target. For that I use Eclipse as a editor and the powerpc-linux-gcc.
That's a bit uncomfortable.
Is it possible to use a powerpc-linux-gcc in Eclipse?
Yes, but you want to install (via Help -> install new software -> from all available sources -> Mobile and device development) C/C++ cross compiler support and possibly C/C++ GDB hardware debugging.
When you start new project, selecet C or C++ project, then Executable, then "empty project" (or something else) and then make sure, in to selecet "Cross gcc" in right listbox. Press Next button until the page with cross compiler prefix and path shows. There you need to enter prefix (powerpc-linux- in your case) and you can also select your compiler's directory (if you have not added it to path).
When you have project set up this way, selected toolchain is used to build. You can alse set up "GDB hardware debugging" session to debug your application remotely.
I have a C++ Visual Studio project which I'm trying to compile for x86 and x64 architecture. I've googled and found a lot information how to do it and it seems to work, but it left me deeply confused about what is going on behind the curtains.
Apperently, the only difference in the settings is a switch in the linker command line flags (to be precise, it's the /MACHINE flag).
If that's the case however, then the object files of the compilation must be platform independent - which is somehow the exact opposite of what I always assumed it to be, since object files are supposed to be sequences of machine code which in turn should be platform dependent.
So, my question is: which part(s) of the build process does not behave the way I thought it would?
Thanks for your time and wisdom!
Michael
When compiling for 32-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\cl.exe. When compiling for 64-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe. The first compiler produces 32-bit object files, the second produces 64-bit object files. This can be seen by running dumpbin.exe on the object files to see their specified architecture.
The compiler invocation remains the same (more or less) -- what changes is the executable $PATH that is set before building. By pointing the PATH to the 32-bit or 64-bit directory, it sneakily changes the whole set of programs that is run to build your project. You can see this by looking at the Project Properties > Configuration Properties > VC++ Directories > Executable Directories, and clicking on "Edit". In the "Inherited Values" box you'll see the path for the current Configuration and Platform.
I am getting an error while porting my application from VC6 to Visual Studio 2005.
Does anyone have any idea what this means?
mfcs80.lib(dllmodul.obj) : error
LNK2005: _DllMain#12 already defined
in MSVCRT.lib(dllmain.obj)
From http://support.microsoft.com/default.aspx?scid=kb;en-us;q148652
A LNK2005 error occurs when the CRT
library and MFC libraries are linked
in the wrong order in Visual C++
Because
The CRT libraries use weak external
linkage for the new, delete, and
DllMain functions. The MFC libraries
also contain new, delete, and DllMain
functions. These functions require the
MFC libraries to be linked before the
CRT library is linked.
So
There are two ways to resolve this
problem. The first solution involves
forcing the linker to link the
libraries in the correct order. The
second solution allows you to find the
module that is causing the problem and
to correct it.
Either
Force Linker to Link
Libraries in Correct Order
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, click to select Input in the Category combo box.
In the Ignore libraries box, insert the library names (for example,
Nafxcwd.lib;Libcmtd.lib).
Note The linker command-line equivalent in /NOD:.
In the Object/library modules box, insert the library names. You
must make sure that these are listed
in order and as the first two
libraries in the line (for example,
Nafxcwd.lib Libcmtd.lib).
To set this option in Visual C++ .NET,
read the "Setting Visual C++ Project
Properties" online help topic.
Or
Locate and Correct the
Problem Module To view the current
library link order, follow these
steps:
On the Project menu, click Settings.
In the Settings For view of the Project Settings dialog box, click to
select the project configuration that
is getting the link errors.
On the Link tab, type /verbose:lib in the Project Options
box.
Rebuild your project. The libraries will be listed in the output
window during the linking process.
I'm sure there are a number of reason this could happen - the worst one I ever found was when trying to integrate a number of static libraries (ours) that were originally DLLS (in fact, we build the projects as both DLL & static libraries).
Our C++/CLI DLL was using the static versions of these libraries (To avoid DLL dependency issues that were causing ASP.NET loading issues when the C++/CLI Dll was being used) and was initially seeing the same linker error.
The problem turned out to be the use of AFX_MANAGE_STATE(AfxGetStaticModuleState()) macro that was needed when the code was built as a DLL but not actually needed for the static library call.
To solve this i ended up adding the following code to the stdafx.h of each project.
#ifdef OMUTILITIES_LINK_STATIC
#undef AfxGetStaticModuleState
#define AfxGetStaticModuleState AfxGetModuleState
#endif
This, of course, may not be your specific problem. But the way i eventually figured it was by turning on the /VERBOSE option for the linker and seeing who, what, where & when it was pulling in the runtime libraries. (Project Properties/Configuration Properties/Linker/Show Progress in vs2005)
You could set the linker input to ignore the troubling library in the project properties, but this may or may not work.