What is the simplest way to build a Haskell project that uses a C++ library? It needs at least the following from Cabal. - It must know how to compile C++ files. This kind of works by accident if I list those under c-sources since gcc knows what to do with them but this is (a) ugly and (b) doesn't allow me to pass C++-specific options to gcc. - The project must be linked with g++. However, I don't understand how to tell Cabal which linker to use. I got as far as main = defaultMainWithHooks $ defaultUserHooks { hookedPrograms = [Program "ld" (findProgramOnPath "g++") (\_ _ -> return Nothing)] but this doesn't seem to work. configure --with-ld=g++ does, but it's not nice. Is there any simple way of making this work or do I have to use makefiles? Also, is it intentional that Cabal ignores standard environment variables such as CC, CFLAGS etc.? Roman
Hello Roman, Tuesday, February 26, 2008, 11:38:36 AM, you wrote:
What is the simplest way to build a Haskell project that uses a C++ library?
i use the following: ghc.exe --make -lstdc++ main.hs lib.o where lib.cpp is compiled by g++ (of course it's not exactly what you've asked for) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 26 feb 2008, at 09.38, Roman Leshchinskiy wrote:
What is the simplest way to build a Haskell project that uses a C++ library? It needs at least the following from Cabal.
- It must know how to compile C++ files. This kind of works by accident if I list those under c-sources since gcc knows what to do with them but this is (a) ugly and (b) doesn't allow me to pass C++-specific options to gcc.
- The project must be linked with g++. However, I don't understand how to tell Cabal which linker to use. I got as far as
main = defaultMainWithHooks $ defaultUserHooks { hookedPrograms = [Program "ld" (findProgramOnPath "g ++") (\_ _ -> return Nothing)]
but this doesn't seem to work. configure --with-ld=g++ does, but it's not nice.
I don't think you need to link with g++. I successfully linked to a C ++ library by adding -fexceptions to the linker options. I used a makefile, but this should work with Cabal as well.
Is there any simple way of making this work or do I have to use makefiles? Also, is it intentional that Cabal ignores standard environment variables such as CC, CFLAGS etc.?
Roman
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Thomas Schilling wrote:
On 26 feb 2008, at 09.38, Roman Leshchinskiy wrote:
What is the simplest way to build a Haskell project that uses a C++ library? It needs at least the following from Cabal.
- It must know how to compile C++ files. This kind of works by accident if I list those under c-sources since gcc knows what to do with them but this is (a) ugly and (b) doesn't allow me to pass C++-specific options to gcc.
- The project must be linked with g++. However, I don't understand how to tell Cabal which linker to use. I got as far as
main = defaultMainWithHooks $ defaultUserHooks { hookedPrograms = [Program "ld" (findProgramOnPath "g++") (\_ _ -> return Nothing)]
but this doesn't seem to work. configure --with-ld=g++ does, but it's not nice.
I don't think you need to link with g++. I successfully linked to a C++ library by adding -fexceptions to the linker options. I used a makefile, but this should work with Cabal as well.
Constructors for static objects won't get run unless you link with g++ (which, IIRC, uses collect2 for linking). Just adding -fexceptions isn't enough. As a matter of fact, what I'd really want is to use the standard C++ compiler for linking, whatever that is. Roman
On Tue, 2008-02-26 at 19:38 +1100, Roman Leshchinskiy wrote:
What is the simplest way to build a Haskell project that uses a C++ library? It needs at least the following from Cabal.
- It must know how to compile C++ files. This kind of works by accident if I list those under c-sources since gcc knows what to do with them but this is (a) ugly and (b) doesn't allow me to pass C++-specific options to gcc.
That's doable. To do it properly we'd have to add c++-sources and c ++-options fields. There's the question of how many languages we want to add support for in this style.
- The project must be linked with g++. However, I don't understand how to tell Cabal which linker to use.
That's a real pain. This kind of thing is never going to scale. When we want to link in objective C code do we have to link using that compiler? What if we're making a Haskell library rather than a program that needs a C++ lib, do we have to remember that every program that uses that Haskell package has to be linked using g++ rather than gcc? Then it's really easy to get into the situation that different linkers are needed if some program directly or indirectly depends on two packages that want different linkers. It's a big ugly mess. A hack that should work for an executable is: ghc-options: -pgml g++
Also, is it intentional that Cabal ignores standard environment variables such as CC, CFLAGS etc.?
CC yes. CFLAGS not exactly. See: http://hackage.haskell.org/trac/hackage/ticket/221 The reason for ignoring CC is that we use ghc as the C compiler and linker. In future we may switch to using the system C compiler to compile C code in which case we may want to pick up CC. http://hackage.haskell.org/trac/hackage/ticket/229 however we'd still use ghc as the linker. Duncan
Duncan Coutts wrote:
On Tue, 2008-02-26 at 19:38 +1100, Roman Leshchinskiy wrote:
What is the simplest way to build a Haskell project that uses a C++ library? It needs at least the following from Cabal.
- It must know how to compile C++ files. This kind of works by accident if I list those under c-sources since gcc knows what to do with them but this is (a) ugly and (b) doesn't allow me to pass C++-specific options to gcc.
That's doable. To do it properly we'd have to add c++-sources and c ++-options fields. There's the question of how many languages we want to add support for in this style.
I'd vote for none (not even C). Something extensible would be vastly preferable.
- The project must be linked with g++. However, I don't understand how to tell Cabal which linker to use.
That's a real pain. This kind of thing is never going to scale. When we want to link in objective C code do we have to link using that compiler? What if we're making a Haskell library rather than a program that needs a C++ lib, do we have to remember that every program that uses that Haskell package has to be linked using g++ rather than gcc? Then it's really easy to get into the situation that different linkers are needed if some program directly or indirectly depends on two packages that want different linkers. It's a big ugly mess.
I agree wholeheartedly, but it's a mess we have to live with.
A hack that should work for an executable is: ghc-options: -pgml g++
Ok, thanks. Roman
participants (4)
-
Bulat Ziganshin -
Duncan Coutts -
Roman Leshchinskiy -
Thomas Schilling