Playing with pypy.

I build me a shared library with ldc and try to access it via ctypes, and it gives me a

/usr/lib64/libdruntime-ldc.so.60: undefined symbol: __data_start

So the natural question is what is __data_start? Am I right in assuming it is a symbol that points to the data section or something and that it is relevant in executables but not shared libraries (and thus shouldn't be in druntime for shared lib builds)?

On 2012-11-12 03:49, Ellery Newcomer wrote:
> Playing with pypy.
>
> I build me a shared library with ldc and try to access it via ctypes,
> and it gives me a
>
> /usr/lib64/libdruntime-ldc.so.60: undefined symbol: __data_start
>
> So the natural question is what is __data_start? Am I right in assuming
> it is a symbol that points to the data section or something and that it
> is relevant in executables but not shared libraries (and thus shouldn't
> be in druntime for shared lib builds)?

Yes, although I don't know if it should be in shared libraries or not.

-- 
/Jacob Carlborg

Am Sun, 11 Nov 2012 18:49:18 -0800
schrieb Ellery Newcomer <ellery-newcomer@utulsa.edu>:

> Playing with pypy.
> 
> I build me a shared library with ldc and try to access it via ctypes, and it gives me a
> 
> /usr/lib64/libdruntime-ldc.so.60: undefined symbol: __data_start

How did you link that shared lib? With ld, gcc or g++? If you link via gcc it pulls in some special object files, one of these could contain __data_start. g++ pulls in some more object files for c++ support, but that's probably not necessary here.

> 
> So the natural question is what is __data_start? Am I right in assuming it is a symbol that points to the data section or something and that it is relevant in executables but not shared libraries (and thus shouldn't be in druntime for shared lib builds)?

There doesn't seem to be much documentation about __data_start. It's a C library / linker symbol, but I think it's local to each shared object. So only the main application can access _it's_ __data_start, and according to some sources each shared library should get it's own __data_start. I don't know why it's not defined in your case. It does mark the start of the data section of the module accessing it but each module (app/shared object) has it's own data section and therefore needs a different __data_start.

See also: http://forum.dlang.org/thread/ftnv6c$2odr$1@digitalmars.com#post-ftpobo:24oi:241:40digitalmars.com

But anyway, the runtime uses __data_start to find the data
section which should be scanned by the gc (see rt.memory). I really
doubt this approach will work in an application with multiple shared
libraries.

On 2012-11-12 09:54, Johannes Pfau wrote:

> But anyway, the runtime uses __data_start to find the data
> section which should be scanned by the gc (see rt.memory). I really
> doubt this approach will work in an application with multiple shared
> libraries.

I'm not sure but I think it won't. The runtime needs to iterate all loaded images (executables and dynamic libraries) and collect the data section of each image.

-- 
/Jacob Carlborg

On 2012-11-12 10:02, Jacob Carlborg wrote:

> I'm not sure but I think it won't. The runtime needs to iterate all
> loaded images (executables and dynamic libraries) and collect the data
> section of each image.

I think "dl_iterate_phdr" needs to be used. That is what the Boehm GC uses on Linux.

-- 
/Jacob Carlborg

On 11/12/2012 12:54 AM, Johannes Pfau wrote:
> How did you link that shared lib? With ld, gcc or g++? If you link via
> gcc it pulls in some special object files, one of these could contain
> __data_start. g++ pulls in some more object files for c++ support, but
> that's probably not necessary here.

gcc -nostartfiles

> But anyway, the runtime uses __data_start to find the data
> section which should be scanned by the gc (see rt.memory). I really
> doubt this approach will work in an application with multiple shared
> libraries.
>

Well, that could be one reason why multiple shared libs doesn't work with my setup.