Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove GNUReadline link dependency from PyNEST #323

Merged
merged 2 commits into from Apr 27, 2016

Conversation

@tammoippen
Copy link
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.

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
Copy link
Contributor

heplesser commented Apr 26, 2016

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

@jougs
Copy link
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
Copy link
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
Copy link
Contributor Author

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
Copy link
Contributor Author

tammoippen commented Apr 26, 2016

I will put some documentation into the cmake.

and add implicit dependency to nestutil explicitly
@apeyser
Copy link
Contributor

apeyser commented Apr 27, 2016

👍

Looks hopeful!

@apeyser apeyser merged commit 10c079b into nest:master Apr 27, 2016
1 check passed
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
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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.