How to resolve conflicts between winhttp.lib and wininet.lib - c++

I am writing a C++ program using C++Builder from Embarcadero. My application uses wininet.lib to do basic internet connections. I have some new c++ code I need to integrate into my application that use winhttp.lib to access the internet. This causes many "Multiple declaration" errors for the functions in both .lib files such as (Multiple declaration for 'HTTP_VERSION_INFO'). There are also a lot of "Redefinition" warnings such as (Redefinition of 'SECURITY_FLAG_IGNORE_CERT_DATE_INVALID' is not identical)
What is the best way to resolve this problem? Should I rewrite the new code so it uses wininet.lib and not winhttp.lib? Is it possible to isolate the code that uses winhttp.lib so there no conflict? How would you solve this problem?

Related

Using Objective C++ for WatchKit

When I try to use Objective C++ for my WatchKit Extension, I get linker errors with messages like
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_WKInterfaceController", referenced from:
I tried creating a new project using the Single View Application template and then added a simple WatchKit App target to that. Without changing anything, the whole thing compiles fine but if I rename the InterfaceController.m file to InterfaceController.mm, then even that simple project gives the above error.
How can I build a WatchKit App Extension using Objective C++?
I couldn't find anything on the web or in Apple's dev forums on this, but I finally worked out what's going on and came up with a workaround.
The problem seems to be that some sort of magic trigger for the linker isn't happening if ALL of the source files are in C++ and Objective C++. The solution was to create a single .m file which includes the WatchKit header. This file only needs this for its contents:
#import <WatchKit/WatchKit.h>
Save that into a .m file, add it to the project and everything will be sunshine and rainbows.
I reported this to Apple through Radar and got this response:
This issue behaves as intended based on the following:
The difference between the objc and objc++ compiles comes down to objc
enabling -fmodules and objc++ not. If you build the objc without
-fmodules you get the same link error, and the driver is dropping -fmodules when in C++ mode, leading to the error.
Looks like we get a number of linker option load commands in the
object when we use -fmodules, but we don't get them without. Thus, an
object with -fmodules can find all of the frameworks it needs on its
own, but an object without cannot.
So the problem is simply that objective c++ modules aren't supported,
so the project has gone from using modules to not using modules. This
means autolinking isn't available, so the project needs to explicitly
link against the frameworks that it uses.
For me this started happening if I set Enable Modules (C and Objective-C) to NO in the Build Settings tab of the WatchKit Extension target. Setting it back to YES gets rid of these errors.
I had the same issue in my Swift project after integrating a third party framework that was written in Objective C. I had to create Bridging-Header and after that the same error message appeared because that framework was referencing WatchKit. All I had to do was importing WatchKit in the Bridging-Header:
#import <WatchKit/WatchKit.h>

Including C++ sources in a Haskell project

I'm trying to make a data structure that will be exposed in Haskell, but implemented in C++. So far I've implemented it in a .cpp file, declared all the functions I need as extern "C" and added the source file to the c-sources field in the .cabal file. When I build the project (in this case with stack build) it seems to build fine.
I know it's doing something to the C++ file because it doesn't compile if there are errors.
I've yet to try running the project because it's a library and so far it doesn't have anything "runnable" written, but the repl doesn't seem to work.
When I try running it (stack repl in this case) I get a missing symbol error with some mangled name that may or may not be refer to a name in my file.
unknown symbol `_ZdlPv'
linking extra libraries/objects failed
How can I fix this issue? I've had a similar problem before that I fixed by manually compiling the source into a dynamic library and then use that library in my project. I don't want to do that since it ties me to a platform and since it makes no sense that a simple C++ couldn't be compiled with the project using the tools that GHC already has. I want to be able to put this on hackage.
Is there something I'm missing? If not, is it a bug and are there plans on fixing it?
Ok, I've managed to "fix" this for now.
I added a extra-libraries: stdc++-6, gcc_s_seh-1 to my cabal file and now it works. No idea if this is platform independant but those libraries do get shipped with GHC when I install it through stack.

Eigen Use in ios project

I am trying to use Eigen 3 in my ios project i have added header files but it does not allow me to compile. it always gives error.
Unable to resolve. I have been searching for solutions for many days.
My All files are .mm
I think, i am missing any compiler flag, linking or anyting.
Please help me.
Attached screen shots of Xcode.
I would appreciate if someone can help me.
Thanks
First of all, make sure you are including Eigen/Core (or the likes) and not directly the .h files that are in Eigen/src/. Then, I guess the problem is that your are mixing c++ and objective c code (.mm file). That confuse the compiler because Eigen requires a very good C++ compiler support. Cannot you use pure C++ code in ios?
The error statements are quite clear: you use identifiers that are not known to the compiler.
Possible reasons:
You failed to include the proper header files. E.g., Dynamic is defined in Constants.h
You failed to open the proper namespace. E.g., Dynamic is defined for the namespace Eigen.

LNK2038, iterator mismatch error, need to ignore

I'm getting the linker error LNK2038 when trying to convert a VS2008 project to VS2010. This error occurs when two different projects are compiled in which one is using _DEBUG preprocessor macro, and the other is not. Basically I have a 3rd party library that only has release .libs, so when I try and use that library when building my project in debug mode I get this mismatch.
I understand why Microsoft is giving this error (STL iterator safety), however our project does not use Microsoft's STL, we use STLPort, so this error means nothing to our project. I just need a way to prevent it from doing this check.
Inside of the STL includes there is a file called yvals.h, which includes the #pragma detect_mismatch definition for the various _ITERATOR_DEBUG_LEVEL settings. That set of definitions is wrapped in an #ifndef _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH, #endif. However, even if I define _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH as a preprocessor macro for my entire project I'm still getting the same linker error. I can even alter yvals.h to define that macro and it does nothing (I'm assuming because the STL itself would need to be recompiled).
So my question is basically, what steps can I take make _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH actually work as intended so that my project doesn't do this check anywhere when compiling in VS2010?
EDIT: I know this is a late response but I just found this post and realized I didn't post the solution. As others mentioned there was a mismatch in the libraries. As it turns out VS2010 changes the default directories for certain projects (I found a thread on MSDN at one point full of complaints about it), and that directory change had caused VS2010 to look in the wrong directory for the debug library, and it was finding the release library instead.
You must use the same version of the standard library, compiled with the
same options, if you expect to successfully link. If you use STLPort,
then you can only link with libraries which use the STLPort, not with
libraries which use the VC++ standard implementation. If you mix,
either you will fail to link, or you will get strange runtime errors.
The problem is that things like std::vector<>::iterator may be defined
completely differently; depending on where and how they are used, you
will find yourself using an instance constructed in a different library,
with a different layout.

Building a DLL via Maven with mojo-native

I can build a simple dll consisting of a source file, a header file and a definition but now I am progressing beyond a simple toy dll and working towards something more real (ie: more complex).
The DLL I am trying to compile has 2 source files, 2 headers and the dreaded stdafx pair.
To compile normally you would use /Yc for the pch and /Yu to use it.
How do you specify that with in the constraints of mojo-native's compiler options?
In the end, after nearly a week trying to get Maven working I have come to the conclusion that Maven + Mojo-native is not possible if you are trying to do any non-trivial C++ development.
I also tried jade.native fork of Mojo-native, but that suffered from similar problems which primarily are a lack of documentation followed by a lack of development.
I the end we have knocked that on the head and are now looking at Hudson for the C++ side of things.

Resources