Bug#465723: mopac7 -- please do not use g2c.
Hello, in my opinion it's a good idea to use either FORTRAN or C version of MOPAC7. Many years earlier the use of f2c and C was the only way I could make this system work, so that's why it is like we have it now. MOPAC7 is mostly fortran, plus some (system-related) C-files thrown in. So the FORTRAN compiler must be able to mix FORTRAN and C code, naturally. But otherwise there is no reason why FORTRAN could not be used. However, since I'm not really an expert FORTRAN programmer myself, and also because MOPAC7 is a very old (and also very famous!) program, I would like to be very very careful in making any changes in the program. And also I would like to keep the original, unmodified source in a separate directory in the package. So let's just maintain MOPAC7 very carefully... :) To summarize, the idea is good, and I hope we can make it work ; please tell me if I can help. I'm not very good with those configuration tools but perhaps I can do testing etc. Regards, Tommi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465723: mopac7 -- please do not use g2c.
Am Montag, den 25.02.2008, 10:49 +0200 schrieb [EMAIL PROTECTED]: in my opinion it's a good idea to use either FORTRAN or C version of MOPAC7. Yeah. This is what I had in mind. f2c was AFAIK designed to compile FORTRAN sources on systems, that do not have a FORTRAN compiler. I would therefor suggest to prefer to compile the FORTRAN sources over f2c generated C source compilation if a FORTRAN compiler is available. Many years earlier the use of f2c and C was the only way I could make this system work, so that's why it is like we have it now. No problem. MOPAC7 is mostly fortran, plus some (system-related) C-files thrown in. So the FORTRAN compiler must be able to mix FORTRAN and C code, naturally. One could write a test in configure.ac to compile a C and a FORTRAN source file and link them together (this is something, where I could need some help - will ask on the autoconf/automake lists if necessary). A very simple alternative would be to add an option to force the compilation of the C source (I guess, this will be necessary in every case). But otherwise there is no reason why FORTRAN could not be used. Sounds good to me. However, since I'm not really an expert FORTRAN programmer myself, and also because MOPAC7 is a very old (and also very famous!) program, I would like to be very very careful in making any changes in the program. The current idea IMHO does not require to patch many things - probably just a replacement of the s_copy function in fdate.c and the 3 fixes for the issues I mentioned in my mail (patch now at [1]). And also I would like to keep the original, unmodified source in a separate directory in the package. So let's just maintain MOPAC7 very carefully... :) No problem for me. A ChangeLog should tell about the differences (where we/you patched and why). To summarize, the idea is good, and I hope we can make it work ; please tell me if I can help. I'm not very good with those configuration tools but perhaps I can do testing etc. I know the autotools pretty well and I will try to provide a patch for upstream. However, I will be pretty busy till the end of April. So don't expect the patch soon (maybe if I find some time) :) Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465723: mopac7 -- please do not use g2c.
http://bugs.debian.org/465723 Hi, I wonder if we really win something by changing from libg2c0-dev to libf2c2-dev. Maybe an alternative (I'm not familiar enough here, so please don't hesitate to comment my proposal): We could take fortran/Makefile.am and put the library creation stuff into it and use the FORTRAN sources. instead of the f2c-generated C sources. That requires copying libmopac7.c and libmopac7.h from src/ into fortran and running autoreconf. So we can maybe drop the libg2c0/libf2c2 dependency completely for the library. Also the application seems to have a FORTRAN source. I attach the necessary Makefile.am to this mail. However, atm this fails for me at: esp.f:948.72: OPEN(21,STATUS='NEW') 1 Error: The STATUS specified in OPEN statement at (1) is 'NEW' and no FILE specifier is present [..] esp.f:2357.72: OPEN(21,STATUS='NEW') 1 Error: The STATUS specified in OPEN statement at (1) is 'NEW' and no FILE specifier is present I'm not familiar with FORTRAN and I miss time to examine this atm. Reading the docs I think, maybe a scratch file should be opened, so I removed the STATUS stuff and then it compiles some more files. But it stops at: symtrz.f:1045.30: DATA TOLER,IFRA / 0.1, ''/ 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to INTEGER(4) After fixing this one and a typo (s/NAMES/NAME) a few lines later (CCed Tommi Hassinen with this mail), it compiles, but it fails with: .libs/fdate.o: In function `fdate_': /usr/local/src/Packages/mopac7/mopac7-1.13/fortran/fdate.c:27: undefined reference to `s_copy' collect2: ld returned 1 exit status This is because fortran/fdate.c uses s_copy(). If we can replace this one too (not hard): Is there anything that prevents us from directly compiling the FORTRAN sources to create the library and program? CCed Tommi Hassinen Regards, Daniel SUBDIRS = c_src_bak EXTRA_DIST = \ aababc.faddfck.faddhcr.faddnuc.f \ analyt.fanavib.faxis.f block.f \ bonds.f brlzon.fbtoc.f calpar.f \ capcor.fcdiag.f chrge.f cnvg.f \ compfg.fconsts.fcqden.f datin.f \ dcart.f delmol.fdelri.f denrot.f \ densit.fdepvar.fderi0.f deri1.f \ deri21.fderi22.fderi23.fderi2.f \ deritr.fderiv.f dernvo.fders.f \ dfock2.fdfpsav.fdgemm.f dgemv.f \ dger.f dgetf2.fdgetrf.fdgetri.f \ diag.f diat2.f diat.f diegrd.f \ dielen.fdiis.f dijkl1.fdijkl2.f \ dipind.fdipole.fdlaswp.fdofs.f \ dot.f drc.f drcout.fdtrmm.f \ dtrmv.f dtrsm.f dtrti2.fdtrtri.f \ dvfill.fef.fenpart.fesp.f \ etime.c exchng.ffdate.c ffhpol.f \ flepo.f fmat.f fock1.f fock2.f \ force.f formxy.fforsav.fframe.f \ freqcy.fgeout.f geoutg.fgetgeg.f \ getgeo.fgetsym.fgettxt.fgmetry.f \ gover.f greenf.fgrid.f h1elec.f \ haddon.fhcore.f helect.fhqrii.f \ ijkl.f ilaenv.finitsv.finterp.f \ iter.f jcarin.flinmin.flocal.f \ locmin.flsame.f makpol.fmamult.f \ matou1.fmatout.fmatpak.fmecid.f \ meci.f mecih.f mecip.f moldat.f \ molval.fmopac7lib.f mullik.f \ mult.f nllsq.f nuchar.fparsav.f \ partxy.fpathk.f paths.f perm.f \ polar.f powsav.fpowsq.f prtdrc.f \ quadr.f react1.freada.f readmo.f \ refer.f repp.f rotate.frotat.f \ rsp.f search.fsecond.fsetupg.f \ SIZES SIZES.orig solrot.fswap.f \ sympro.fsymtry.fsymtrz.fthermo.f \ timer.f timout.fupdate.fupsurf.f \ vecprt.fwritmo.fwrtkey.fwrttxt.f \ xerbla.fxyzint.f lib_LTLIBRARIES= libmopac7.la libmopac7_la_LDFLAGS = -version-info 1:13:0
Bug#465723: mopac7 -- please do not use g2c.
On Mon, Feb 25, 2008 at 04:25:57AM +0100, Daniel Leidert wrote: I wonder if we really win something by changing from libg2c0-dev to libf2c2-dev. Maybe an alternative (I'm not familiar enough here, so please don't hesitate to comment my proposal): We could take fortran/Makefile.am and put the library creation stuff into it and use the FORTRAN sources. instead of the f2c-generated C sources. That requires copying libmopac7.c and libmopac7.h from src/ into fortran and running autoreconf. So we can maybe drop the libg2c0/libf2c2 dependency completely for the library. Also the application seems to have a FORTRAN source. This is the best way ahead. After some consulting on #gfortran, I was advised not to use f2c, but prefer to provide the f2c calls in the source of mopac7. Depending on g2c is not an option because the gfortran transition would imply not using g2c. I'm not familiar with FORTRAN and I miss time to examine this atm. Reading the docs I think, maybe a scratch file should be opened, so I removed the STATUS stuff and then it compiles some more files. But it stops at: I am also not too good, but I'll try giving it a shot later if the maintainers don't get back to it. symtrz.f:1045.30: DATA TOLER,IFRA / 0.1, ''/ 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to INTEGER(4) After fixing this one and a typo (s/NAMES/NAME) a few lines later (CCed Tommi Hassinen with this mail), it compiles, but it fails with: .libs/fdate.o: In function `fdate_': /usr/local/src/Packages/mopac7/mopac7-1.13/fortran/fdate.c:27: undefined reference to `s_copy' collect2: ld returned 1 exit status This is because fortran/fdate.c uses s_copy(). If we can replace this one too (not hard): Is there anything that prevents us from directly compiling the FORTRAN sources to create the library and program? No, and that would be waaay better than depending on the obsolete f2c, though I am not the deciding authority here. :-) Thanks! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Bug#465723: mopac7 -- please do not use g2c.
Package: mopac7 Version: 1.13-1 Severity: important User: [EMAIL PROTECTED] Usertags: gfortran Hi! I would request you to please shift Build-Depends to use the new gfortran based Lapack and Blas packages in order to phase out packages dependent on the old g2c (g77). In this regard, I would request you to refer to: http://wiki.debian.org/GfortranTransition Thank you. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
