iostream linker error

[rambu]

Hi,

I`, currently evaluating visualGDB and tried a fairly simply example.

The main routine (compiled with the visual studio compiler) calls a function

in a static library (created using visualGDB, default parameters, nothing changed).

This generally works fine. The result of a math operation , done in the function, is printed

in the main routine. But when I include <iostream> in the function,

I get linker errors, obviously with some cryptic assembler code

( like : unresolved external symbol _ZNSt8ios_base4InitC1Ev )

So, what is going wrong? ‘gcc’ should know ‘iostream’, right?

I`m aware that this might not be visualGDBs fault, but I just have too little knowledge

of cygwin/linuc programming.

 

thanks for help!

[support]

You cannot reliably combine code from MS C++ compiler and GCC in one module as those compilers have too many differences. However you can create shared library (.DLL) using VisualGDB and load it from your MSVC-compiled app (or vice versa). As long as those are 2 different modules, it should work.

[rambu]

Thanks for your answer, Bazis. I tried it now with a explicitly called dll. ( created the .def file manually and then created the .lib file using microsofts lib.exe ). While everything  works when there is no printf ( or std::cout ) in the dll, I get an access violation error when they are included. std::cout -> Unhandled exception at 0x00000003FD11D61D (cygstdc++-6.dll) in callingDLL.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. printf -> Unhandled exception at 0x000000018011AE47 (cygwin1.dll) in callingDLL.exe: 0xC0000005: Access violation writing location 0x00000000D10400D5.  I really tried to solve this, but failed. So, sorry if this some sort of a beginners problem, again…

[support]

Hi,

Are you trying to load a Cygwin DLL into a non-Cygwin EXE? If yes, this is unsupported and can cause very strange bugs. I would recommend building your code with MinGW instead of Cygwin. It does not emulate certain Unix-world things like fork(), but is much easier to integrate with existing code from the Windows world.

[rambu]

Bazil, yes, what I exactly want to achieve is to call a cygwin dll from a windows dll. I read this here : https://cygwin.com/ml/cygwin/2002-02/msg00689.html and other information from the web which made me think it should not be a problem. So, you recommend MinGW? Will check that, thanks!

 

[support]

It might be possible in theory, but in practice many Cygwin-specific functionality will simply crash randomly because it will expect certain process-wide preparations to be made by the host executable (that will not be made as your EXE is not cygwin-based). You could try investigating and fixing those crashes, but using MinGW would be a much easier solution.

[Author]

Posts