Re: amber-developers: second draft release for AmberTools1.1

From: Scott Brozell <>
Date: Fri, 27 Jun 2008 16:45:54 -0700 (PDT)


On Fri, 27 Jun 2008, David A. Case wrote:

> On Thu, Jun 26, 2008, Volodymyr Babin wrote:
> >
> > On AIX (IBM Power 5):
> >
> > a) we do not have xlc; gcc 3.3.2 that they put there does not support
> > '-m32' flag so I had to remove this from configure_at
> Does anyone know if "-m32" is ever needed? (I.e. won't a correctly configured
> gcc (hah!) automatically compile for the local architecture?

m32 should not be needed.
This if-elseif statement is the wrong approach imo:
    if [ $x86_64 = "yes" ]; then
       cflags="$cflags -m64"
       ocflags="$ocflags -m64"
    elif [ "$processor" = "ia64" ]; then
    elif [ "$processor" = "Power Macintosh" ]; then
       cflags="$cflags -m32"
       ocflags="$ocflags -m32"

It should be :
if special reason to force 32 bits long/pointers then bla -m32
else if special reason to force 32 bits int, 64 bits long/p then bla -m64
else bla

But the reasons for the existing if-elseif statement are not
documented in the code or the logs. So changing it now will
probably break something, but imo we should change it.

> Volodymyr: what does "uname -m" return on the IBM machine? Can we at least
> special-case out the -m32 flag?
> >
> > c) nab.c:8:23: sys/fcntl.h: No such file or directory; changed to
> > #include <fcntl.h> (man page says <fcntl.h>, not <sys/fcntl.h>)
> > (fixed in amber11 cvs)
> As far as I can tell, nab.c does not actually need <fcntl.h>, which I don't
> think is part of the ISO standard. But I'm reluctant to change this, since
> it hasn't caused problems (except for the non-standard location, fixed above.)
The code depending on fcntl.h is in ifdef 0 blocks.
So I put the header inclusion in the same kind of block.


> >
> > d) nmode.c: In function `lnorm':
> > nmode.c:1172: error: `__I' undeclared (first use in this function)
> > nmode.c:1172: error: (Each undeclared identifier is reported only once
> > nmode.c:1172: error: for each function it appears in.)
> > ... replaced <complex.h> by "complex.h" - it worked for me
> > (did not commit since this is probably a local misconfiguration)
> Yannick: can we get rid of all dependence on complex.h!?!
> >
> > g) could not compile sleap even with GNU make because of boost/pthreads
> > errors (most probably unused by sleap; did not look there)
> Can you send Wei ( some of the errors? Or maybe someone can
> arrange for Wei to get access to an AIX machine. It's not a show-stopper now
> to not have IBM Power 5 support, but in the longer term, this would be nice.
> Thanks to Volodymyr for carrying out these tests.
> ...regards...dave
Received on Sun Jun 29 2008 - 06:07:53 PDT
Custom Search