I'm learning how to make C++ call haskell code from a library, I was following instructions from FFI complete examples http://www.haskell.org/haskellwiki/FFI_complete_examples
however, after
ghc -v Foo.hs
only Foo_stub.h and Foo.o are created, there's no Foo_stub.c or Foo_stub.o. According to Calling Haskell from C, ghc > 7.2 doesn't generate _stub.o anymore.
In this case do I still need a stub.o to link an executable using g++?
At the moment after
g++ -o test Foo.o test.o `cat link_options`
I get lots of undefined symbols errors for hs_init and the like. Is it because _stub.o is not present or something else missing?
I can link them correctly using ghc:
ghc -no-hs-main -o test test.o Foo.o -lstdc++
(after reading this question:Building a dynamic library with haskell and using it from C++)
but I wonder is it still possible to link using g++?
You're looking at an out-of-date example (it's using ghc 6.12.3). This example works for 7.6.3:
http://www.haskell.org/haskellwiki/GHC/Using_the_FFI
Related
The fortran compiler catches a lot of my stupid mistakes like providing the wrong number of arguments, or some argument that has the wrong type.
However, I use LAPACK and BLAS a lot, and when I make those mistakes when calling their subroutines, gfortran happily compiles it for me, resulting in errors that are hard to debug.
Is there a way to have gfortran check the calls to those shared libraries for me?
I compile using the following commands
gfortran -o foo.o -c foo.f
gfortran -o bar bar.f foo.o -lblas -llapack
What I am trying to do is to have a dynamic library (lib_utils.so) that links libstdc++ statically and includes also other utility functions (created by me).
Then I want other binaries to use this library instead of libstdc++.
Seems stupid but I cannot deploy both lib_utils.so and libstdc++.so.6 to my customers and I try to combine them into one single library. I also want to avoid static linking with libstdc++ because I have 5 binaries that need libstdc++.
Is this possible?
Thank you
I managed to do it:
g++ -std=c++14 -Wl,-whole-archive /usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a -Wl,-no-whole-archive -shared -fPIC lib.cpp -o libviata.so
Then I loaded this library into a simple app and this app does not require libstdc++ anymore, cause it loads my custom library (which is quite big now, 2.1MB)
g++ -std=c++14 test.cpp -o test -L/home/tawfic/Desktop/test -lviata && ldd test
I have a requirement of creating a C++ program which exposes certain functions through HTTP. For that reason I was trying to use libmicrohttpd for the same. Now this library is written in C. However I am kind of new to C++ and am trying to compile this C and C++ code given here. (Which can be git cloned from here)
Now I need help in understanding how g++ may be used to compile a program which is not written completely in C++. And/or how to compile the above linked code.
PS: Working in linux
And finally if someone can point to an easier alternative than libmicrohttpd - I am all ears.
Edit to Edit:
Finally got it working. Compiled the individual cpp files with gcc and then linked everything using g++. I have no clue how this came to work, maybe some one can reply below.
I have made the following script to compile and link:
LOC="path/to/directory"
gcc -c httphandler.cpp -o httphandler.o -I $LOC
gcc -c strutil.cpp -o strutil.o -I $LOC
gcc -c api.cpp -o api.o -I $LOC
gcc -c executor.cpp -o executor.o -I $LOC
g++ -o out httphandler.o strutil.o api.o executor.o -lmicrohttpd -lboost_regex
But in the final step I am getting the following error:
/usr/bin/ld: strutil.o: undefined reference to symbol '__cxa_free_exception##CXXABI_1.3'
/usr/bin/ld: note: '__cxa_free_exception##CXXABI_1.3' is defined in DSO /usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid operation
What gives?
For starters, don't compile the C code with g++, use gcc instead. Then just include the header file and use the functions normally. When linking don't forget to link with the object file(s) generated from compiling the libmicrohttpd source file(s).
HI all
I am trying to use SWIG to export C++ code to Python.
The C sample I read on the web site does work but I have problem with C++ code.
Here are the lines I call
swig -c++ -python SWIG_TEST.i
g++ -c -fPIC SWIG_TEST.cpp SWIG_TEST_wrap.cxx -I/usr/include/python2.4/
gcc --shared SWIG_TEST.o SWIG_TEST_wrap.o -o _SWIG_TEST.so -lstdc++
When I am finished I receive the following error message
ImportError: ./_SWIG_TEST.so: undefined symbol: Py_InitModule4
Do you know what it is?
It looks like you aren't linking to the Python runtime library. Something like adding -lpython24 to your gcc line. (I don't have a Linux system handy at the moment).
you might try building the shared library using gcc
g++ -shared SWIG_TEST.o SWIG_TEST_wrap.o -o _SWIG_TEST.so
rather than using ld directly.
As Mark said, it's a problem linking to the python library. A nice way to get hints as to just which flags you need to successfully link can be gotten by running python-config --ldflags. In fact, a particularly painless way of compiling your test is the following:
swig -c++ -python SWIG_TEST.i
g++ -c `python-config --cflags` -fPIC SWIG_TEST.cpp SWIG_TEST_wrap.cxx
gcc --shared `python-config --ldflags` SWIG_TEST.o SWIG_TEST_wrap.o -o _SWIG_TEST.so -lstdc++
Note that python-config isn't perfect; it sometimes gives you extra things, or conflicting things. But this should certainly help a lot.
I have a C++ library and a C++ application trying to use functions and classes exported from the library. The library builds fine and the application compiles but fails to link. The errors I get follow this form:
app-source-file.cpp:(.text+0x2fdb): undefined reference to `lib-namespace::GetStatusStr(int)'
Classes in the library seem to be resolved just fine by the linker, but free functions and exported data (like a cosine lookup table) invariably result in the above error.
I am using Ubuntu 8.04 (Hardy), and it is up to date with the latest Ubuntu packages.
The command to link the library is (with other libraries removed):
g++ -fPIC -Wall -O3 -shared -Wl,-soname,lib-in-question.so -o ~/project/lib/release/lib-in-question.so
The command to link the application is (with other libraries removed):
g++ -fPIC -Wall -O3 -L~/project/lib/release -llib-in-question -o ~/project/release/app-in-question
Finally, it appears (as best as I can tell) that the symbols in question are being exported properly:
nm -D ~/project/lib/release/lib-in-question.so | grep GetStatusStr --> U _ZN3lib-namespace12GetStatusStrEi
the U before _ZN3lib-namespace12GetStatusStrEi in the nm output shows that the symbol is undefined in the library.
Maybe it's defined in the wrong namespace: it looks like you're calling it in lib-namepace but you might be defining it in another.
It's been a while, but if you specify a lib with the -l option, then don't you have the skip the lib prefix?
(I changed the name from "lib-in-question.so" to "libfoobar.so" for easier reading for the example below)
g++ -fPIC -Wall -O3 -L~/project/lib/release -lfoobar
or
g++ -fPIC -Wall -O3 ~/project/lib/release/libfoobar.so