RE: FFI & C++ & Cygwin
| It is possible to trick ghc into using cygwin's gcc in mingw-mode, | the following steps works for me to do that: Interesting. The only worry is that the run-time system and libraries are all pre-compiled with the mingw gcc. So it's not clear to me that the process Peter outlines will always work. Or, if it does, why doesn't it work using the mingw gcc all the time for Haskell files? Here's a guess: use g++ -mno-cygwin for the C++ files and ordinary ghc for the Haskell files. Then, linking with ghc will give linking errors, as Koen found, only because the g++ files expect to be linked with some g++ runtime system code. If that is the only problem, it can be solved by doing g++ -v to link, seeing what extra link libraries are given to ld, and giving those same libraries to the ghc link step. Or, dually, see what libraries ghc passes to ld, and give those to g++. If this works, and someone will write it up, I'll add it to the users guide. Incidentally, on the subject of building GHC to target Cygwin (rather than Mingw), I'm sure it's possible, because Sigbjorn has done it, although it's not a route we support, and I just don't know understand all the differences well enough to know what the problems are. But, if someone makes it work (which I'm sure is possible) I'd gladly apply make-system patches, and add guidance notes to the building guide, in here: http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html Simon | * 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 | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI & C++ & Cygwin
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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI & C++ & Cygwin
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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI & C++ & Cygwin
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FFI & C++ & Cygwin
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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI & C++
Wolfgang, On Solaris, you can build GNU C++ either way; that is, to use shared libraries or linked libraries. (In fact you can also build it to enable both, and select one or the other at link time.) So, this is certainly worth checking. The easiest way to check it is to run "ldd -r" on the executable. On Wed, 2002-10-30 at 15:53, Wolfgang Thaller wrote: > Many platforms have the C++ runtime and the C++ standard library as a > static library (probably because the C++ ABI is not as stable as it > should be...). I think this applies to both Mac OS and to Windows > [mingw32], perhaps it's the same with Solaris. > If that is the case, it would explain the problem, I think. > > GHCi can't load static libraries [yet - the ar format shouldn't be too > difficult to implement], so everything that's needed from static > libraries has to be linked into the ghc binary and probably also listed > in Linker.c (who else doesn't like those hard-coded symbol references?) > > Just my EUR 0.02 :-) > > Cheers, > Wolfgang > > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI & C++
Many platforms have the C++ runtime and the C++ standard library as a static library (probably because the C++ ABI is not as stable as it should be...). I think this applies to both Mac OS and to Windows [mingw32], perhaps it's the same with Solaris. If that is the case, it would explain the problem, I think. GHCi can't load static libraries [yet - the ar format shouldn't be too difficult to implement], so everything that's needed from static libraries has to be linked into the ghc binary and probably also listed in Linker.c (who else doesn't like those hard-coded symbol references?) Just my EUR 0.02 :-) Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI & C++
On 30 Oct 2002, Seth Kurtzberg wrote: > What is the O/S and compiler? That the C++ new operator is not found is > very strange. Throw is another story, as throw doesn't appear in the > compiled code with some compilers. We run Solaris + gcc 2.95.3. The exact error message looks like this: Prelude> :set -package satnik Loading package satnik ... linking ... /.../chalmers.se/fs/cab/cs/work/proj/formal-methods/home/src/fm/HSatnik/Satnik.o: unknown symbol `__builtin_new' ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): can't load package `satnik' Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. ... which to me seems like it cannot find new. /Niklas ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI & C++
What is the O/S and compiler? That the C++ new operator is not found is very strange. Throw is another story, as throw doesn't appear in the compiled code with some compilers. On Wed, 2002-10-30 at 04:18, Simon Marlow wrote: > > I am currently trying to create a Haskell interface to a C++ > > library and > > cannot get it to work completely. The problem seems to be > > that the linker > > must be able to find the code for basic C++ constructs like > > new and throw. > > Apparently it is able to do so when compiling an executable, > > but when I > > try to do the same with ghci it fails. Anybody have an idea why this > > happens and what to do about it? > > I don't know the gory details, but it might be that we would have to link GHCi with >the C++ linker for this to work. Would anyone with a clue about C++ linking like to >comment? > > > The feature to install local packages is currently a bit > > awkward. I would > > like to be able to simply use a local package the same way I > > use a normal > > package, and my first try was to set the package-conf file in my .ghci > > file. But this doesn't work very well for two reasons: (1) it > > only works > > for the interpreter, but not for the compiler (2) it isn't read until > > *after* the command line is read, so any packages given there is not > > recognized. Is it possible to have a common (.ghc) file that > > is used for > > both the compiler and the interpreter, and that is read *before* the > > command line is interpreted? > > Hmm, I must admit I'm a bit averse to adding features like this unless they are >really necessary. One problem is that when someone submits a bug report, we'll have >to start asking "do you have a .ghc file? what does it contain?". The current >situation has the advantage of being simple. > > Can't you just alias ghc to 'ghc -package-conf ...'? > > Cheers, > Simon > ___ > Glasgow-haskell-users mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: FFI & C++
> I am currently trying to create a Haskell interface to a C++ > library and > cannot get it to work completely. The problem seems to be > that the linker > must be able to find the code for basic C++ constructs like > new and throw. > Apparently it is able to do so when compiling an executable, > but when I > try to do the same with ghci it fails. Anybody have an idea why this > happens and what to do about it? I don't know the gory details, but it might be that we would have to link GHCi with the C++ linker for this to work. Would anyone with a clue about C++ linking like to comment? > The feature to install local packages is currently a bit > awkward. I would > like to be able to simply use a local package the same way I > use a normal > package, and my first try was to set the package-conf file in my .ghci > file. But this doesn't work very well for two reasons: (1) it > only works > for the interpreter, but not for the compiler (2) it isn't read until > *after* the command line is read, so any packages given there is not > recognized. Is it possible to have a common (.ghc) file that > is used for > both the compiler and the interpreter, and that is read *before* the > command line is interpreted? Hmm, I must admit I'm a bit averse to adding features like this unless they are really necessary. One problem is that when someone submits a bug report, we'll have to start asking "do you have a .ghc file? what does it contain?". The current situation has the advantage of being simple. Can't you just alias ghc to 'ghc -package-conf ...'? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FFI & C++
> Hi, I am currently trying to create a Haskell interface to a C++ > library and cannot get it to work completely. If you want to interface Hugs to C++ code, you have to link Hugs using a C++ compiler so that the Hugs binary contains new, throw, etc. I believe the main thing this changes is that some extra libraries are linked into the binary. Obviously, the story is a bit different for GHC but you probably want to either: 1) Tell GHC to use a C++ compiler as its linker; or 2) Figure out what libraries C++ adds in (e.g., compare what g++ -v and gcc -v do with hello world) and tell GHC to use them when linking. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FFI & C++
Hi, I am currently trying to create a Haskell interface to a C++ library and cannot get it to work completely. The problem seems to be that the linker must be able to find the code for basic C++ constructs like new and throw. Apparently it is able to do so when compiling an executable, but when I try to do the same with ghci it fails. Anybody have an idea why this happens and what to do about it? A second question, The feature to install local packages is currently a bit awkward. I would like to be able to simply use a local package the same way I use a normal package, and my first try was to set the package-conf file in my .ghci file. But this doesn't work very well for two reasons: (1) it only works for the interpreter, but not for the compiler (2) it isn't read until *after* the command line is read, so any packages given there is not recognized. Is it possible to have a common (.ghc) file that is used for both the compiler and the interpreter, and that is read *before* the command line is interpreted? /Niklas ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDIRECT/FFI - C enums
Sigbjorn Finne wrote: > This is just what we agreed on a couple of months ago, no? [...] What are you referring to exactly? CEnum? +/&/| for Enum? I can't remember any of them... Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDIRECT/FFI - C enums
This is just what we agreed on a couple of months ago, no? I'm afraid this has been sitting on my HDirect ToDo list since then, as I've been busy with misc other Haskell-related matters. However, I've unqueued the item & implemented something which is close to what you're after, I believe. It's just been checked into the hdirect portion of the CVS repo. Have a go & let me know whether this scratches your itch or not. --sigbjorn - Original Message - From: "Mike Thomas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 27, 2001 23:34 Subject: HDIRECT/FFI - C enums > Hi all. > > HDirect can generate code as follows: > > > data CONST_DDWAITVBFLAGS > = DDWAITVB_BLOCKBEGIN > | DDWAITVB_BLOCKBEGINEVENT > | DDWAITVB_BLOCKEND > > instance Prelude.Enum (CONST_DDWAITVBFLAGS) where > fromEnum v = > case v of >DDWAITVB_BLOCKBEGIN -> 1 >DDWAITVB_BLOCKBEGINEVENT -> 2 >DDWAITVB_BLOCKEND -> 4 > > toEnum v = > case v of >1 -> DDWAITVB_BLOCKBEGIN >2 -> DDWAITVB_BLOCKBEGINEVENT >4 -> DDWAITVB_BLOCKEND >_ -> Prelude.error "unmarshallCONST_DDWAITVBFLAGS: illegal enum value > " > > > > Unfortunately, if you want to interface to a C function which takes a > combination of flags added together in a specific argument eg (C): > > bar ( DDWAITVB_BLOCKBEGIN + DDWAITVB_BLOCKBEGINEVENT ); > > (Haskell) > > bar (toEnum (fromEnum DDWAITVB_BLOCKBEGIN) + (fromEnum > DDWAITVB_BLOCKBEGINEVENT )) > > the toEnum function can't deal with the comnbination - it generates a > run-time error. > > Is there a simple way to deal with this situation (the need to associate > symbols with specific values, while retaining the ability to lump the values > together in a manner reflecting the underlying C semantics)? > > Should there be another FFI type CEnum? > > Should the Haskell Enum type be operable with +/&/| or whatever? > > Merry Christmas > > Mike Thomas. > ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HDIRECT/FFI - C enums
Hi all. HDirect can generate code as follows: data CONST_DDWAITVBFLAGS = DDWAITVB_BLOCKBEGIN | DDWAITVB_BLOCKBEGINEVENT | DDWAITVB_BLOCKEND instance Prelude.Enum (CONST_DDWAITVBFLAGS) where fromEnum v = case v of DDWAITVB_BLOCKBEGIN -> 1 DDWAITVB_BLOCKBEGINEVENT -> 2 DDWAITVB_BLOCKEND -> 4 toEnum v = case v of 1 -> DDWAITVB_BLOCKBEGIN 2 -> DDWAITVB_BLOCKBEGINEVENT 4 -> DDWAITVB_BLOCKEND _ -> Prelude.error "unmarshallCONST_DDWAITVBFLAGS: illegal enum value " Unfortunately, if you want to interface to a C function which takes a combination of flags added together in a specific argument eg (C): bar ( DDWAITVB_BLOCKBEGIN + DDWAITVB_BLOCKBEGINEVENT ); (Haskell) bar (toEnum (fromEnum DDWAITVB_BLOCKBEGIN) + (fromEnum DDWAITVB_BLOCKBEGINEVENT )) the toEnum function can't deal with the comnbination - it generates a run-time error. Is there a simple way to deal with this situation (the need to associate symbols with specific values, while retaining the ability to lump the values together in a manner reflecting the underlying C semantics)? Should there be another FFI type CEnum? Should the Haskell Enum type be operable with +/&/| or whatever? Merry Christmas Mike Thomas. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
