Fatal Error while loading '/lib64/libphobos2.so.0.67' The module 'std.array' is already defined in './pydtest'

[deviator]

I call extending D function from embeded python code in D code

src/main.d

import std.stdio;
import pyd.pyd, pyd.embedded;
void main()
{
    py_init();
    auto script = new InterpContext;
    script.py_stmts( "import sys" );
    script.py_stmts( "sys.path.append('.')" );
    script.py_stmts( "import pct" );
    writefln( "result: %s", script.pct.calldfunc()(12) );
}

pct.py

import func

def calldfunc(x):
    return func.calc( 8, x )

src/func.d

module func;
import pyd.pyd;
import std.math;
float calc( float x, float y ) { return sqrt(x) + y^^x; }
extern(C) void PydMain()
{
    def!(calc)();
    module_init();
}

setup_func.py

from pyd.support import setup, Extension
projName = 'func'
setup(
    name=projName,
    version='0.1',
    ext_modules=[
        Extension(projName, ['src/func.d'],
            extra_compile_args=['-w'],
            build_deimos=True,
            d_lump=True
        )
    ],
)

dub.json

{
    "name": "pydtest",
    "targetType": "executable",
    "dependencies": {
        "pyd": "~>0.9.7"
    },
    "subConfigurations": {
        "pyd": "python34"
    }
}

run

dub build
python3 setup_func.py build && cp build/lib.linux-x85-64-3.4/func.cpython-34m.so .
./pydtest

and have error

Fatal Error while loading '/lib64/libphobos2.so.0.67':
    The module 'std.array' is already defined in './pydtest'.

Linux 4.0.4-201.fc21.x86_64 DMD64 v2.067.1 Python 3.4.1

[ariovistus]

add

"dflags": ["-defaultlib=libphobos2.so"],

to dub.json.

Annoyingly enough, it will go on to complain that pyd modules are already defined in pydtest (as well as func, but that can be fixed by moving it out of src).

What would need to happen, is dub would need to not compile pyd modules in, but rather reference them in the so file. I'll see if I can figure something out...

[ariovistus]

hm.

"Dynamic libraries are not yet supported as dependencies - building as static library."

dub's out.

Next, the so file is missing some symbols because of some assumptions that don't hold in this case. those can be rearranged... and nope. pyd was not architected to work this way, so no quick hacky fixes today, sorry.

I'm thinking pyd's runtime needs to be built as a dynamic library. then both the pyd extension[s] and the main program would link to that. Not sure if that will work with all the template metaprogramming. It'd be an adventure.

[deviator]

Some workaround can be used: d program compiles with ldc2, compilation of python part wasn't change (i don't know how select ldc2 as d compiler in building process of pyd).