* 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
the recommended method is to use#include <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 <>)#include FT_FREETYPE_H
* 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
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.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)'
* 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:
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)Exceeds maximum C shell command length of 256 characters
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:
Compiling with -Wformat-security means that you'll have to patch all those expression to863 } else { 864 PyErr_Format(PyExc_RuntimeError, mesg); 865 }
There were similar issue with wxLog*(m) statements in other files, e.g.863 } else { 864 PyErr_Format(PyExc_RuntimeError, "%s", mesg); 865 }
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 }
