Issue #2 open

Build fails on a new computer

madjar
created an issue

During the build process, The python bindings are used.

The problem is that the python bindings need datenwerk to be install, or that libdatenwerk.so is present in the python/datenwerk dir. Here is the code responsable of that behaviour.

{{{

!python

WIN32 = sys.platform == 'win32' MODULE_PATH = os.path.abspath(os.path.dirname(file))

if WIN32: lib_path = os.path.join(MODULE_PATH,'datenwerk.dll') else: lib_path = os.path.join(MODULE_PATH,'libdatenwerk.so') if not os.path.isfile(lib_path): lib_path = find_library("datenwerk")

assert lib_path, "Can't find the Datenwerk C-library." }}}

Of course, during the first build, datenwerk is not installed and the build fail. I presume this behaviour does not appear if datenwerk is already installed.

Some possible solutions : Copy libdatenwerk.so the python/datenwerk dir Remove the tests from the main build process

Comments (8)

  1. Leonard Ritter repo owner
    • changed status to open

    The error is peculiar, as I can't seem to reproduce it. SConstruct adds the library path to LD_LIBRARY_PATH during build, and python is executed in that environment, so the C library can always be found.

  2. madjar reporter

    Archlinux (last version). Python version is 2.7.2.

    What is strange is that, even by setting the LD_LIBRARY_PATH manually, it doesn't work.

    ➜  python  ls ../build/linux-x86_64/release/datenwerk
    array.os   bool.os   containers.os  float.os    hub.os  io.os    libdatenwerk.so  main.os     memory.os  object.os  string.os
    assert.os  class.os  context.os     history.os  int.os  item.os  link.os          memfile.os  net.os     signal.os
    ➜  python  LD_LIBRARY_PATH=../build/linux-x86_64/release/datenwerk python2 -c "import datenwerk"       
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "datenwerk/__init__.py", line 106, in <module>
        assert lib_path, "Can't find the Datenwerk C-library."
    AssertionError: Can't find the Datenwerk C-library.
    
  3. Anonymous

    Hello,

    I at least managed to pinpoint parts of the problem, which is due to scons' most idiotic behavior: although you use env.PrependENVPath, it is NOT put in os.environ, just scons' env['ENV'] var. So, when you call os.system, the subprocess doesn't have the modified env either. You need to explicitly setup the subprocess env from scons' env['ENV'] var, as in:

    def compile_schema(target, source, env):
        cpp_out_folder = os.path.dirname(target[0].path)
        py_out_folder = os.path.dirname(target[0].path)
        source_paths = [f.path for f in source]
        args = ['dwsc',
            '--cpp-out=' + cpp_out_folder,
            '--python-out=' + py_out_folder
            ] + source_paths
        print args
        import subprocess;
        return subprocess.call(args, env=env['ENV'])
    

    Even with that fix, it still fails to build because env.PrependENVPath('LD_LIBRARY_PATH', env.subst('#build/$variant_dir/datenwerk')) doesn't seem to construct an absolute path in the end: env['ENV']['LD_LIBRARY_PATH'] is just 'build/linux-x86_64/release/datenwerk'.

    I don't know how to force it to generate an abs path.

    Good Luck,

    -- Johan B.

  4. Anonymous

    One more atempt, putting:

    env.PrependENVPath('LD_LIBRARY_PATH', os.path.abspath(env.subst('build/$variant_dir/datenwerk')))
    

    in the top SConstruct file, which leads to the correct abs path for LD_LIBRARY_PATH in os.environ when datenwek/init.py gets executed during the build, alas it's still bailing out on the assertion. Something wrong is going on with ctypes.util.find_library.

  5. Anonymous

    Well, you open up /usr/lib/python*/ctypes/util.py and have a look at the ugliness of that find_library function. After less than 5 minutes, you'll feel nauseated enough not to be willing to use that crap anymore, ever.

    ctypes.util.find_library doesn't use the LD_LIBRARY_PATH env var.

    If this is working by you, chances are it's just like madjar since the beginning: you've got the lib setup system-wide. Less likely it could be some weird LIBRARY_PATH env var (used by gcc's linker).

    I'm sorry to say this, but it really does looks like the whole thing, from build system to runtime code needs to be rethought from scratch if you want any chance to make it work reliably :/

  6. Log in to comment