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. http://publink.neffie.com/subject/ydu59u5vXyrnNKDK20yd4SDWY7iGLU1OcM7nlslAuNsPtYSM602xHMYCpKp29WU5#635291642225045068 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