Comments (7)
@sanjayankur31 Before being cleared, the flags as saved as SLI_SAVE_{C,CXX}FLAGS (see lines 330-370), and these saved values are then appended to the flags used to build NEST by the SLI_SET_{C,CXX}FLAGS macros. So they will be used when building NEST, but they will not be used while running the tests following line 461.
As you can see from the comments in configure.ac, I wrote that code 11 years ago. Unfortunately, I can right away reconstruct why I did that then, but something must have interfered in some way then.
Could you let me know a bit more about what goes wrong when you try to build NEST?
from nest-simulator.
Ah, that's weird. I was building nest for Fedora (review ticket here - https://bugzilla.redhat.com/show_bug.cgi?id=1273579 and copr builds here - https://copr.fedoraproject.org/coprs/ankursinha/neuroscience-research/build/129034/) and it didn't seem to pick up CFLAGS, LDFLAGS or CXXFLAGS that the build system set up. It exports them before calling the configure script. Like this for example:
$ rpm -E %configure
CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic}" ; export CFLAGS ;
CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic}" ; export CXXFLAGS ;
FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
FCFLAGS="${FCFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -I/usr/lib64/gfortran/modules}" ; export FCFLAGS ;
LDFLAGS="${LDFLAGS:--Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld}"; export LDFLAGS;
[ "1" = 1 ] && for i in $(find $(dirname ./configure) -name config.guess -o -name config.sub) ; do
[ -f /usr/lib/rpm/redhat/$(basename $i) ] && /usr/bin/rm -f $i && /usr/bin/cp -fv /usr/lib/rpm/redhat/$(basename $i) $i ;
done ;
[ "1" = 1 ] && [ x != "x-specs=/usr/lib/rpm/redhat/redhat-hardened-ld" ] &&
for i in $(find . -name ltmain.sh) ; do
/usr/bin/sed -i.backup -e 's~compiler_flags=$~compiler_flags="-specs=/usr/lib/rpm/redhat/redhat-hardened-ld"~' $i
done ;
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu \
--program-prefix= \
--disable-dependency-tracking \
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib64 \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/var/lib \
--mandir=/usr/share/man \
--infodir=/usr/share/info
For the time being, I've just removed the lines that clear CFLAGS and things, and that seems to have fixed it.
from nest-simulator.
This is what I'd get when CFLAGS was cleared, for example:
checking for closedir... no
checking for opendir... no
checking for readdir... no
checking for strlcat... no
checking for strlcpy... no
checking for gsl-config... /usr/bin/gsl-config
checking for GSL - version >= 1.0... no
*** Could not run GSL test program, checking why...
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding GSL or finding the wrong
*** version of GSL. If it is not finding GSL, you'll need to set your
*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point
*** to the installed location Also, make sure you have run ldconfig if that
*** is required on your system
***
*** If you have an old version installed, it is best to remove it, although
*** you may also be able to get things to work by modifying LD_LIBRARY_PATH
checking for inline... inline
checking for popen... no
checking for pclose... no
checking for execv... no
checking for fork... no
checking for setenv... no
checking for sigaction... no
checking for expm1 ... yes
checking how to run the C++ preprocessor... g++ -E
checking for gmake... /usr/bin/gmake
checking for tgetstr in -lcurses... no
checking for tgetstr in -ltermcap... no
checking for tgetstr in -lncursesw... no
checking for tgetstr in -lncurses... no
configure: error: You need either libncurses, libcurses, or libtermcap to compile NEST.
Here, all the required packages are installed, and everything available in the standard locations, but the configure script failed to find them.
from nest-simulator.
@sanjayankur31 Thanks for building NEST for Fedora! Looking at copr, it seems that you have succeeded in building NEST now---was that after manually removing the lines that cleared the CFLAGS? We are currently looking at a thorough overhaul of our build system, so unless it is crucial for you, I would not want to spend much time on investigating this issue further at present.
Btw, I noticed the question concerning Python3 in your review ticket. NEST supports Python 3.
from nest-simulator.
I've managed to build it, and the package works, but as you'll see from the review, there are a few issues I need to work on before the package gets into Fedora and EL (CentOS etc too).
I manually deleted the lines in the spec file. It isn't crucial at all. I can carry that patch downstream for the time being - I have to carry some patches to get the files to install in proper Fedora specific MPI locations anyway.
Thanks for clarifying the Py3 issue. I had gone through the release notes for previous releases and noticed that they had mentioned Py3. I'll update the package to build the Py3 version as well when I fix the other issues pointed out by the reviewer.
Closing this ticket then. Cheers!
from nest-simulator.
Just a short addition: we're happy to review a pull request with the patches you require for proper package building. If they don't collide with other platforms, we'll include them into mainline NEST.
from nest-simulator.
I'm still looking into them. They seem to mostly be downstream patches that are required to place files in proper Fedora specific locations. For example, on Fedora/EL variants, this is how MPI specific locations are defined (when one goes module load mpi/openmpi-x86_64
):
[asinha@stri-cluster results]$ env | grep MPI
MPI_INCLUDE=/usr/include/openmpi-x86_64
MPI_PYTHON_SITEARCH=/usr/lib64/python2.7/site-packages/openmpi
MPI_LIB=/usr/lib64/openmpi/lib
MPI_BIN=/usr/lib64/openmpi/bin
MPI_COMPILER=openmpi-x86_64
MPI_SYSCONFIG=/etc/openmpi-x86_64
MPI_SUFFIX=_openmpi
MPI_MAN=/usr/share/man/openmpi-x86_64
MPI_FORTRAN_MOD_DIR=/usr/lib64/gfortran/modules/openmpi-x86_64
MPI_HOME=/usr/lib64/openmpi
Just changing prefix
and execprefix
didn't quite seem enough - binaries go to a different location, python stuff goes to a completely different location and so on. I haven't used a Ubuntu variant in a while and am not sure if they use the same locations. I'll check up and if these patches turn out to be general, I'll open a pull request.
Cheers!
from nest-simulator.
Related Issues (20)
- Properly control validity of NodeCollections and SynapseCollections with hashes
- ConnBuilder loop_over_targets() does not work as intended HOT 1
- NEST behaves incorrectly or fails when connecting sliced layers while using MPI
- Allow use of pairwise_bernoulli rule for connections to devices
- How do you run Potjans_2014 in full scale? HOT 4
- MPI initialization exits ungracefully
- NEST fails to assert presence of required Boost libraries when Boost is configured HOT 2
- Connecting nodes with spatial positions fails in corner case
- Nest-simulator 3.4 - installation on MAC - sli HOT 2
- Review use of types for number of processes and threads
- Refactor to use higher mathematical functions available per C++17
- Compiler warns about initializing reference with temporary in astrocyte_lr_1994
- Slow DumpLayerConnections() HOT 3
- Download NEST for working with Python HOT 3
- Displaying NodeCollection is very slow in IPython
- SelectNodesByMask() and DumpLayerConnections() combination problem
- Failing MPI tests not properly detected
- When dividing by random parameter, one obtains fixed, not random values
- How to debug the C++ Kernel in VSCode from PyNEST program? HOT 2
- Report on PyNEST examples test run
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nest-simulator.