This is the procedure followed to test moldy. The ebuild is masked with missing keywords. 1. EMERGING MOLDY. __________________ a. The moldy-2.16e.ebuild was modified so as to get the line as follows: KEYWORDS="~amd64" instead of KEYWORDS="x86". b. The file /etc/portage/package.keywords was edited so as to contain: app-sci/moldy ~amd64 c. The command as follows was launched: emerge moldy d. Observations: the emerge worked perfectly. 2. RUNNING MOLDY. _________________ a. The program was run with ALL check-files in /usr/share/moldy/examples: - control.argon - control.clay - control.mgclh2o - control.quartz - control.tip4p - control.tips2 - control.water b. Observations. Programs as follows gave some errors. b.1. moldy control.argon started and ended with: - failed to open file "MDTEMPX" for writing restart configuration - segmentation fault b.2. moldy control.mgclh2o started and ended with: - failed to open file "mdsave mgclh2o" for writing restart configuration - segmentation fault b.3. moldy control.tip4p started and ended with: - failed to open dump file "tip4p.dmp0" for writing c. Errors are reproducible. The 32 bits version works perfectly on a workstation as well as on openmosix-2.4.24-r4. Reproducible: Always Steps to Reproduce: 1. see details above 2. 3. Actual Results: See Section entitled "Details". Expected Results: Results were compared to the 32 bits case which works on a single workstation and on a cluster of 3 machines (openmosix-2.4.24-r3). In the case of the control.argon file (32 bits), I also observed that moldy cannot write on "MDTEMPX" but the code run until producing the radial distribution, what is the expected result. In the case of control.mgclh2o (32 bits), the prgm also stops with a failed to open file "mdsave.mgclh2o" but there is no segmentation fault. In the case of control.tip4p (32 bits), the prgm also stops with a failed to open file "tip4p.dmp0" (the reason which is printed is that "permission is denied"). This case is not specific to the amd64 case. I understand that the C code contains some errors that are not specific to the amd64 architecture. However the 2 segmentation fault are specific to what I emerged on the amd64. Many thanks for your help. This prgm is high-valuable for molecular dynamics research. My configuration is as follows: # Specifications -- Hardware: ----------------------------- Processor: AMD 64 Processor 3000+ cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 3000+ stepping : 8 cpu MHz : 2002.652 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow bogomips : 3932.16 TLB size : 1088 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp Motherboard: Asus K8V SE Deluxe Video card: Nvidia (Siluro FX 5200) Sound card: VIA Technologies, Inc. VT8233 AC97 Audio Controller Ethernet: 3Com Corporation 3c905C-TX/TX-M [Tornado] Screen: Proview 568 Hard Disk: 1 x Maxtor 40 Gb General usage: workstation - computations # Specifications -- Software: ----------------------------- Install: middle October. Software update: 11/29/2004. Poratge version: 2.0.51-r3 ## /etc/make.conf - - - - - - - - - CFLAGS="-O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="${CFLAGS}" USE="X qt kde -gtk -gnome cups foomaticdb usb alsa f77" MAKEOPTS="-j2" LINGUAS="fr" ALSA_CARDS="via82xx" SYNC="rsync://rsync.gentoo.skynet.be/gentoo-portage rsync://rsync.gentoo.skynet.be/gentoo" GENTOO_MIRRORS="ftp://ftp.gentoo.skynet.be/pub/gentoo ftp://ftp.gentoo.skynet.be/pub/gentoo-portage" ## /etc/portage/package. - - - - - - - - - - - - - This contains: /app-sci/moldy ~amd64
I dowloaded moldy-2.16e sources from http://www.ccp5.ac.uk/librar.shtml and compiled them with CC=gcc OPT=-g .configure and then, make. I expected than debugging could have been necessary. The config.log file looks normal. Running moldy on each control files does no longer produce the errors observed with the ebuild. Even not those associated with the ebuild emerged on 32 bits (x86). If this can help...(I am trying to understand the origin of observed bugs). My best, T.
This looks like an upstream bug. You might like to subscribe to the moldy mailing list and post it there at http://www.jiscmail.ac.uk/lists/MOLDY.html.
