Brian Barrett wrote:
> LAM 7.0, in anticipation for a thread hot MPI, enables thread support
> by default. We only support THREAD_SINGLE to THREAD_SERIALIZED, but
> that's enough to require some locking support. So LAM 7.0 links in
> all the pthread code (and mpicc/mpiCC/mpif7 add them as well). Any
> version of LAM previous to LAM 7.0 probably would not have done this.
>
> You might try compiling LAM 7.0 with the --without-threads configure
> flag and see if that solves the problem. That would lead me to
> believe that the issue is just a difference in behavior of the dl
> library when there is pthread support linked in.
That was a good idea. It worked. Thank you.
The thread support included with the LAM runtime tools (lamboot, lamd,
mpirun) apparently is not part of the problem. When I used the
non-thread version of those tools, my app still failed. I had to
recompile with the non-thread version of mpiCC to get it to run.
Conversely, I can run the non-thread version of my app on the
thread-supporting version of lamboot, lamd, and mpirun with no problem.
I don't need thread support, but I think you should consider how to
configure your tools to support both threaded and non-threaded
applications. The only difference I saw in mpiCC was the addition of
-pthread in building my application for the thread-supporting LAM. That
must have been the killer for dlerror.
Maybe you could consider an option for mpiCC to tell it to leave off the
-pthread option. Or you could just leave it to the user to add the
appropriate options for his particular compiler and linker, when he
wants thread support.
--
Dick Hadsell 914-259-6320 Fax: 914-259-6499
Reply-to: hadsell_at_[hidden]
Blue Sky Studios http://www.blueskystudios.com
44 South Broadway, White Plains, NY 10601
|
