Le lundi 10 octobre 2005 à 11:29 +0300, Tommi Hassinen a écrit : > On Sun, 9 Oct 2005, Michael Banck wrote: > > >> I could wait so that the recent 64-bit OpenGL changes are tested. > > > > I would happily put those into Debian, but I got stuck with the mopac > > changes. Could you release mopac first perhaps? (it does not seem to > > depend on the others), then I could upload the 64bit changes to > > libghemical and ghemical and report back. > > Hello, > > I made an "release candidate" version of mopac7 for download here: > > http://www.uku.fi/~thassine/tmp/mopac7-1.10rc1.tgz > > Please read the INSTALL file carefully ; I have not yet found a way how to > compile this with a compiler newer than gcc-3.2. The problem here is that > the C code is generated by the f2c converter tool from fortran, and the > current versions of this converter seems to generate code that is not > accepted by gcc-3.3, gcc-3.4 or gcc-4.0. So I have simply used > > CC=gcc-3.2 ./configure > > to make thigs work. The libtool problem is still there. If I run make, aclocal is called: /home/jean/sources/installs/mopac7-1.10rc1/missing --run aclocal-1.8 This breaks things. This occurs, because configure.ac is more recent than aclocal.m4. Makefile.in should also be more recent than configure.ac otherwise automake is also called. To make things work, I had to type: touch aclocal.m4 touch Makefile.in touch configure About the compiler problem, even if things work with gcc-3.2, I am not certain that they are reliable. Take ME08B in diag.f. It is defined as: SUBROUTINE ME08B (A,Q,B,N,IA) REAL A(IA,*),Q(2,*),B(IA,*) and is called from ME08B: 50 CALL ME08B (A(K,K),Q(K),A(I,K),N-K+1,IA*2) where A and Q are complex, not real. I have forgotten fortran and I do not know how things can work, but the code generated by f2c will most likely fail because in _me08a, the c compiler uses the extern declaration where the variables are complex* and the real code use real* arrays. There are no solutions to that other than rewriting the code :-( Best regards, Jean