Segmentation fault when running hs_init(0, 0) for ffi - haskell

I am trying to call Haskell functions from python.
I have the following make file:
GHC=ghc
GHC_RUNTIME_LINKER_FLAG=-lHSrts-ghc7.4.1
libffi-example.so: Example.o wrapper.o
$(GHC) -o $# -shared -dynamic -fPIC $^ $(GHC_RUNTIME_LINKER_FLAG)
Example_stub.h Example.o: Example.hs
$(GHC) -c -dynamic -fPIC Example.hs
wrapper.o: wrapper.c Example_stub.h
$(GHC) -c -dynamic -fPIC wrapper.c
clean:
rm -f *.hi *.o *_stub.[ch]
clean-all:
rm -f *.hi *.o *_stub.[ch] *.so
# Runs the example Python program
example: libffi-example.so
python program.py
The only thing wrapper.c does it creating wrappers for hs_init by calling hs_init(0,0);. The wrapper is called example_init
I get a segmentation fault when running make example, in example_init (ie when calling hs_init(0,0)).
Can someone tell me why this is and/or how to fix it?
Thanks!

It ought to work:
"Moreover, hs_init() may be called with NULL for both argc and argv, signalling the absence of command line arguments."
It seems to be a bug in ghc-7.2.1 to ghc-7.4.1:
RFib.hs:
{-# LANGUAGE ForeignFunctionInterface #-}
module RFib where
fib :: Int -> Int
fib n
| n >= 0 = go 0 1 n
| even n = -go 0 1 (-n)
| otherwise = go 0 1 (-n)
where
go a _ 0 = a
go a b k = go b (a+b) (k-1)
foreign export ccall "rfib" fib :: Int -> Int
rfib.c:
#include <stdio.h>
#include <HsFFI.h>
int rfib(int);
int main(void) {
hs_init(0,0);
printf("%d\n", rfib(35));
hs_exit();
return 0;
}
Compile and run:
$ rm rfib.o RFib.hi RFib.o a.out
$ ghc-7.0.2 -O2 -Wall -no-hs-main RFib.hs rfib.c && ./a.out
[1 of 1] Compiling RFib ( RFib.hs, RFib.o )
Linking a.out ...
9227465
$ rm rfib.o RFib.hi RFib.o a.out
$ ghc-7.0.4 -O2 -Wall -no-hs-main RFib.hs rfib.c && ./a.out
[1 of 1] Compiling RFib ( RFib.hs, RFib.o )
Linking a.out ...
9227465
$ rm rfib.o RFib.hi RFib.o a.out
$ ghc-7.2.1 -O2 -Wall -no-hs-main RFib.hs rfib.c && ./a.out
[1 of 1] Compiling RFib ( RFib.hs, RFib.o )
Linking a.out ...
Speicherzugriffsfehler
$ rm rfib.o RFib.hi RFib.o a.out
$ ghc-7.2.2 -O2 -Wall -no-hs-main RFib.hs rfib.c && ./a.out
[1 of 1] Compiling RFib ( RFib.hs, RFib.o )
Linking a.out ...
Speicherzugriffsfehler
$ rm rfib.o RFib.hi RFib.o a.out
$ ghc-7.4.1 -O2 -Wall -no-hs-main RFib.hs rfib.c && ./a.out
[1 of 1] Compiling RFib ( RFib.hs, RFib.o )
Linking a.out ...
Speicherzugriffsfehler
$ rm rfib.o RFib.hi RFib.o a.out
$ ghc-7.4.2 -O2 -Wall -no-hs-main RFib.hs rfib.c && ./a.out
[1 of 1] Compiling RFib ( RFib.hs, RFib.o )
Linking a.out ...
9227465
$ rm rfib.o RFib.hi RFib.o a.out
$ ghc -O2 -Wall -no-hs-main RFib.hs rfib.c && ./a.out
[1 of 1] Compiling RFib ( RFib.hs, RFib.o )
Linking a.out ...
9227465
Changing two lines in rfib.c:
int main(int argc, char *argv[]) {
hs_init(&argc,&argv);
it works with all versions (>= 7.0 that I have installed).
So to fix it
pass &argc and &argv
upgrade GHC
are the two most obvious ways.

Related

__attribute__ ((weak)) not work for global variable

pqy#localhost ~/src/test/a $ cat m.c
#include <stdio.h>
int aaaaa __attribute__ ((weak)) =8;
int main(void){
printf("%d\n", aaaaa);
return 0;
}
pqy#localhost ~/src/test/a $ cat lib.c
int aaaaa = 5;
pqy#localhost ~/src/test/a $ gcc lib.c -fPIC -shared -o libb.so;gcc m.c -o m -L. -lb -Wl,-rpath=$PWD;./m
8
Above is my code and test result. I am confused why it does not work as expected.
Also try function, not work ether. Below is the test result.
pqy#localhost ~/src/test/a $ cat lib.c
int fun() {
return 5;
}
pqy#localhost ~/src/test/a $ cat m.c
#include <stdio.h>
__attribute__((weak)) int fun() {
return 8;
}
int main(void){
printf("%d\n", fun());
return 0;
}
pqy#localhost ~/src/test/a $ gcc lib.c -fPIC -shared -o libb.so;gcc m.c -O0 -o m -L. -lb -Wl,-rpath=$PWD;./m
8
pqy#localhost ~/src/test/a $ ldd m
linux-vdso.so.1 (0x00007ffd819ec000)
libb.so => /home/pqy/src/test/a/libb.so (0x00007f7226738000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7226533000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7226744000)
pqy#localhost ~/src/test/a $
At bottom what you have observed here is just the fact that the linker will not
resolve a symbol dynamically if it can resolve it statically. See:
main.c
extern void foo(void);
extern void need_dynamic_foo(void);
extern void need_static_foo(void);
int main(void){
foo();
need_dynamic_foo();
need_static_foo();
return 0;
}
dynamic_foo.c
#include <stdio.h>
void foo(void)
{
puts("foo (dynamic)");
}
void need_dynamic_foo(void)
{
puts(__func__);
}
static_foo.c
#include <stdio.h>
void foo(void)
{
puts("foo (static)");
}
void need_static_foo(void)
{
puts(__func__);
}
Compile the sources so:
$ gcc -Wall -c main.c static_foo.c
$ gcc -Wall -fPIC -c dynamic_foo.c
Make a shared library:
$ gcc -shared -o libfoo.so dynamic_foo.o
And link a program:
$ gcc -o prog main.o static_foo.o libfoo.so -Wl,-rpath=$PWD
It runs like:
$ ./prog
foo (static)
need_dynamic_foo
need_static_foo
So foo and need_static_foo were statically resolved to the definitions from static_foo.o and
the definition of foo from libfoo.so was ignored, despite the fact that libfoo.so
was needed and provided the definition of need_dynamic_foo. It makes no difference
if we change the linkage order to:
$ gcc -o prog main.o libfoo.so static_foo.o -Wl,-rpath=$PWD
$ ./prog
foo (static)
need_dynamic_foo
need_static_foo
It also makes no difference if we replace static_foo.c with:
static_weak_foo.c
#include <stdio.h>
void __attribute__((weak)) foo(void)
{
puts("foo (static weak)");
}
void need_static_foo(void)
{
puts(__func__);
}
Compile that and relink:
$ gcc -Wall -c static_weak_foo.c
$ gcc -o prog main.o libfoo.so static_weak_foo.o -Wl,-rpath=$PWD
$ ./prog
foo (static weak)
need_dynamic_foo
need_static_foo
Although the definition of foo in static_weak_foo.c is now declared weak,
the fact that foo can be statically resolved to this definition
still preempts any need to resolve it dynamically.
Now if we write another source file containing another strong definition of
foo:
static_strong_foo.c
#include <stdio.h>
void foo(void)
{
puts("foo (static strong)");
}
and compile it and link as follows:
$ gcc -Wall -c static_strong_foo.c
$ gcc -o prog main.o static_weak_foo.o libfoo.so static_strong_foo.o -Wl,-rpath=$PWD
we see:
$ ./prog
foo (static strong)
need_dynamic_foo
need_static_foo
Now, libfoo.so still provides the definition of need_dynamic_foo, because there
is no other; static_weak_foo.o still provides the only definition of need_static_foo,
and the definition of foo in libfoo.so is still ignored because the symbol
can be statically resolved.
But in this case there are two definitions of foo in different files that are
available to resolve it statically: the weak definition in static_weak_foo.o and
the strong definition in static_strong_foo.o. By the linkage rules that you are
familiar with, the strong definition wins.
If both of these statically linked definitions of foo were strong, there would of course be a
multiple definition error, just like:
$ gcc -o prog main.o static_foo.o libfoo.so static_strong_foo.o -Wl,-rpath=$PWD
static_strong_foo.o: In function `foo':
static_strong_foo.c:(.text+0x0): multiple definition of `foo'
static_foo.o:static_foo.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
in which the dynamic definition in libfoo.so plays no part. So you can
be guided by this practical principle: The rules you are familiar with for arbitrating
between weak and strong definitions of the same symbol in a linkage only apply
to rival definitions which would provoke a multiple definition error in the absence
of the weak attribute.
The symbol is resolved at link stage, during the link stage only the weak symbol aaaaa = 8 is visible.
If the symbol can be resolved in the link stage, it won't generate a relocation entry, then nothing will happen at load stage
There are no aaaaa in the relocation table:
% objdump -R m
m: file format elf64-x86-64
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
0000000000003dc8 R_X86_64_RELATIVE *ABS*+0x0000000000001130
0000000000003dd0 R_X86_64_RELATIVE *ABS*+0x00000000000010f0
0000000000004028 R_X86_64_RELATIVE *ABS*+0x0000000000004028
0000000000003fd8 R_X86_64_GLOB_DAT _ITM_deregisterTMCloneTable
0000000000003fe0 R_X86_64_GLOB_DAT __libc_start_main#GLIBC_2.2.5
0000000000003fe8 R_X86_64_GLOB_DAT __gmon_start__
0000000000003ff0 R_X86_64_GLOB_DAT _ITM_registerTMCloneTable
0000000000003ff8 R_X86_64_GLOB_DAT __cxa_finalize#GLIBC_2.2.5
0000000000004018 R_X86_64_JUMP_SLOT printf#GLIBC_2.2.5
Сompiler or linker builds files from the command line in reverse order. In other words, files with ((weak)) should be located earlier in the command line than dynamic ones.

Is there any gcc/g++ linker flag than removes the hidden visibility from symbols of a shared library

I went through this The hidden visibility does get applied in my shared libraries but works for static libraries on linux
and
Is there any way to override the -fvisibility=hidden at link time?
but I have follow up question
File: lib_mylib.h
int fun();
int fun1(void);
int fun2(void);
File: lib_mylib.c
#include <stdio.h>
int fun() {
return 2;
}
int fun1(void) {
return 2;
}
int fun2(void) {
return 2;
}
File: my_lib_shared.c
#include "my_lib.h"
int foo(void) {
return fun() + 4;
}
File: my_lib_shared.h
int foo();
File driver.c
/* filename: driver.c */
#include "my_lib.h"
#include "my_lib_shared.h"
#include <stdio.h>
int main() {
int x = foo() ;
return 0;
}
If I execute following steps
1) `gcc -fPIC -fvisibility=hidden -c my_lib.c -o lib_mylib.o`
2) `gcc -fPIC -fvisibility=hidden -shared -o libMyLibHidden.so lib_mylib.o`
3) `gcc -fPIC -c my_lib_shared.c -o my_lib_shared.o`
4) `gcc -shared -o libMyShared2.so my_lib_shared.o`
5) `gcc -L. -Wall -o test_hidden driver.c -lMyLibHidden -lMyShared2`
the output of objdump is as
objdump -T libMyLibHidden.so
libMyLibHidden.so: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000448 l d .init 0000000000000000 .init
0000000000000000 w D *UND* 0000000000000000 __gmon_start__
0000000000000000 w D *UND* 0000000000000000 _Jv_RegisterClasses
0000000000000658 g DF .fini 0000000000000000 Base _fini
0000000000000000 w D *UND* 0000000000000000 _deregisterTMCloneTable
0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable
0000000000000000 w DF *UND* 0000000000000126 GLIBC_2.2.5 _cxa_finalize
0000000000200938 g D *ABS* 0000000000000000 Base __bss_start
0000000000200948 g D *ABS* 0000000000000000 Base _end
0000000000200938 g D *ABS* 0000000000000000 Base _edata
0000000000000448 g DF .init 0000000000000000 Base _init
I did not any reference of functions of fun, fun1 and fun2 in the above objdump. Which is expected
and I get following error at final linking step
/tmp/ccMsEpFq.o: In function main':
driver.c:(.text+0xe): undefined reference tofun' collect2: error: ld returned 1 exit status
but in my actual code and shared libraries of libQtGui.so i can see in my Makefile -fvisibility=hidden is given as flag but still the symbols are available in my dynamic symbol table of libQtGui.so
=--------------------------------My question
is is there any flag in gcc linux or way where we can override the hidden visibility and make the symbols available in shared libraries
or there any flag in gcc linux where we can export all the symbols in the shared library
The flags of my Makefile while making shared library of libQtGui.so are
CFLAGS = -m64 -pipe -g -O2 -fvisibility=hidden -Wall -W -D_REENTRANT -fPIC $(DEFINES)
CXXFLAGS = -m64 -pipe -fpermissive -g -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC $(DEFINES)
INCPATH = -I../../mkspecs/linux-g++-64 -I. -I../../include/QtCore -I../../include/QtCore -I../../include -I../../include/QtGui -I../3rdparty/libpng -I../3rdparty/zlib -I/usr/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/release-shared -I/usr/X11R6/include -I.uic/release-shared
LINK = g++
LFLAGS = -m64 -Wl,-rpath/shared_libary_path -shared -Wl,-soname,libQtGui.so.4
Just remove the -fvisibility=hidden flag and all functions will be exported.

dylib dynamic library calling a dylib : Undefined symbols for architecture i386

Under mac os x with g++ from gcc-5.2 I am trying to do the following : create a dylib exporting a class defined by header tmp8bis_dylib.h and source tmp8bis_dylib.cpp, and then create another dylib out of a source file tmp8bis.cpp using and linking to the previous dylib. Header and sources are in the same directory. I compile as follows :
g++-5.2.0 -m32 -Wall -g -c ./tmp8bis_dylib.cpp
g++-5.2.0 -m32 -dynamiclib ./tmp8bis_dylib.o -o ./tmp8bis_dylib.dylib
g++-5.2.0 -m32 -Wall -g -c ./tmp8bis.cpp
g++-5.2.0 -m32 -dynamiclib ./tmp8bis.o -o ./tmp8bis.dylib
and get this :
Undefined symbols for architecture i386:
"complex::cmodule(double, double)", referenced from:
_mymodule in tmp8bis.o
"complex::complex(double, double)", referenced from:
_mymodule in tmp8bis.o
"complex::~complex()", referenced from:
_mymodule in tmp8bis.o
ld: symbol(s) not found for architecture i386
collect2: error: ld returned 1 exit status
make: *** [all] Error 1
Obviously, I tried to pass various include and library paths with -I and -L flags respectively, with the very same result... Any idea ?
Files are below :
For tmp8bis_dylib.h :
#ifndef TMP_8_BIS_DYLIB_H
#define TMP_8_BIS_DYLIB_H
class complex
{
public:
double real;
double imag;
public:
complex();
complex(double x);
complex(double x,double y);
double cmodule(double x, double y);
~complex();
};
#endif
For tmp8bis_dylib.cpp :
#include "./tmp8bis_dylib.h"
#include <math.h>
extern "C"
{
complex::complex()
{
real = 0.0 ;
imag = 0.0 ;
}
complex::complex(double x)
{
real = x ;
imag = 0.0 ;
}
complex::complex(double x,double y)
{
real = x ;
imag = y ;
}
double complex::cmodule(double x, double y)
{
double res = sqrt(x*x+y*y);
return res ;
}
complex::~complex()
{
}
}
For tmp8bis.cpp :
#include <math.h>
#include "./tmp8bis_dylib.h"
extern "C"
{
double mymodule(double x, double y)
{
complex z(x,y);
double ret = z.cmodule(x,y);
return ret;
}
}
Precision. -m32 is because I need 32 bits dylib because the final dylib will be plugged into excel 2011's (for mac) VBA, which is 32 bits.
EDIT. Following Brett Hale's comment about Apple's advises about dylibs, I added
#define EXPORT __attribute__((visibility("default")))
after the #include's from tmp8bis.cpp, and EXPORT's for all its member functions, and compiled as follows :
g++-5.2.0 -m32 -Wall -g -c ./tmp8bis_dylib.cpp
g++-5.2.0 -m32 -dynamiclib ./tmp8bis_dylib.o -fvisibility=hidden -o ./tmp8bis_dylib.dylib
did a sudo cp ./tmp8bis_dylib.dylib /opt/lib/libtmp8bis_dylib.dylib and then compiled :
g++-5.2.0 -m32 -Wall -g -c ./tmp8bis.cpp
g++-5.2.0 -m32 -dynamiclib ./tmp8bis.o -o ./tmp8bis.dylib -L/opt/lib
and got the same result as before... Nor did
g++-5.2.0 -m32 -dynamiclib ./tmp8bis.o -o ./tmp8bis.dylib -ltmp8bis_dylib.dylib
make my day.
Without resorting to #define EXPORT __attribute__((visibility("default"))) or any -fvisibility=hidden
g++-5.2.0 -m32 -Wall -fpic -g -c ./tmp8bis_dylib.cpp
g++-5.2.0 -m32 -shared ./tmp8bis_dylib.o -o ./libtmp8bis_dylib.dylib
g++-5.2.0 -m32 -Wall -g -c ./tmp8bis.cpp
g++-5.2.0 -m32 -shared ./tmp8bis.o -o ./tmp8bis.dylib -L. -ltmp8bis_dylib
finally worked. I did not managed to succeed without -fpic, naming libtmp8bis_dylib.dylib and using -ltmp8bis_dylib.

How to include SDL in your program (Linux). undefined reference to SDL_Init()

Im trying everything to run this test Program and keep getting this error messages:
g++ objects/src_files/display.o objects/src_files/main.o -o program -L/usr/local/lib
objects/src_files/main.o: In function `main':
main.cpp:(.text+0x16): undefined reference to `SDL_Init'
collect2: error: ld returned 1 exit status
make: *** [program] Error 1
this is how my test program looks like:
#include <iostream>
#include <string>
#include <GL/glew.h>
#include <SDL2/SDL.h>
#include <glm/glm.hpp>
#include <display.hpp>
using namespace std;
int main(int argc, char **argv)
{
SDL_Init(SDL_INIT_EVERYTHING);
glm::vec3 my_v(0, 0, 0);
string s = "This is a Test";
cout << s << endl;
return 0;
}
and this is my MAKEFILE:
APP = program
CC = g++
SRCDIR = src_files
OBJDIR = objects
H_DIR = header_files
INC_DIR = include
LIB_DIR = /usr/local/lib
SRCS := $(shell find $(SRCDIR) -name '*.cpp')
SRCDIRS := $(shell find . -name '*.cpp' -exec dirname {} \; | uniq)
OBJS := $(patsubst %.cpp,$(OBJDIR)/%.o,$(SRCS))
CFLAGS = -Wall -pedantic -ansi -lSDL
LDFLAGS =
#update here
_H = $(HD_DIR)/display.hpp
SDL_H = $(INC_DIR)/SDL.h
MAIN_H = $(_H) $(SDL_H)
all: $(APP)
$(APP) : buildrepo $(OBJS)
$(CC) $(OBJS) $(LDFLAGS) -o $#
$(OBJDIR)/%.o: %.cpp
$(CC) $(CFLAGS) -I$(INC_DIR) -I$(H_DIR) -c $< -o $#
#update here
$(OBJ_DIR)/main.o: $(MAIN_H)
$(OBJ_DIR)/display.o: $(_H) $(SDL_H)
clean:
$(RM) $(OBJS)
distclean: clean
$(RM) $(APP)
buildrepo:
#$(call make-repo)
define make-repo
for dir in $(SRCDIRS); \
do \
mkdir -p $(OBJDIR)/$$dir; \
done
endef
I run the MAKEFILE with: make -f MAKEFILE
What else can I try?
Thanks
In your Makefile change
CFLAGS = -Wall -pedantic -ansi -lSDL
LDFLAGS =
To
CFLAGS = -Wall -pedantic -ansi
LDFLAGS = -lSDL
-lSDL is actually a linker flag, not compiler.

Compiling wmii on Fedora 15 x86_64

I'm having trouble compiling wmii v3.9.2 on Fedora 15; Here's the interesting part (things break down at the linking stage):
% bmake -de
MAKE all libbio/
MAKE all libfmt/
MAKE all libregexp/
MAKE all libutf/
MAKE all libixp/
MAKE all doc/
MAKE all man/
MAKE all cmd/
MAKE all cmd/wmii/
MAKE all cmd/menu/
LD cmd/wmii9menu.out
/usr/bin/ld: wmii/xext.o: undefined reference to symbol 'XRenderFindVisualFormat'
/usr/bin/ld: note: 'XRenderFindVisualFormat' is defined in DSO /usr/lib64/libXrender.so.1 so try adding it to the linker command line
/usr/lib64/libXrender.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
*** Failed target: wmii9menu.out
*** Failed command: ../util/link "cc" "$(pkg-config --libs 2>/dev/null) -g -L../lib -L/usr/lib64 ../lib/libregexp9.a ../lib/libbio.a ../lib/libfmt.a ../lib/libutf.a -L../lib -L/usr/lib64 ../lib/libregexp9.a ../lib/libbio.a ../lib/libfmt.a ../lib/libutf.a" wmii9menu.out wmii9menu.o clientutil.o wmii/x11.o wmii/xext.o wmii/geom.o wmii/map.o util.o ../lib/libixp.a $(pkg-config --libs xft xrandr xinerama) -lXext
*** Error code 1
Stop.
bmake: stopped in /srv/redhat/BUILD/wmii+ixp-3.9.2/cmd
*** Failed target: dall
*** Failed command: dirs="libbio libfmt libregexp libutf libixp doc man cmd libwmii_hack rc alternative_wmiircs"; set -e; targ=dall; targ=${targ#d}; for i in $dirs; do export WMII_HGVERSION=""; export BASE=$i/; if [ ! -d $i ]; then echo Skipping nonexistent directory: $i 1>&2; else echo MAKE $targ $BASE; (cd $i && bmake $targ) || exit ; fi; done
*** Error code 1
Stop.
bmake: stopped in /srv/redhat/BUILD/wmii+ixp-3.9.2
Finally, in config.mk, I have the following settings:
...
INCLUDES = -I. -I$(ROOT)/include -I$(INCLUDE) -I/usr/include
LIBS = -L$(ROOT)/lib -L/usr/lib64
...
LDFLAGS += -g $(LIBS)
SOLDFLAGS += $(LDFLAGS)
SHARED = -shared -Wl,-soname=$(SONAME)
STATIC = -static
...
With a little more manual resolution, the statement generating the error is essentially as follows:
gcc \
-o wmii9menu.out\
-L../lib -L/usr/lib $(pkg-config --libs xft xrandr xinerama xext)\
../lib/libregexp9.a ../lib/libbio.a ../lib/libfmt.a\
../lib/libutf.a ../lib/libixp.a\
wmii9menu.o clientutil.o util.o\
wmii/x11.o wmii/xext.o wmii/geom.o wmii/map.o
Here, the pkg-config resolves to the following, which by itself is perfectly correct:
-lXft -lXrandr -lXinerama -lXext
And the solution is as follows:
--- wmii+ixp-3.9.2/config.mk 2011-06-03 14:03:22.950163074 +1000
+++ wmii+ixp-3.9.2/config.mk 2011-06-03 14:03:16.086129011 +1000
## -32 +32 ##
-X11PACKAGES = xft
+X11PACKAGES = xft xext xrandr xrender xinerama

Resources