[gmx-users] install problem

[John Mercer]

Hi,

I am a beginning user of GROMACS, and am just now trying to get a  
functional installation.  There is something not quite right about  
the installations I have tried.  I have spent considerable time  
testing ideas about what might be the problem, but have not nailed  
it.  I am hoping someone will have a suggestion (perhaps obvious)  
that will reduce the time I am spending getting GROMACS operational.   
I can duplicate the problem with multiple GROMACS subprograms but  
will only refer to "luck" (luck.c).

Platform:  Mac OS X 10.4.10

Installations tried:
	1. Binary package install of gromacs-3.3.dmg.gz (from www.gromacs.org)
	2. Fink with compile; first standalone, then remove standalone and  
install openmpi
In both cases, GMXRC.bash is sourced in "profile".
	3. All installations exhibit the same problem so I'll stick to fink.
	
Indications:
	1. luck -c executes with a segmentation fault from any directory.
	2. /sw/bin/luck -c executes normally from any directory. (/usr/local/ 
bin installation exhibits same problem.)
	3. Not a UNIX PATH problem as non GROMACS functions in /sw/bin  
execute normally from the same shell.
	4. A shorter PATH value does function normally without regard to  
where fink subdirectories are placed in the PATH, causing me to  
wonder whether PATH is parsed in code with a fixed memory variable.


Diagnostics:
	1. luck -c prints the GROMACS banner before it's segmentation fault
	2. /sw/bin/luck -c prints the banner, a wording for the GROMACS  
acronym, a version number, the authors, software information, and a  
user friendly quote.
	3. Comparing 1. & 2. with luck.c, copyrite.c, etc suggestions that a  
call to bromacs() in CopyRight() migh be where the problem manifests  
itself.
	4. The call sequence could be CopyRight() -> bromacs() -> pukeit() - 
 > low_lib_libopen() -> low_libfn().
	5. Note: I haven't tested all these functions to verify they are  
each involved, but suggest them as a hypothesis based on the output  
and looking at traces of system calls.
	6. One thing that puzzles me is that it looks as if low_libfn()  
expects "GMXLIB" as an environment variable, but the script  
GMXRC.bash sets up "GMXLDLIB as the library environment variable.

Whatever the problem, the program executes from any directory, but  
only with the full path specified does it execute without a  
segmentation fault.


Any advice on how to fix this problem would be greatly appreciated.

John Mercer