On 9/6/06 9:05 AM, "Ralf Wildenhues" <ralf.wildenh...@gmx.de> wrote:
>> I was testing with a trivial "hello world" MPI application; i.e., one that >> I had compiled with mpicc and was running with "mpirun -np 2 --mca btl >> openib hello". Hence, I was testing against installed trees of Open MPI. >> I took care to "rm -rf" the installation tree before testing each so that >> there would be no kruft left from prior installs. > > OK, I can only assume that with 1.5.22, some code links against > libibverbs, or loads it earlier at runtime, so that the symbol is > present. In any case I wonder why mthca.so isn't linked directly > against libibverbs (maybe useful to suggest that to upstream). I'm not sure. I think it's a plugin; I'll ask. > To find out the culprit, here's a couple of quick (well) ways: > diff build-with-lt1.5/Makefile build-with-lt2.1a/Makefile > > and look for differences in library link variables. Otherwise, the > config.log outputs should give clues. I did that early in the ticket and didn't see much of a difference. However, while typing this, Gleb just replied about RTLD_GLOBAL. I'll go comment on that... > To give you some more hints for possible causes: ompi_info could have a > different set of RPATH entries, or different NEEDED libraries than your > test executable; if any of those cause libibverbs.so to be loaded, then > the symbol would be visible already. Maybe your test executables even > have different RPATHs or NEEDED libs (find out with 'objdump -p' and > ldd)? > >> I've attached 2 tarballs to the bug (you have to go to the URL of the bug >> to get them; they are not included in the mails): > > If there are tarballs available at > http://svn.open-mpi.org/trac/ompi/ticket/334, then I'm too blind to find > them. Would that be elsewhere? It's because I'm a bozo and forgot to attach them. They're now near the top of the ticket in the "Attachments" section. Sorry about that... http://svn.open-mpi.org/trac/ompi/ticket/334 -- Jeff Squyres Server Virtualization Business Unit Cisco Systems
