www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - undefined symbol: rt_finalize

reply "Tolga Cakiroglu" <tcak pcak.com> writes:
I am trying to compile a shared library on Linux and use it.

lib.d
---------------------------
import core.runtime;

class A{}

extern(C) void foo(){
	Object obj = new Object();

	A objA = new A();

	char[] c = new char[ 1024 ];

	destroy( objA );
	destroy( c );
}


makefile:
--------------------------
lib:
	dmd -c lib.d -fPIC -debug -gc -g -w -wi
	gcc --shared lib.o -o lib.so


After getting the `foo` symbol in the app by using dlsym, I call 
it, the following is output on the shell:

library is loaded now
Running functions...
./app: symbol lookup error: ./lib.so: undefined symbol: 
rt_finalize


Where exactly is that function linked into an application? and 
why is it not linked into the library? Does it require an extra 
flag?
Feb 26 2014
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Thursday, 27 February 2014 at 06:25:45 UTC, Tolga Cakiroglu 
wrote:

 I am trying to compile a shared library on Linux and use it.

 lib.d
 ---------------------------
 import core.runtime;

 class A{}

 extern(C) void foo(){
 	Object obj = new Object();

 	A objA = new A();

 	char[] c = new char[ 1024 ];

 	destroy( objA );
 	destroy( c );
 }


 makefile:
 --------------------------
 lib:
 	dmd -c lib.d -fPIC -debug -gc -g -w -wi
 	gcc --shared lib.o -o lib.so


 After getting the `foo` symbol in the app by using dlsym, I 
 call it, the following is output on the shell:

 library is loaded now
 Running functions...
 ./app: symbol lookup error: ./lib.so: undefined symbol: 
 rt_finalize


 Where exactly is that function linked into an application? and 
 why is it not linked into the library? Does it require an extra 
 flag?


because there is no finalize. rt_init/rt_term is what you need

https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L30
Feb 27 2014
parent reply "Tolga Cakiroglu" <tcak pcak.com> writes:
 because there is no finalize. rt_init/rt_term is what you need

 https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L30


I looked at the `/usr/include/dmd/druntime` folder with `grep 
finalize -r`, and it brought me only one file, that is 
`object.di`.

When I check `object.di`, I see that rt_finalize is defined as 
`extern(C)` and it is called in `destroy` function. Thereby, it 
is defined by the DMD itself. So, there is a `finalize`, but even 
I am not doing anything special in the code, it is not finding it 
while having it in a normal programme.
Feb 27 2014
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Friday, 28 February 2014 at 05:41:04 UTC, Tolga Cakiroglu 
wrote:

 because there is no finalize. rt_init/rt_term is what you need

 https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L30


 I looked at the `/usr/include/dmd/druntime` folder with `grep 
 finalize -r`, and it brought me only one file, that is 
 `object.di`.

 When I check `object.di`, I see that rt_finalize is defined as 
 `extern(C)` and it is called in `destroy` function. Thereby, it 
 is defined by the DMD itself. So, there is a `finalize`, but 
 even I am not doing anything special in the code, it is not 
 finding it while having it in a normal programme.


that finalize i guess is for finalizing objects. but destroy 
itself is deprecated. use clear() to do this instead.
Feb 27 2014
next sibling parent reply "Mike" <none none.com> writes:
On Friday, 28 February 2014 at 05:46:03 UTC, evilrat wrote:

 that finalize i guess is for finalizing objects. but destroy 
 itself is deprecated. use clear() to do this instead.


I believe delete() and clear() are deprecated and destroy() is 
the correct method.  I recently read it somewhere, I'll try to 
find it.
Feb 27 2014
parent reply "Mike" <none none.com> writes:
On Friday, 28 February 2014 at 05:59:23 UTC, Mike wrote:

 On Friday, 28 February 2014 at 05:46:03 UTC, evilrat wrote:

 that finalize i guess is for finalizing objects. but destroy 
 itself is deprecated. use clear() to do this instead.


 I believe delete() and clear() are deprecated and destroy() is 
 the correct method.  I recently read it somewhere, I'll try to 
 find it.


Here it is:  
https://github.com/D-Programming-Language/dlang.org/pull/156
Feb 27 2014
parent "Tolga Cakiroglu" <tcak pcak.com> writes:
On Friday, 28 February 2014 at 06:02:30 UTC, Mike wrote:

 On Friday, 28 February 2014 at 05:59:23 UTC, Mike wrote:

 On Friday, 28 February 2014 at 05:46:03 UTC, evilrat wrote:

 that finalize i guess is for finalizing objects. but destroy 
 itself is deprecated. use clear() to do this instead.


 I believe delete() and clear() are deprecated and destroy() is 
 the correct method.  I recently read it somewhere, I'll try to 
 find it.


 Here it is:  
 https://github.com/D-Programming-Language/dlang.org/pull/156


It doesn't matter. `free`, `destroy`, `clear`. All of them are 
same. The only successful result I have found was to define 
`extern(C) rt_finalize2` and use it instead of destroy. It works 
with it, but this doesn't seem like the correct behaviour.
Feb 27 2014
prev sibling parent "Tolga Cakiroglu" <tcak pcak.com> writes:
 that finalize i guess is for finalizing objects. but destroy 
 itself is deprecated. use clear() to do this instead.


Nope. No chance. I have removed all imports. All `destroy`s are 
replaced with `clean`, and still same. I have deleted all 
executables and compiled again and again.

./app: symbol lookup error: ./lib.so: undefined symbol: 
rt_finalize


I thought maybe it is not about the library but the program. But 
when I DO NOT call that "foo" function, no error is seen. That 
means that piece of code is making this.

I have shared codes and makefile on Publink.


If you are on Linux and won't bother you, can you test it please.
Feb 27 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Thursday, 27 February 2014 at 06:25:45 UTC, Tolga Cakiroglu 
wrote:

 I am trying to compile a shared library on Linux and use it.

 lib.d
 ---------------------------
 import core.runtime;

 class A{}

 extern(C) void foo(){
 	Object obj = new Object();

 	A objA = new A();

 	char[] c = new char[ 1024 ];

 	destroy( objA );
 	destroy( c );
 }


 makefile:
 --------------------------
 lib:
 	dmd -c lib.d -fPIC -debug -gc -g -w -wi
 	gcc --shared lib.o -o lib.so


 After getting the `foo` symbol in the app by using dlsym, I 
 call it, the following is output on the shell:

 library is loaded now
 Running functions...
 ./app: symbol lookup error: ./lib.so: undefined symbol: 
 rt_finalize


 Where exactly is that function linked into an application? and 
 why is it not linked into the library? Does it require an extra 
 flag?


rt_finalize is defined in lifetime.d 
(https://github.com/D-Programming-Language/druntime/blob/master
src/rt/lifetime.d). 
  Its part of the D runtime.  It just forwards to rt_finalize2.

I don't know why you are getting an undefined symbol, though.  Is 
the signature different?
Feb 27 2014
parent reply "Tolga Cakiroglu" <tcak pcak.com> writes:
 rt_finalize is defined in lifetime.d 
 (https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d).
  Its part of the D runtime.  It just forwards to rt_finalize2.

 I don't know why you are getting an undefined symbol, though.  
 Is the signature different?


I made some changes in code and culled a big part of it. Now the 
new error is:

./app: symbol lookup error: ./lib.so: undefined symbol: 
_d_newarrayiT


The exact codes are below:

app.d
------------------------------------
import core.sys.posix.dlfcn;

void main(){
	void *lh = dlopen("./lib.so", RTLD_LAZY);
	void function() foo = cast(void function())( dlsym( lh, "foo" ) 
);
	foo();
}


lib.d
------------------------------------
class A{}

extern(C) void foo(){
	Object obj = new Object();

	A objA = new A();

	char[] c = new char[ 1024 ];

	clear( objA );
	clear( obj );
	clear( c );
}


makefile
------------------------------------
all: clean lib app

lib:
	dmd -c lib.d -fPIC -debug -gc -g -w -wi
	gcc --shared lib.o -o lib.so

app:
	dmd app.d -L-ldl -L-lrt -debug -gc -g -w -wi

clean:
	rm -f lib.so
	rm -f lib.o
	rm -f app
Feb 27 2014
parent reply "Tolga Cakiroglu" <tcak pcak.com> writes:
Whops! Hold on a sec. I saw that I defined `foo` as `extern` 
instead of `export`. Testing with that.
Feb 27 2014
parent reply "Tolga Cakiroglu" <tcak pcak.com> writes:
On Friday, 28 February 2014 at 06:28:10 UTC, Tolga Cakiroglu 
wrote:

 Whops! Hold on a sec. I saw that I defined `foo` as `extern` 
 instead of `export`. Testing with that.


Even Walter Bright's code doesn't use export, and goes with 
extern only.
http://dlang.org/dll-linux.html#dso10
Feb 27 2014
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Friday, 28 February 2014 at 06:36:02 UTC, Tolga Cakiroglu 
wrote:

 On Friday, 28 February 2014 at 06:28:10 UTC, Tolga Cakiroglu 
 wrote:

 Whops! Hold on a sec. I saw that I defined `foo` as `extern` 
 instead of `export`. Testing with that.


 Even Walter Bright's code doesn't use export, and goes with 
 extern only.
 http://dlang.org/dll-linux.html#dso10


that articles may be outdated. export has some problems in terms 
it was implemented recently, and still not on all platforms.

also, why are you calling gcc to make .so ? isn't dmd with 
-shared not works? or maybe if you really need gcc it is requires 
to link with phobos and/or runtime if any?
Feb 27 2014
parent reply "Tolga Cakiroglu" <tcak pcak.com> writes:
On Friday, 28 February 2014 at 06:40:27 UTC, evilrat wrote:

 On Friday, 28 February 2014 at 06:36:02 UTC, Tolga Cakiroglu 
 wrote:

 On Friday, 28 February 2014 at 06:28:10 UTC, Tolga Cakiroglu 
 wrote:

 Whops! Hold on a sec. I saw that I defined `foo` as `extern` 
 instead of `export`. Testing with that.


 Even Walter Bright's code doesn't use export, and goes with 
 extern only.
 http://dlang.org/dll-linux.html#dso10


 that articles may be outdated. export has some problems in 
 terms it was implemented recently, and still not on all 
 platforms.

 also, why are you calling gcc to make .so ? isn't dmd with 
 -shared not works? or maybe if you really need gcc it is 
 requires to link with phobos and/or runtime if any?


If I don't use GCC, and use a build code as below, following is 
the error of compiler:

dmd lib.d -shared -fPIC -debug -gc -g -w -wi
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(lifetime_46f_7db.o): 
relocation R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' can 
not be used when making a shared object; recompile with -fPIC
/usr/lib/x86_64-linux-gnu/libphobos2.a: error adding symbols: Bad 
value
collect2: error: ld returned 1 exit status
--- errorlevel 1
make: *** [libnogcc] Error 1
Feb 27 2014
parent reply "Stanislav Blinov" <stanislav.blinov gmail.com> writes:
On Friday, 28 February 2014 at 06:45:25 UTC, Tolga Cakiroglu 
wrote:


 If I don't use GCC, and use a build code as below, following is 
 the error of compiler:

 dmd lib.d -shared -fPIC -debug -gc -g -w -wi
 /usr/bin/ld: 
 /usr/lib/x86_64-linux-gnu/libphobos2.a(lifetime_46f_7db.o): 
 relocation R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' 
 can not be used when making a shared object; recompile with 
 -fPIC
 /usr/lib/x86_64-linux-gnu/libphobos2.a: error adding symbols: 
 Bad value
 collect2: error: ld returned 1 exit status
 --- errorlevel 1
 make: *** [libnogcc] Error 1


http://dlang.org/dll-linux.html#dso7

dmd lib.d -shared -fPIC -debug -gc -g -w -wi 
-defaultlib=libphobos2.so
Feb 28 2014
parent "Tolga Cakiroglu" <tcak pcak.com> writes:
 http://dlang.org/dll-linux.html#dso7

 dmd lib.d -shared -fPIC -debug -gc -g -w -wi 
 -defaultlib=libphobos2.so


Problem about using shared libphobos is that I need to install 
many different libraries on the target computer. On the web 
server, I don't want to install DMD. I compiled before a DLL with 
libphobos2.so, and on web server it started asking many different 
libraries which made me unhappy.
Feb 28 2014