wiki:TCTGccUpgrade4.4
Last modified 9 years ago Last modified on 08/24/2010 11:42:43 AM

Version Upgrades to Current 3rd Party Software

Robert and MikeJ, 23 August 2010

Email 1

... and the answer is that Mike wins by a knockout (or, more technically, an internal error in g++).

We do need to resolve this, but in the meantime, meas::algorithms trunk is a problem. It does build -O0, so with trunk sconsUtils you can say:

scons opt=3 noOptFiles=Shapelet.cc

Mike: do you have access to g++ 4.3.5?

R

> $ g++ --version
> g++ (GCC) 4.3.5
> Copyright (C) 2008 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ g++ -o src/Shapelet.os -c -g -Wall -O3 -DLSST_HAVE_TR1=1
+-DLSST_LITTLE_ENDIAN=1 -fPIC
+-I/data/ana/products/Linux64/external/boost/1.37.0/include
+-I/data/ana/products/Linux64/base/3.1.4/include
+-I/data/ana/products/Linux64/external/python/2.5.2/include/python2.5
+-I/data/ana/products/Linux64/external/python/2.5.2/include
+-I/data/ana/products/Linux64/external/cfitsio/3006.2/include
+-I/data/ana/products/Linux64/external/wcslib/4.4.4/include
+-I/data/ana/products/Linux64/external/xpa/2.1.7b2/include
+-I/data/ana/products/Linux64/external/minuit2/5.22.00+1/include
+-I/data/ana/products/Linux64/external/gsl/1.8/include
+-I/data/ana/products/Linux64/pex_exceptions/3.2.2/include
+-I/data/ana/products/Linux64/utils/3.4.5/include
+-I/data/ana/products/Linux64/daf_base/3.2.14/include
+-I/data/ana/products/Linux64/pex_logging/3.4.1/include
+-I/data/ana/products/Linux64/security/3.2.2/include
+-I/data/ana/products/Linux64/pex_policy/3.5.2/include
+-I/data/ana/products/Linux64/daf_persistence/3.!
 3.14/include -I/data/ana/products/Linux64/daf_data/3.2.4/include
+-I/data/ana/products/Linux64/external/eigen/2.0.0/include
+-I/data/ana/products/Linux64/external/fftw/3.2.2/include
+-I/home/rhl/LSST/afw/include -Iinclude src/Shapelet.cc
> src/Shapelet.cc: In member function 'double
+lsst::meas::algorithms::Shapelet::evaluateAt(double, double)':
> src/Shapelet.cc:176: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> 

Email 2

A workaround is:

>     double Shapelet::evaluateAt(double x, double y)
>     {
> #if 0                                   // crashes g++ 4.3.5
>         return pImpl->evaluateAt(x,y);
> #else
>         return evaluateAt(lsst::afw::geom::makePointD(x, y));
> #endif
>     }

Should I commit this? I hate to see #if ... #endif workarounds in code, but...

R

(Mike: the problem is the Eigen::VectorXcd? constructor; this also makes the problem go away:

> 
> #if 0
>             CDVector zList(1);          // crashes g++ 4.3.6
> #else
>             CDVector zList;
> #endif

A simple single-line program calling this constructor doesn't expose the bug. )

Russell Owen, 23 August 2010

Regarding tcl/tk: matplotlib cares and we should use a released version that is compatible with our Python. Thus:

  • the latest Tcl/Tk? 8.5.x if we use Python 2.6
  • the latest (still old) Tcl/Tk? 8.4.x if we use Python 2.5
  • IIRC Python 2.7 is required to use Tcl/Tk? 8.6.

In any case, the important thing is to get a stable version of Tcl/Tk? that works, not to get the latest and greatest.

Lynne Jones, 20 August 2010

And a question from RHL as to why we care about tcl/tk: "does matplotlib care?"

I don't know if this is the only reason the project as-a-whole cares, but matplotlib does need tcl/tk. The version that is currently available with the stack is quite old and does not compile on a mac. However, I don't know if there are new features with the newer tcl/tk or if just upgrading would fix the compilation issues.

Mike Jarvis, 20 aug 2010

I would also like icc to be supported.

Jim Bosch, 18 Aug 2010

Eigen 2.0.15 is a bugfix-only release that should not break any existing code, and fixes several bugs and performance problems present in Eigen 2.0.0.

Eigen 3.0 is much further away and is not worth waiting for at this point.

Martin Dubkovsky, 3 Aug 2010

Provided the following list of upgrades he recommends:

  • Eigen 2.0.15 (or wait a few months for 3.0)
  • Boost 1.42 [We should probably go to 1.44 which has just been released. RHL]
  • gcc 4.4
  • swig >= 2.0.0

Russell Owen, 3 Aug 2010

Provided the following additions to Martin's list:

  • icc (for MAC users)
  • scons 2.0 or at least 1.3
  • python 2.6.x with TCL/TK 8.5.x (considered python 2.7 too green) [Why do we care about the tcl/tk version? Does matplotlib care? RHL]

Upgrade to GCC 4.4

This records the comments on GCC 4.4 upgrades. It needs to become a Proposal.

From: Mike Jarvis, 14 Apr 2010

Since I've recently struggled a bit to compile with gcc 4.4, I'll share a bit of what I learned.

The main problem I had was with boost's gil::at_c conflicting with its mpl::at_c. Basically when the argument to a gil routine includes an object in the mpl namespace, gcc 4.4 (correctly) pulls the mpl namespace into scope. And when the gil routine then calls at_c(...), there is an ambiguity about which function to use.

So I went into the boost files for gil and everywhere they had at_c, I replaced it with gil::at_c. This fixed the problem.

Hopefully (and probably), boost has fixed this with a more recent version, but I haven't checked. Otherwise, I suppose we need to have an lsst-specific boost distribution that fixes this problem.

From: Ray Plante, 14 Apr 2010

FYI: I've installed gcc 4.4.3 on the cluster and am in the process of trying to get a (partial) stack built with it, so that people can play with it. Various packages fail at the moment (currently, pex_policy is the blocker).

I will note that gcc 4.4.* now requires the GMP and MPFR packages (multi-precesion libraries) to build and run.

From: Russell Owen 12 Apr 2010

I believe the NCSA official gcc is 4.3.<something>. The next step is gcc 4.4.x. One argument in favor of gcc 4.4.x that is that it is the ONLY modern gcc RPM available for many common linux distributions. I hope we will adopt it as our reference compiler once DC3b settles down a bit. I can write a proposal if you want, but it's not going to say much beyond that.