Remove GNUReadline link dependency from PyNEST #323

Merged
merged 2 commits into from Apr 27, 2016

Conversation

Projects
None yet
4 participants
@tammoippen
Contributor

tammoippen commented Apr 26, 2016

Only the executables sli and nest use the GNUReadline interaction. All other libraries and modules, e.g. PyNEST, do not need to be linked against the GNUReadline library. In this PR I create a separate target sli_readline that contains all the code necessary for the GNUReadline interaction and link it only to sli and nest executable. This way PyNEST is not linked against GNUReadline (and Python can use its readline library) and problems discussed in #210 and #209 will not occur anymore.

Create separate sli_readline target
This library contains all the code necessary for GNUReadline interaction. We linke it only to sli and nest executable, so that for example pynest is not affected by readline linking stuff.
@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser Apr 26, 2016

Contributor

Looks good 👍, but I think @apeyser should take another look before merging.

Contributor

heplesser commented Apr 26, 2016

Looks good 👍, but I think @apeyser should take another look before merging.

@jougs

This comment has been minimized.

Show comment
Hide comment
@jougs

jougs Apr 26, 2016

Contributor

👍 from me. I think this is a nice solution to #209. I still suggest to keep #210 open.

Contributor

jougs commented Apr 26, 2016

👍 from me. I think this is a nice solution to #209. I still suggest to keep #210 open.

@apeyser

This comment has been minimized.

Show comment
Hide comment
@apeyser

apeyser Apr 26, 2016

Contributor

@tammoippen
Have you tried it under different archs? I think it will definitely cause what you expect under OSX which has two level namespaces, but I'm less sure sure under Linux where pynest ends up linked against nest, which I think would still end up getting linked to sli_readline, correct? I think it depends on some flag linking subtleties which I don't know enough to predict. If cmake & most compilers do what you think, then this is good (but maybe a line in cmake.txt explaining at least a reference number back here would be good).

Another option is to remove readline and just stick rlwrap around the whole thing.

Contributor

apeyser commented Apr 26, 2016

@tammoippen
Have you tried it under different archs? I think it will definitely cause what you expect under OSX which has two level namespaces, but I'm less sure sure under Linux where pynest ends up linked against nest, which I think would still end up getting linked to sli_readline, correct? I think it depends on some flag linking subtleties which I don't know enough to predict. If cmake & most compilers do what you think, then this is good (but maybe a line in cmake.txt explaining at least a reference number back here would be good).

Another option is to remove readline and just stick rlwrap around the whole thing.

@tammoippen

This comment has been minimized.

Show comment
Hide comment
@tammoippen

tammoippen Apr 26, 2016

Contributor

I tried it under OS X and now also under Linux (Lubuntu 14.04). Only the executables sli/nest are linked to sli_readline, and pynestkernel.so is not: pynestkernel.so links against sli_lib, nest_lib, ..., which all do not have a main function and also do not have the gnureadline code (with this PR).

See this dependency graph: yellow boxes are external libraries, red boxes are our executables/modules, white boxes are libraries within nest, black arrows are explicit links and orange arrows are implicit links (i left out the implicit links for the executables/modules to make it clearer).

Using ldd on pynestkernel reveals this: no readline 😄

$ ldd install/lib/python2.7/site-packages/nest/pynestkernel.so 
    linux-vdso.so.1 =>  (0x00007ffe92f39000)
    libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007ff5f7bb1000)
    libnest_lib.so => /home/fiddler/Desktop/nest/build/install/lib/libnest_lib.so (0x00007ff5f7986000)
    libnestkernel.so => /home/fiddler/Desktop/nest/build/install/lib/libnestkernel.so (0x00007ff5f766a000)
    librandom.so => /home/fiddler/Desktop/nest/build/install/lib/librandom.so (0x00007ff5f741e000)
    libsli_lib.so => /home/fiddler/Desktop/nest/build/install/lib/libsli_lib.so (0x00007ff5f70cf000)
    libtopology.so => /home/fiddler/Desktop/nest/build/install/lib/libtopology.so (0x00007ff5f6e4c000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff5f6b48000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff5f6932000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5f656d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff5f634f000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff5f6136000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff5f5f32000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff5f5d2f000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff5f5a29000)
    libmodels.so => /home/fiddler/Desktop/nest/build/install/lib/libmodels.so (0x00007ff5f5361000)
    libprecise.so => /home/fiddler/Desktop/nest/build/install/lib/libprecise.so (0x00007ff5f510e000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007ff5f4eff000)
    libnestutil.so => /home/fiddler/Desktop/nest/build/install/lib/libnestutil.so (0x00007ff5f4cfb000)
    libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007ff5f4af1000)
    libgsl.so.0 => /usr/lib/libgsl.so.0 (0x00007ff5f4691000)
    libgslcblas.so.0 => /usr/lib/libgslcblas.so.0 (0x00007ff5f4445000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff5f835f000)
Contributor

tammoippen commented Apr 26, 2016

I tried it under OS X and now also under Linux (Lubuntu 14.04). Only the executables sli/nest are linked to sli_readline, and pynestkernel.so is not: pynestkernel.so links against sli_lib, nest_lib, ..., which all do not have a main function and also do not have the gnureadline code (with this PR).

See this dependency graph: yellow boxes are external libraries, red boxes are our executables/modules, white boxes are libraries within nest, black arrows are explicit links and orange arrows are implicit links (i left out the implicit links for the executables/modules to make it clearer).

Using ldd on pynestkernel reveals this: no readline 😄

$ ldd install/lib/python2.7/site-packages/nest/pynestkernel.so 
    linux-vdso.so.1 =>  (0x00007ffe92f39000)
    libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007ff5f7bb1000)
    libnest_lib.so => /home/fiddler/Desktop/nest/build/install/lib/libnest_lib.so (0x00007ff5f7986000)
    libnestkernel.so => /home/fiddler/Desktop/nest/build/install/lib/libnestkernel.so (0x00007ff5f766a000)
    librandom.so => /home/fiddler/Desktop/nest/build/install/lib/librandom.so (0x00007ff5f741e000)
    libsli_lib.so => /home/fiddler/Desktop/nest/build/install/lib/libsli_lib.so (0x00007ff5f70cf000)
    libtopology.so => /home/fiddler/Desktop/nest/build/install/lib/libtopology.so (0x00007ff5f6e4c000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff5f6b48000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff5f6932000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5f656d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff5f634f000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff5f6136000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff5f5f32000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff5f5d2f000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff5f5a29000)
    libmodels.so => /home/fiddler/Desktop/nest/build/install/lib/libmodels.so (0x00007ff5f5361000)
    libprecise.so => /home/fiddler/Desktop/nest/build/install/lib/libprecise.so (0x00007ff5f510e000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007ff5f4eff000)
    libnestutil.so => /home/fiddler/Desktop/nest/build/install/lib/libnestutil.so (0x00007ff5f4cfb000)
    libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007ff5f4af1000)
    libgsl.so.0 => /usr/lib/libgsl.so.0 (0x00007ff5f4691000)
    libgslcblas.so.0 => /usr/lib/libgslcblas.so.0 (0x00007ff5f4445000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ff5f835f000)
@tammoippen

This comment has been minimized.

Show comment
Hide comment
@tammoippen

tammoippen Apr 26, 2016

Contributor

I will put some documentation into the cmake.

Contributor

tammoippen commented Apr 26, 2016

I will put some documentation into the cmake.

Comment sli_readline
and add implicit dependency to nestutil explicitly
@apeyser

This comment has been minimized.

Show comment
Hide comment
@apeyser

apeyser Apr 27, 2016

Contributor

👍

Looks hopeful!

Contributor

apeyser commented Apr 27, 2016

👍

Looks hopeful!

@apeyser apeyser merged commit 10c079b into nest:master Apr 27, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

tammoippen added a commit that referenced this pull request May 18, 2016

Fix building nest without python
The PR #323 removed GNUReadline from PyNEST, but when building nest without python
the library `libnest.so` now expects GNUReadline, as no _IS_PYNEST is given.
This commit allows to differentiate building the NEST CLI, PyNEST and a standalone
library.

@tammoippen tammoippen deleted the tammoippen:pynest_wo_readline branch May 18, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment