Conflicting stl from different Visual C++ versions - visual-c++

I have a closed executable (with no source) which was compiled with VC++ 7.1 (VS2003).
This executable loads a DLL for which I do have the source code.
I'm trying to avoid compiling this DLL with the VS2003 toolkit, because it involves installing this toolkit on every machine I want to compile it on, and to use a makefile instead of directly use the newer VS project.
I changed parameters like the runtime library (I use /MT instead of /MD to prevent runtime DLL conflicts) and some other language switches to maintain compatibility with the old compiler. Finally it compiled and linked fine with the VS2005 libs.
But then when I tried running it, it crashed. The reason: The DLL sends an std::string (and on other places - an std::vector) back to the exe, and the conflicting STL implementation versions cause something bad to happen.
So my question is: Is there a way to work around it? Or should I continue compiling the DLL with the VC7.1 toolkit?
I'm not very optimistic, but maybe someone will have a good idea regarding this.
Thanks.

As the implentations of the stl libraries change, that breaks binary compatability, which is (to my understanding) when the size/member variables of an object changes. The two sides don't agree on how big a std::string/vector/etc is.
If the old executable thinks a std::string is 32bit char* ptr, and 32bit size_t length, and the new executable thinks a std::string is a 64bit iterator* iterator_list, 64bit char* ptr, 64bit size_t length, then they can't pass strings back and forth. This is why long-standing formats (windows, bmp) have the first member is a 32bit size_of_object.
Long story short, you need the older VS2003 version of the library (I don't think you necessarily need the compiler)

Related

Why are C/C++ 'obj' files valid only for a specific compiler?

After much struggling with attempting to link a C++ project to a 3rd party static library (.lib), I think I have solved the issue by verifying that I compile my project using the same compiler in which the .lib file was compiled (MSVC11).
Until this point, I assumed all .obj files were equivalent, thus I could take a .lib file (containing various .objs), and use that with any other project I might want to develop in the future. However, this was an incorrect assumption.
So I'm curious as to why (in the context of MSVC) .obj files differ from one version of the compiler to the next. Assuming you're targeting an x86 application, shouldn't the obj files be comprised of the same types of instructions regardless of whether or not you compiled using MSVC11/12/14?
TLDR; Why can't I link a project to an .obj that was created using a different MSVC compiler?
That's because it could be linked to another version of Visual C++ runtime libraries, which is incompatible with the version you are using.
This problem could be even with DLLs if you try to expose C++ objects from it.

arm-linux-gnueabi toolchain vs arm-linux-androideabi toolchain.

Can I compile files (e.g. C or C++ source code) using for my android device using the arm-linux-gnueabi-* toolchain?
My question might seem a bit silly, but will I get the same result as compiling with the arm-linux-androideabi-* toolchain?
A compilation might mean more than just converting source code to binary. A compiler like GCC also provides certain libraries, in this case libgcc for handling what hardware can't handle. When a compiler becomes a toolchain, it also provides runtime libraries standardised by the programming language similar to ones provided in target system. In arm-linux-gnueabi-'s case that might be libc and for arm-linux-androideabi- that's bionic.
You can produce compatible object files to be used by different compilers, that's what elf is for.
You can produce static executable which can be mighty in size and they should work on any matching hardware/kernel, because in that case toolchains aim for that.
But if you produce dynamic executables, those ones can only run on systems that's supporting their dependencies. Because of that a simple "hello world" application that's not static build by arm-linux-gnueabi- won't work on an Android system since it provides bionic, not libc.

Compile math functions from newlib with Visual C++ Express

I am extracting code designed for an embedded system that uses math functions from NEWLIB and I would like to compile that code with Visual C++ Express Edition. However, it seems that part of the code inside NEWLIB is designed to be compiled only with GCC.
Question: Can NEWLIB be somehow modified to be compiled with a compiler other than GCC? How?
Am I asking unreasonable things here?
As an example, the following symbols are not understood by the Visual Compiler:
__extension__
__ULong
_mbtowc_state
__attribute__
Note, I would content myself if I could compile with LCC. Would this be easier?
Building newlib with MSVC would take a large porting effort. You are better off porting your code to the libc provided by MSVC. They should be mostly compatible. Simply remove newlib from you build system, MSVC will automatically link you code against it's own libc.
If you can built your code under MSVC you've probably already ported it to MSVC's libc anyway. Unless you are explicitly including headers from newlib. For example, if you include stdio.h, by default it will pickup MSVC's version unless you override this behavior to get it to use newlib's version.

Options for using MSVC static libraries with MinGW (reimp was unable to convert them)

I work for a company that recently purchased a piece of hardware accompanied by an SDK. Unfortunately, all the SDK libraries were compiled with a Microsoft Visual C++ compiler (I don't know which one) and cannot be used by MinGW (I develop in Code::Blocks using the MinGW C++ compiler).
I've attempted to convert the libraries using reimp (from the MinGW utilities collection), which has worked in the past with static libraries from other vendors, but in this case the converted libraries result in "undefined reference" errors when linked.
The def files generated by reimp for each library during the conversion process don't look very good (they're filled with lines like ??0nameOfFunction##QEAA#AEBV0##Z, while the def files generated during a successful conversion contain lines similar to nameOfFunction#32), so it seems that the vendor's libraries are simply of a type that reimp can't convert.
Are there any other options that would allow me to use these libraries with MinGW? If not, is it reasonable to request that the vendor recompile their libraries with g++ (i.e., is it something they could feasibly do given that the libraries were originally developed using MSVC)?
Any comments or suggestions are appreciated!

LLVM and visual studio .obj binary incompatibility

Does anyone know if LLVM binary compatibility is planned for visual studio combiled .obj and static .lib files?
Right now I can only link LLVM made .obj files with dynamic libs that loads a DLL at runtime (compiled from visual studio).
While there probably is very small chances that binary compatibility will happen between the two compilers, does anybody know why it is so difficult achieving this between compilers for one platform?
As Neil already said, the compatibility includes stuff like calling convention, name mangling, etc. Though these two are the smallest possible problems. LLVM already knows about all windows-specific calling conventions (stdcall, fastcall, thiscall), this is why you can call stuff from .dll's.
If we speak about C++ code then the main problem is C++ ABI: vtable layout, rtti implementation, etc. clang follows Itanium C++ ABI (which gcc use, for example, among others), VCPP - doesn't and all these are undocumented, unfortunately. There is some work going in clang in this direction, so stuff might start to work apparently. Note that most probably some parts will never be covered, e.g. seh-based exception handling on win32, because it's patented.
Linking with pure C code worked for ages, so, you might workaround these C++ ABI-related issues via C stubs / wrappers.
Apart from anything else, such as calling conventions, register usage etc, for C++ code to binary compatible the two compilers must use the same name-mangling scheme. These schemes are proprietory (so MS does not release the details if its scheme) and are in any case in a constant state of flux.

Resources