NOTE:
* I've confirmed that ECCE built like this installs and works perfectly on a Thinkpad SL410 with intel graphics
* It also compiles and runs perfectly on a home built desktop with external nvidia card (GF119) using the binary non-free nvidia drivers
* It also compiles and runs perfectly on a home built desktop with onboard nvidia (GeForce 7025/nForce 630a) using the nouveau drivers. I had issues on this desktop before, but reinstalled debian jessie from scratch. Before that I used nvidia-legacy drivers, which may or may not (probably not) have had something to do with it not working.
* UPDATE: instead of putting
#include <freetype.h>
the recommended method is to use
#include FT_FREETYPE_H
I've updated the patch_script.sh below accordingly. Same goes for ftoutln.h vs FT_OUTLINE_H, but the latter didn't work (error saying #include must use "" or <>)
* UPDATE: If you're having issues with undetected -lGL and -lGLU in the wxwidgets step, it's because
667 endif
668 cat configure.orig | sed -e 's%^SEARCH_INCLUDE="\\%SEARCH_INCLUDE="$ECCE_HOME/${ECCE_SYSDIR}3rdparty/mesa/include \\%' >! configure
669 chmod a+x configure
670
needs to be changed to
667 endif
668 cat configure.orig | sed -e 's%^SEARCH_INCLUDE="\\%SEARCH_INCLUDE="$ECCE_HOME/${ECCE_SYSDIR}3rdparty/mesa/include $ECCE_HOME/${ECCE_SYSDIR}3rdparty/mesa/lib \\%' >! configure
669 chmod a+x configure
670
I had this issue on a debian wheezy system with the vendor nvidia libraries.
I wouldn't have spotted this bug otherwise.
* Another error from my debian wheezy nvidia system: if you get
checking how to run the C preprocessor... x86_64-linux-gnu-gcc -E
./configure: line 2880: syntax error near unexpected token `Using'
./configure: line 2880: ` AC_MSG_NOTICE(Using external PCRE library from $PCRE_CONFIG)'
then make sure you're not using autoconf2.13, which is an obsolete version. I think I have it due to my system originally being installed back in 2010.
* Finally, I'm currently working on fixing minor things that have been nagging me in ecce. One is the basis set quicklist (in
src/dsm/edsiimpl/ICalcUtils.C), but obviously that's a personal preference. A more serious one is the 256 character limit for csh commands:
Exceeds maximum C shell command length of 256 characters
Note that this isn't the C shell complaining -- this is a built-in limit in ecce (in
src/comm/rcommand/RCommand.C). I've changed that limit to 16384 characters (the real limit is much, much higher)
I've also added two basis sets to ECCE, and have tinkered with the exchange-correlation functionals.
I'll try to push the fixes back upstreams when I'm ready if they'll accept them; otherwise I'll create my own github/sourceforge repo.
THE POST:
Building ECCE on debian wheezy was a breeze. Building ECCE on debian jessie was painful.
In the end it boiled down to two things:
*freetype headers are no longer in freetype2/freetype/ but in freetype2/
*-Wformat-security is turned on by default
mkdir ~/tmp/ecce_compile -p
cd ~/tmp/ecce_compile
sudo apt-get install bzip2 build-essential autoconf libtool ant pkg-config
sudo apt-get install gtk+-2.0-dev libxt-dev csh gfortran openjdk-7-jdk python-dev
sudo apt-get install libjpeg-dev imagemagick xterm libfreetype6-dev libfl-dev libtool-bin
As usual I'm not 100% sure when it comes to the necessary packages. libfl-dev might not be needed.
Download the
ECCE source code and put the
ecce-v7.0-src.tar.bz2 file in
~/tmp/ecce_compile. Put the
patch_script.sh file (see below in this post for the code) in
~/tmp/ecce_compile. Then do
tar xvf ecce-v7.0-src.tar.bz2
cd ecce-v7.0/
export ECCE_HOME=`pwd`
cd build/
./build_ecce
You'll now step through a list over programs and libraries that are needed and what ECCE can find. If you're having issues with e.g. javac and java being different versions, use sudo update-alternative --config javac.
At the end you'll be asked whether to skip these checks next time -- answer y(es).
Next do
./build_ecce|tee xerxes.log && ./build_ecce |tee mesa.log && ./build_ecce |tee wxwidgets.log
sh ../../patch_script.sh && ./build_ecce|tee wxpython.log
./build_ecce|tee httpd.log && ./build_ecce|tee ecce.log
If all went well you've managed to build the ecce binaries. If not, go through wxpython.log and check for errors relating to format-security statements. Then go through ecce.log and look for issues with freetype.
What to do with the binaries? Follow one of the many ECCE installation posts on this blog, e.g.
http://verahill.blogspot.com.au/2013/08/487-version-70-of-ecce-out-now.html
NOTE that if you get ''Invalid null command." trying to execute install_ecce.v7.0.csh, install tcsh and do
tcsh install_ecce.v7.0.csh
The patch_script.sh file -- when copying, make sure to check that the lines end where they are supposed to and not broken up.
#!/bin/bash
cp ${ECCE_HOME}/build/3rdparty-dists/wxPython-src-2.8.12.1.tar.bz2 ${ECCE_HOME}/3rdparty/build/
cd ${ECCE_HOME}/3rdparty/build/
tar xvf wxPython-src-2.8.12.1.tar.bz2
rm wxPython-src-2.8.12.1.tar.bz2
cd ${ECCE_HOME}/3rdparty/build/wxPython-src-2.8.12.1/wxPython
grep -rsl "PyErr_Format(PyExc_RuntimeError, mesg)" *|xargs -I {} sed -i 's/PyErr_Format(PyExc_RuntimeError, mesg)/PyErr_Format(PyExc_RuntimeError, "%s", mesg)/g' {}
cd ${ECCE_HOME}/3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/
sed -i 's/wxLogFatalError(m)/wxLogFatalError("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogError(m)/wxLogError("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogWarning(m)/wxLogWarning("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogMessage(m)/wxLogMessage("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogInfo(m)/wxLogInfo("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogDebug(m)/wxLogDebug("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogVerbose(m)/wxLogVerbose("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogStatus(pFrame, m)/wxLogStatus(pFrame, "%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogStatus(m)/wxLogStatus("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogSysError(m)/wxLogSysError("%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogGeneric(level, m)/wxLogGeneric(level, "%s", m.c_str())/g' _misc_wrap.cpp
sed -i 's/wxLogTrace(mask, m)/wxLogTrace(mask, "%s", m.c_str())/g' _misc_wrap.cpp
cd ${ECCE_HOME}/src
grep -srl "<freetype/freetype.h>" |xargs -I {} sed -i 's,<freetype/freetype.h>,FT_FREETYPE_H,g' {}
grep -srl "freetype/" |xargs -I {} sed -i 's,freetype/,,g' {}
cd ${ECCE_HOME}/build
What I found during troubleshooting:
In files such as:
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_core_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_gdi_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_windows_wrap.cpp
./3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_controls_wrap.cpp
there are sections which look like this:
863 } else {
864 PyErr_Format(PyExc_RuntimeError, mesg);
865 }
Compiling with -Wformat-security means that you'll have to patch all those expression to
863 } else {
864 PyErr_Format(PyExc_RuntimeError, "%s", mesg);
865 }
There were similar issue with wxLog*(m) statements in other files, e.g.
3rdparty/build/wxPython-src-2.8.12.1/wxPython/src/gtk/_misc_wrap.cpp -> ("%s", m.c_str())
3093 m.Replace(wxT("%"), wxT("%%"));
3094 wxLogFatalError(m);
3095 }
..
3177 m.Replace(wxT("%"), wxT("%%"));
3178 wxLogTrace(mask, m);
3179 }
