
Dear GHC users, I have the following problem and I wonder if anyone can help. I am using the FFI to talk to a library of functions written in C++. On Unixes (Solaris, Linux) this works just fine if one adds the right -ldstdc++ here and there. However, I am using Cygwin now and that is where all the problems start. The C++ stuff compiles fine (using Cygwin's g++). The Haskell stuff compiles just fine (using Win Ghc). However, at linking time I get the following error: - undefined reference to '_impure_ptr' - undefined reference to 'operator delete(void*)' - undefined reference to 'vtable for ___cxxabiv1::__blahblah' These are all things that C++ uses internally. I think the problem is that I used Cygwin's g++ compiler and that Ghc uses Mingwin's gcc compiler to compile and link. However, I have tried to recompile the C++ libraries using the Mingwin C++ compiler but it starts throwing pages of error messages at me. The other way around: using a Cygwin specific GHC, seems more appropriate, but where does one get one of those? (I have never managed to compile one myself.) Any ideas? /Koen.

On Fri, Jan 10, 2003 at 02:11:35PM +0100, Koen Claessen wrote:
The C++ stuff compiles fine (using Cygwin's g++). The Haskell stuff compiles just fine (using Win Ghc). However, at linking time I get the following error: - undefined reference to '_impure_ptr' - undefined reference to 'operator delete(void*)' - undefined reference to 'vtable for ___cxxabiv1::__blahblah' These are all things that C++ uses internally. I think the problem is that I used Cygwin's g++ compiler and that Ghc uses Mingwin's gcc compiler to compile and link.
It is possible to trick ghc into using cygwin's gcc in mingw-mode, the following steps works for me to do that: * compile the c++-stuff with g++ -mno-cygwin * copy /usr/bin/gcc.exe to c:/ghc/ghc-5.04.2/gcc.exe * rename c:/ghc/ghc-5.04.2/gcc-lib to something else (ghc feeds a -B option to gcc, which we cannot(?) override) * compile with "ghc -optl -mno-cygwin -lstdc++" (add -optc -mno-cygwin if -fvia-C is used) (i.e. we would like to use /usr/bin/gcc -mno-cygwin as the linker) I think it should be possible to use -pgml instead of replacing the binary, but that didn't work for me..
However, I have tried to recompile the C++ libraries using the Mingwin C++ compiler but it starts throwing pages of error messages at me.
However, the method above doesn't help if you really need cygwin for your c++-library, which you seem to do? /Peter

Peter Strand wrote: | It is possible to trick ghc into using cygwin's gcc in mingw-mode, | the following steps works for me to do that: | * compile the c++-stuff with g++ -mno-cygwin | * copy /usr/bin/gcc.exe to c:/ghc/ghc-5.04.2/gcc.exe | * rename c:/ghc/ghc-5.04.2/gcc-lib to something else | (ghc feeds a -B option to gcc, which we cannot(?) override) | * compile with "ghc -optl -mno-cygwin -lstdc++" | (add -optc -mno-cygwin if -fvia-C is used) Thanks for your reply, Peter. Actually, we tried the above without the renaming of gcc-lib, and also the -pgml flag trick. In the end, we found out that the gcc versions of ghc and mingwin and cygwin did not match up. So, when we used normal cygwin g++-2, the linking suddenly produced a lot less error messages. Actually only one: undefined reference to _impure_ptr. After hours of hacking, I simply created a C file that defines a constant called _impure_ptr, and linked that with everything else. It works now! And it doesn't even crash :-) | However, the method above doesn't help if you really | need cygwin for your c++-library, which you seem to | do? We found out that the complex makefile system used cygwin-style paths which the mingwin g++ did not understand but that was "easily" fixed by replacing mingwin's g++ by a script that first converts all its arguments which look like filenames to windows-paths and then calls mingwin's g++. Anyway, thanks for everyone's suggestions! /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen Chalmers University, Gothenburg, Sweden.

Just a very general remark on this topic: Mixing C and C++ is a highly delicate undertaking, see e.g. item 34 in Scott Meyer's highly recommendable "More Effective C++". The linking errors you see are probably related to initialization/shutdown of the C++ runtime system, including construction and destruction of C++ statics. Even if you don't use the latter, a library you use could do. As a rule of thumb, if any part of your program is written in C++, compile "main" with the same C++ compiler and link the same way as your C++ compiler does. Otherwise there can be *very* strange effects like non-working "catch" clauses, segfaults in C++'s runtime system, flawed template instantiations, etc. (War stories available if requested :-} Cheers S.
participants (3)
-
Koen Claessen
-
Peter Strand
-
Sven Panne