On Jun 11, 2004, at 4:41 PM, Richard Hadsell wrote:
> 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.
It's actually more complicated than that. You can mix and match
(although we don't support it) threaded lamboot,mpirun,lamhalt with
no-threaded mpicc/libmpi.a. But to support app-level threading, we
need to have pthreads primitives in libmpi.a. If we have pthreads
primitives in libmpi.a, we need to have -pthread added by mpicc. We
could probably play some games and have two versions of libmpi.a or
multiple symbols or all kinds of horrible games. But the games tend to
be OS-specific, and we just don't have the manpower to support those
features. So we are left with the current state of affairs.
Brian
--
Brian Barrett
LAM/MPI developer and all around nice guy
Have a LAM/MPI day: http://www.lam-mpi.org/
|
