On 13/03/08 18:33 -0600, Brian Barrett wrote:
> Justin -
>
> Do you mind explaining the problem and why the patch solves the
> problem? I don't want to commit anything I don't understand and
> unfortunately don't have time to really dig into LAM these days.
>
> On Mar 11, 2008, at 6:27 PM, Justin Bronder wrote:
>
> > lam-mpi-7.1.4 builds and installs correctly when -Wl,--as-needed is in
> > LDFLAGS, however attempting to use any of the compiler wrappers
> > fails with
> > unresolved symbols [1]. I'm currently using the attached patch,
> > which appears to
> > resolve the problem (at least for me). Hopefully I haven't done
> > anything too
> > foolish and if there is another release this could be included.
> >
> > Of course, if I have done something foolish, please let me know so I
> > can
> > stop!
> >
> > Thanks,
> >
> > [1] Yes, it's 7.1.2, but the problem persisted in 7.1.4 :)
> > http://bugs.gentoo.org/show_bug.cgi?id=199835
> >
Sure, the problem is that when using the LDFLAGS="-Wl,--as-needed" ld does
not include symbols from libmpi and liblam needed by liblamf77mpi.
Normally this is ok because the linker will search all libraries for
missing symbols, however with the aforementioned flag, this doesn't happen.
The patch changes the build process by building a temporary liblamf77mpi
(similar to what is done with libmpi), and later, once libmpi and liblam are
built, links this temporary library with the other two to create the full
liblamf77mpi.
To see the problem, configure with LDFLAGS="-Wl,--as-needed" and then attempt
to compile any mpi program with the same LDFLAGS.
To summarize, here's the difference:
patched:
jbronder_at_mejis ~/src/mpi-examples $ ldd /usr/lib/mpi/mpi-lam/usr/lib64/liblamf77mpi.so
linux-vdso.so.1 => (0x00007fffcedfe000)
libmpi.so.0 => /usr/lib64/mpi/mpi-lam/usr/lib64/libmpi.so.0 (0x00002ba2dc011000)
liblam.so.0 => /usr/lib64/mpi/mpi-lam/usr/lib64/liblam.so.0 (0x00002ba2dc2b7000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002ba2dc525000)
libc.so.6 => /lib/libc.so.6 (0x00002ba2dc740000)
libdl.so.2 => /lib/libdl.so.2 (0x00002ba2dca80000)
libtorque.so.2 => /usr/lib/libtorque.so.2 (0x00002ba2dcc84000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00002ba2dceda000)
libutil.so.1 => /lib/libutil.so.1 (0x00002ba2dd0f2000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
jbronder_at_mejis ~/src/mpi-examples $ mpicc hello_c.c
jbronder_at_mejis ~/src/mpi-examples $
unpatched:
jbronder_at_mejis ~/src/mpi-examples $ ldd /usr/lib/mpi/mpi-lam-unpatched/usr/lib64/liblamf77mpi.so
linux-vdso.so.1 => (0x00007ffff5ffe000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b53b4df3000)
libc.so.6 => /lib/libc.so.6 (0x00002b53b500f000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
jbronder_at_mejis ~/src/mpi-examples $ mpicc hello_c.c
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so: undefined reference to `ah_find'
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so: undefined reference to `lam_ksignal'
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so: undefined reference to `lam_arr_append'
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so: undefined reference to `ah_delete'
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so: undefined reference to `lam_errorstr'
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so: undefined reference to `lam_ssi_cr_did'
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so: undefined reference to `lam_rtrnameget'
...
This is a long list.
For more information about as-needed issues, see this write-up, which
explains it far better then I could ever hope to.
http://www.gentoo.org/proj/en/qa/asneeded.xml
By the way, the same issue occurs with the f77 and f90 wrappers in openmpi,
however the solution is not as simple. (Read that as, the same trick pulled
here isn't working for me).
--
Justin Bronder
- application/pgp-signature attachment: stored
|
