www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - crt1.o: could not read symbols: Bad value

reply "Tim" <nrgyzer gmail.com> writes:
Hi guys,

I've the following few lines:


module test;

export:
extern(D):


int test()
{
	return 0;
}

... and compile it using the following line:

dmd -m64 -fPIC -L-shared test.d -oflibtest.so

But when I try to compile it, I always get the following error:

/usr/bin/ld: 
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: 
relocation R_X86_64_32S against `__libc_csu_fini' can not be used 
when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: 
could not read symbols: Bad value
collect2: ld gab 1 als Ende-Status zurück
--- errorlevel 1

Any suggestions how to solve the problem?
Jun 10 2014
parent reply "FreeSlave" <freeslave93 gmail.com> writes:
dmd has -shared option. Try it instead of -L-shared.
Jun 10 2014
parent reply "Tim" <nrgyzer gmail.com> writes:
On Tuesday, 10 June 2014 at 20:29:56 UTC, FreeSlave wrote:
 dmd has -shared option. Try it instead of -L-shared.
I'm getting a similar error: /usr/bin/ld: /usr/local/bin/../lib64/libphobos2.a(object__a_58c.o): relocation R_X86_64_32 against `_D10TypeInfo_m6__initZ' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/../lib64/libphobos2.a: could not read symbols: Bad value collect2: ld gab 1 als Ende-Status zurück --- errorlevel 1
Jun 10 2014
parent reply "FreeSlave" <freeslave93 gmail.com> writes:
It seems like you're trying to compile 64-bit code when you are 
on 32-bit system and you have 32-bit libphobos.
Jun 11 2014
parent reply "FreeSlave" <freeslave93 gmail.com> writes:
I conclude that because I have similar errors when trying to 
build 64-bit library on 32-bit system.

/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(format_712_5b3.o): 
relocation R_X86_64_32 against `.rodata' 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

But paths in your error log look like you're on x64, so it's 
probably not the case.
Jun 11 2014
parent reply "Tim" <nrgyzer gmail.com> writes:
On Wednesday, 11 June 2014 at 10:09:50 UTC, FreeSlave wrote:
 I conclude that because I have similar errors when trying to 
 build 64-bit library on 32-bit system.

 /usr/bin/ld: 
 /usr/lib/x86_64-linux-gnu/libphobos2.a(format_712_5b3.o): 
 relocation R_X86_64_32 against `.rodata' 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

 But paths in your error log look like you're on x64, so it's 
 probably not the case.
Yes, I'm using a x64 system (CentOS 6.5), but I also use dmd64.
Jun 11 2014
parent reply "Tim" <nrgyzer gmail.com> writes:
On Wednesday, 11 June 2014 at 17:11:51 UTC, Tim wrote:
 On Wednesday, 11 June 2014 at 10:09:50 UTC, FreeSlave wrote:
 I conclude that because I have similar errors when trying to 
 build 64-bit library on 32-bit system.

 /usr/bin/ld: 
 /usr/lib/x86_64-linux-gnu/libphobos2.a(format_712_5b3.o): 
 relocation R_X86_64_32 against `.rodata' 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

 But paths in your error log look like you're on x64, so it's 
 probably not the case.
Yes, I'm using a x64 system (CentOS 6.5), but I also use dmd64.
It seems that -defaultlib=libphobos2.so solved the problem. When I use the following compile command: dmd test.d -shared -defaultlib=libphobos2.so I don't get any error. I hope the shared object works as expect...
Jun 11 2014
parent "Tim" <nrgyzer gmail.com> writes:
On Wednesday, 11 June 2014 at 17:21:54 UTC, Tim wrote:
 On Wednesday, 11 June 2014 at 17:11:51 UTC, Tim wrote:
 On Wednesday, 11 June 2014 at 10:09:50 UTC, FreeSlave wrote:
 I conclude that because I have similar errors when trying to 
 build 64-bit library on 32-bit system.

 /usr/bin/ld: 
 /usr/lib/x86_64-linux-gnu/libphobos2.a(format_712_5b3.o): 
 relocation R_X86_64_32 against `.rodata' 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

 But paths in your error log look like you're on x64, so it's 
 probably not the case.
Yes, I'm using a x64 system (CentOS 6.5), but I also use dmd64.
It seems that -defaultlib=libphobos2.so solved the problem. When I use the following compile command: dmd test.d -shared -defaultlib=libphobos2.so I don't get any error. I hope the shared object works as expect...
I can compile my so-library (which contains MySQL UDF Functions). It also works - as long as I try to create objects or assign something like this: export extern(C): char* mysql_custom_udf(UDF_INIT* initid, UDF_ARGS* args, char* result, c_ulong *length, char* is_null, char* error) { JSONValue json = null; json = ["myObject" : "AssignSomething"]; // <- That throws the exception string res = "Hello World!"; result = cast(char*) res.ptr; *length = res.length; return cast(char*) result; } The function above is contained inside the shared object (so) file. When I remove/comment out the "json = ["myObject" : "AssignSomething"];"-line I can call the udf from MySQL. But when I uncomment/insert the line I'm getting the following error: Thread pointer: 0x1d24250 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7fc98804ae18 thread_stack 0x40000 /usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8cea15] /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65e0d4] /lib64/libpthread.so.0(+0xf710)[0x7fc98abcb710] /usr/lib64/libphobos2.so.0.65(gc_malloc+0x29)[0x7fc951a70e05] Any suggestions how to solve that error? It seems that there's anything wrong with gc_malloc in libphobos2...
Jun 12 2014