Brian,
Yes I understand that. I don't transfer the object files from my
development machine to the cluster. I can compile on the cluster as
well, but I like to do small test runs on my local machine. Yes I
think you are right about the linking issues being a G++ problem. In
this case, does it make sense to use LAM 7.1.1 on my test machine
(since it works with gcc 4.0)? Otherwise, I may try installing the
older gcc 3.2 compiler (which I believe is the same compiler that our
cluster uses).
Lucas
mailto:lucshaw_at_[hidden]
Sunday, December 4, 2005, 3:19:39 PM, you wrote:
BB> First, a note that you can't build with one version of LAM and run
BB> with another version - it will not work. It looks like you have a
BB> problem with the configuration of your compile machine - this is not
BB> a LAM problem. This usually happens when you have an improperly
BB> installed compiler or because you are trying to use a library built
BB> with one version of G++ and linking it into an application compiled
BB> with another version of G++. GCC 3.x and GCC 4.x are not link
BB> compatible for C++.
BB> Hopefully this gives you some idea of where to start....
BB> Brian
BB> On Dec 4, 2005, at 5:15 PM, Lucas R. Shaw wrote:
>> Brian,
>>
>> I am stuck with LAM 6.5.9 since that is what our cluster uses (though
>> I probably could just use LAM 7.1 on my machine and the code would
>> compile and run on the cluster fine as long as I only use features in
>> LAM 6.5.9).
>>
>> The compilation of LAM was done as per the Chapter 3 For the Impatient
>> chapter in the installation manual. I set CC to gcc, CXX to g++, and
>> FC to g77, then ran ./configure, then make, then make install.
>>
>> The errors I am running into have to do with the STL Allocators (I
>> think). Here's a sample. This is when trying to install with mpiCC
>> (which uses g++ 4.0.2):
>>
>> mpiCC -g -Wall -c Utility.cpp Utility.o
>> mpiCC -g -Wall -c Plane.cpp Plane.o
>> mpiCC -g -Wall -c DailyFlights.cpp DailyFlights.o
>> mpiCC -g -Wall -c City.cpp City.o
>> mpiCC -g -Wall -c FlightSim.cpp FlightSim.o
>> mpiCC -g -Wall Utility.o Plane.o DailyFlights.o City.o FlightSim.o -
>> L/usr/lib -lmpi -llam -o vaccSim
>> DailyFlights.o
>> (.gnu.linkonce.t._ZN9__gnu_cxx6__poolILb1EE18_M_initialize_onceEv
>> [__gnu_cxx::__pool<true>::_M_initialize_once()]+0x22): In function
>> `__gnu_cxx::__pool<true>::_M_initialize_once()':
>> /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/
>> ext/mt_allocator.h:317: undefined reference to
>> `__gnu_cxx::__pool<true>::_M_initialize()'
>> DailyFlights.o
>> (.gnu.linkonce.t._ZN9__gnu_cxx13__common_poolINS_6__poolELb1EE11_S_get
>> _poolEv[__gnu_cxx::__common_pool<__gnu_cxx::__pool,
>> true>::_S_get_pool()]+0x1a): In function
>> `__gnu_cxx::__common_pool<__gnu_cxx::__pool, true>::_S_get_pool()':
>> /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/
>> ext/mt_allocator.h:386: undefined reference to `__cxa_guard_acquire'
>> DailyFlights.o
>> (.gnu.linkonce.t._ZN9__gnu_cxx13__common_poolINS_6__poolELb1EE11_S_get
>> _poolEv[__gnu_cxx::__common_pool<__gnu_cxx::__pool,
>> true>::_S_get_pool()]+0x43):/usr/lib/gcc/i386-redhat-linux/
>> 4.0.2/../../../../include/c++/4.0.2/ext/mt_allocator.h:386:
>> undefined reference to
>> `__cxa_guard_release'
>> DailyFlights.o
>> (.gnu.linkonce.t._ZN9__gnu_cxx10__mt_allocI5PlaneNS_20__common_pool_po
>> licyINS_6__poolELb1EEEE8allocateEjPKv[__gnu_cxx::__mt_alloc<Plane,
>> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate
>> (unsigned int, void const*)]+0x90): In function
>> `__gnu_cxx::__mt_alloc<Plane,
>> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate
>> (unsigned int, void const*)':
>> /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/
>> ext/mt_allocator.h:678: undefined reference to
>> `__gnu_cxx::__pool<true>::_M_get_thread_id()'
>> DailyFlights.o
>> (.gnu.linkonce.t._ZN9__gnu_cxx10__mt_allocI5PlaneNS_20__common_pool_po
>> licyINS_6__poolELb1EEEE8allocateEjPKv[__gnu_cxx::__mt_alloc<Plane,
>> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate
>> (unsigned int, void
>> const*)]+0x12b):/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../
>> include/c++/4.0.2/ext/mt_allocator.h:698: undefined reference to
>> `__gnu_cxx::__pool<true>::_M_reserve_block(unsigned int, unsigned
>> int)'
>> DailyFlights.o
>> (.gnu.linkonce.t._ZN9__gnu_cxx10__mt_allocI5PlaneNS_20__common_pool_po
>> licyINS_6__poolELb1EEEE10deallocateEPS1_j[__gnu_cxx::__mt_alloc<Plane,
>> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>> >::deallocate(Plane*, unsigned int)]+0x59): In function
>> `__gnu_cxx::__mt_alloc<Plane,
>> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true>
>> >::deallocate(Plane*, unsigned int)':
>> /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/
>> ext/mt_allocator.h:717: undefined reference to
>> `__gnu_cxx::__pool<true>::_M_reclaim_block(char*, unsigned int)'
>> collect2: ld returned 1 exit status
>> make: *** [vaccSim] Error 1
>>
>> Like I said, I think the problem lies in linking with the STL
>> libraries, but I am not sure. Thanks for your help. I might just try
>> installing 7.1 instead just so I can try out my programs locally.
>>
>> Lucas
>> mailto:lucshaw_at_[hidden]
>>
>> Saturday, December 3, 2005, 1:00:16 PM, you wrote:
>>
>> BB> On Dec 2, 2005, at 9:19 PM, Lucas R. Shaw wrote:
>>
>>>> I am trying to compile some code using MPI on my freshly installed
>>>> Fedora4 OS that compiles just fine normally (i.e. I have
>>>> compiled it
>>>> before). I don't know exactly what the problem is, but the
>>>> executable won't link to some of the STL classes. I have the
>>>> latest
>>>> version of gcc, g++, etc. Are there any issues with using these
>>>> new
>>>> compilers with LAM/MPI 6.5.9? I am hoping it is just a
>>>> configuration
>>>> issue that I can resolve, but I am running out of options. Right
>>>> now, I am considering installing the old gcc 3.2 compiler that
>>>> worked just fine before in RedHat 9.
>>
>> BB> We no longer maintain the LAM 6.5.x series of releases, so we've
>> BB> never tested LAM 6.5.9 with the GCC 4 series of compilers. As
>> far as
>> BB> we know, however, there are no problems with the 7.1.x series of
>> BB> releases with modern GCC compilers. I'd recommend upgrading to
>> LAM
>> BB> 7.1.1, if possible.
>>
>> BB> If you must use LAM 6.5.9 for some reason, it would be helpful to
>> BB> know what errors you are seeing. In particular, the exact error
>> BB> message would be useful in figuring out where the problem lies.
>> BB> Information on how LAM was built would also be useful.
>>
>> BB> Brian
|
