The messages are warnings, and they're saying that a symbol from lammpi is being used instead of one from the base system, so I wouldn't assume breakage has occurred.
Does Gadget have any test cases where there's a solution to check against? Or even a "make check" or "make test" option that you can use? Todd Krause wrote: > > Hi Alexander, > > Sorry to fill your inbox. But it seems like I spoke too soon. When I > build Gadget2 again, this time using /sw/bin/lam-mpicc as the > compiler, I get the following warnings: > > /usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may > result in errors or different symbols being used > symbol _szone_check_counter used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > symbol _szone_check_modulo used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > symbol _scalable_zone_info used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > symbol _szone_check_start used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > symbol _malloc_jumpstart used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > symbol _malloc_freezedry used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > symbol _create_scalable_zone used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > symbol _scalable_zone_statistics used from dynamic library > /sw/lib/lammpi/libmpi.dylib(scalable_malloc.o) not from earlier > dynamic library /usr/lib/libSystem.B.dylib(scalable_malloc.So) > > But then it seems I *am* able to run the program. I just have to make > sure I'm using the correct mpirun, namely lam-mpicc: > > 08:43 PM btpro:Gadget2> lamboot > LAM 7.1.2/MPI 2 C++/ROMIO - Indiana University > > 08:45 PM btpro:Gadget2> /sw/bin/lam-mpirun -np 1 ./Gadget2 > ./parameterfiles/galaxy.param > Note: This is a massively parallel code, but you are running with 1 > processor only. > Compared to an equivalent serial code, there is some unnecessary > overhead. > > This is Gadget, version `2.0'. > > Running on 1 processors. > > Allocated 25 MByte communication buffer per processor. > > Communication buffer has room for 504122 particles in gravity computation > Communication buffer has room for 204800 particles in density computation > Communication buffer has room for 163840 particles in hydro computation > etc. > > I'm wondering if you have any idea what I can about the build > warnings. I'm worried that they mean there's a possibility that even > though I'm getting data out of Gadget2, I'm getting garbage in essence. > > Anyhow, I know that's not really a Fink question, so if you don't know > or don't have time, that's fine. My other questions about being able > to remove the programs Fink installed still stand (though perhaps I > won't remove them just yet, if I can make sure I'm not getting garbage > out of Gadget2). > > Sorry to keep pestering you. Thanks very much for all your help. > > Best, > Todd > > On Fri, 20 Jul 2007, Alexander K. Hansen wrote: > >> Todd Krause wrote: >>> Hi, >>> >>> Could someone please give me advice on how to resolve the following >>> error I get with FFTW 2.1.5? When I try to run Gadget2, a parallel >>> cosmology code that uses MPI and FFTW, I get >>> >>> 10:52 AM btpro:Gadget2> mpd & >>> [1] 457 >>> 10:52 AM btpro:Gadget2> mpirun -np 1 ./Gadget2 >>> ./parameterfiles/galaxy.param >>> dyld: Symbol not found: _lam_mpi_float >>> Referenced from: /sw/lib/libsfftw_mpi.2.dylib >>> Expected in: flat namespace >>> >>> 10:53 AM btpro:Gadget2> mpdallexit >>> >>> The first and last lines are starting and quitting the MPI >>> environment. My problem was that in order to "make" Gadget2, I >>> needed FFTW 2.1.5 with MPI enabled, and an MPI package. I installed >>> MPICH2 myself in /usr/local, and the unstable fftw-mpi via Fink. >>> The latter also installed gcc4.2 and lammpi. Now I get Gadget2 to >>> "make", but it won't execute. Does anyone have any suggestions on >>> how to fix this? >>> >>> I'm working on a MacBook Pro, and I have Xcode 2.4.1 installed -- in >>> fact I *reinstalled* Xcode to see if this would fix the linking >>> problem, but to no avail. >>> >>> Thanks for any suggestions, >>> Todd >>> >>> >> Did you reinstall Xcode _and_ rebuild Gadget2 (or any of the other >> packages)? >> >> One thing to check is whether your libfftw got misbuilt. What do you >> get from >> >> otool -L /sw/lib/libsfftw_mpi.2.dylib >> >> ? >> >> -- >> Alexander K. Hansen >> Fink User Liaison/Documenter >> akh AT finkproject DOT org >> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fink-beginners mailing list Fink-beginners@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-beginners
