|
List Info
Thread: LAM: Supporting -Wl,--as-needed in LDFLAGS.
|
|
| LAM: Supporting -Wl,--as-needed in
LDFLAGS. |
|
2008-03-11 19:27:43 |
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
--
Justin Bronder
diff -urN lam-7.1.4/configure.in
lam-7.1.4-patched/configure.in
--- lam-7.1.4/configure.in 2006-06-24 16:42:47.000000000
-0400
+++ lam-7.1.4-patched/configure.in 2008-03-11
00:03:26.000000000 -0400
 -2482,6
+2482,7
share/libmpi/Makefile
share/liblam/Makefile
+ share/liblamf77mpi/Makefile
share/dynamic-ssi/Makefile
share/dynamic-ssi/boot/Makefile
diff -urN lam-7.1.4/share/liblamf77mpi/Makefile.am
lam-7.1.4-patched/share/liblamf77mpi/Makefile.am
--- lam-7.1.4/share/liblamf77mpi/Makefile.am 1969-12-31
19:00:00.000000000 -0500
+++
lam-7.1.4-patched/share/liblamf77mpi/Makefile.am 2008-03-11
00:37:26.000000000 -0400
-0,0
+1,32
+# -*- makefile -*-
+#
+# Copyright (c) 2001-2003 The Trustees of Indiana
University.
+# All rights reserved.
+# Copyright (c) 1998-2001 University of Notre Dame.
+# All rights reserved.
+# Copyright (c) 1994-1998 The Ohio State University.
+# All rights reserved.
+#
+# This file is part of the LAM/MPI software package. For
license
+# information, see the LICENSE file in the top level
directory of the
+# LAM/MPI source distribution.
+#
+# $Id: 7.1.4-as-needed.patch,v 1.1 2008/03/11 14:34:42
jsbronder Exp $
+#
+
+include $(top_srcdir)/config/Makefile.options
+
+if WANT_FORTRAN
+fortran_lib = liblamf77mpi.la
+else
+fortran_lib =
+endif
+
+lib_LTLIBRARIES = $(fortran_lib)
+
+liblamf77mpi_la_SOURCES =
+liblamf77mpi_la_LIBADD =
+ $(top_builddir)/share/libmpi/libmpi.la
+ $(top_builddir)/share/liblam/liblam.la
+ $(top_builddir)/share/mpi/f77/liblamf77mpi.la
+liblamf77mpi_la_LDFLAGS = $(EXTRA_LDFLAGS)
diff -urN lam-7.1.4/share/libmpi/Makefile.am
lam-7.1.4-patched/share/libmpi/Makefile.am
--- lam-7.1.4/share/libmpi/Makefile.am 2006-06-24
16:42:43.000000000 -0400
+++ lam-7.1.4-patched/share/libmpi/Makefile.am 2008-03-11
00:12:32.000000000 -0400
-42,5
+42,6
$(top_builddir)/share/mpi/libmpiextra.la
$(top_builddir)/share/ssi/libssi_mpi.la
$(top_builddir)/share/memory/libmemory.la
+ $(top_builddir)/share/liblam/liblam.la
$(impi_lib) $(pmpi_lib)
libmpi_la_LDFLAGS = $(EXTRA_LDFLAGS)
diff -urN lam-7.1.4/share/Makefile.am
lam-7.1.4-patched/share/Makefile.am
--- lam-7.1.4/share/Makefile.am 2006-06-24
16:42:43.000000000 -0400
+++ lam-7.1.4-patched/share/Makefile.am 2008-03-10
23:32:04.000000000 -0400
-24,4
+24,4
SUBDIRS = include args boot etc freq kreq impi memory mpi
$(LIBLTDL_SUBDIR) nreq pmpi rreq ssi
threads $(TOTALVIEW_DLL_DIR) trillium tstdio
- liblam libmpi dynamic-ssi
+ liblam libmpi liblamf77mpi dynamic-ssi
diff -urN lam-7.1.4/share/mpi/f77/Makefile.am
lam-7.1.4-patched/share/mpi/f77/Makefile.am
--- lam-7.1.4/share/mpi/f77/Makefile.am 2006-06-24
16:42:35.000000000 -0400
+++ lam-7.1.4-patched/share/mpi/f77/Makefile.am 2008-03-10
23:41:30.000000000 -0400
-16,6
+16,8
include $(top_srcdir)/config/Makefile.options
+noinst_LTLIBRARIES = liblamf77mpi.la
+
# This kinda sucks. The "ar" command in IRIX 6.5
has a upper limit
# on the total number of characters in its arguments. If
we include
# all these fortran files in making libmpi.a, with all the
-34,12
+36,6
# no extra subdirectories, so it doesn't run into the same
character
# limit with ar. Ugh.
-if WANT_FORTRAN
-fortran_lib = liblamf77mpi.la
-else
-fortran_lib =
-endif
-
# Files with stubs of MPI functions that LAM has not yet
implemented.
# These are here because the default action is to *not*
compile them
-61,8
+57,6
mpi_stub_sources =
endif
-
-lib_LTLIBRARIES = $(fortran_lib)
liblamf77mpi_la_SOURCES =
$(mpi_stub_sources)
abort_f.c
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/
|
|
| Re: LAM: Supporting -Wl,--as-needed in
LDFLAGS. |
 
United States |
2008-03-13 19:33:07 |
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.
Thanks,
Brian
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
>
> --
> Justin Bronder
>
<7.1.4-as-needed.patch>_______________________________
________________
> This list is archived at http://www.l
am-mpi.org/MailArchives/lam/
--
Brian Barrett
LAM/MPI Developer
Make today a LAM/MPI day!
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/
|
|
| Re: LAM: Supporting -Wl,--as-needed in
LDFLAGS. |
|
2008-03-13 22:32:25 |
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:
jbrondermejis ~/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)
jbrondermejis ~/src/mpi-examples $ mpicc hello_c.c
jbrondermejis ~/src/mpi-examples $
unpatched:
jbrondermejis ~/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)
jbrondermejis ~/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
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/
|
|
| Re: LAM: Supporting -Wl,--as-needed in
LDFLAGS. |
United States |
2008-03-13 22:40:31 |
On Mar 13, 2008, at 9:32 PM, Justin Bronder wrote:
> jbrondermejis ~/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.
Your solution doesn't make sense in this case -- those
symbols have
nothing to do with liblamf77mpi, but are in liblam.so.
liblamf77mpi
should never be linked into hello_c.c, as it's all Fortran
code. Is it
possible that something else is going on?
Brian
--
Brian Barrett
LAM/MPI Developer
Make today a LAM/MPI day!
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/
|
|
| Re: LAM: Supporting -Wl,--as-needed in
LDFLAGS. |
|
2008-03-13 22:54:42 |
On 13/03/08 21:40 -0600, Brian Barrett wrote:
> On Mar 13, 2008, at 9:32 PM, Justin Bronder wrote:
>
> > jbrondermejis ~/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.
>
> Your solution doesn't make sense in this case -- those
symbols have
> nothing to do with liblamf77mpi, but are in liblam.so.
liblamf77mpi
> should never be linked into hello_c.c, as it's all
Fortran code. Is it
> possible that something else is going on?
>
>
Well, I probably should have included this instead. This
comes from the
single line added to share/libmpi/Makefile.am
jbrondermejis ~/src/mpi-examples $ ldd
/usr/lib/mpi/mpi-lam-unpatched/usr/lib64/libmpi.so
linux-vdso.so.1 => (0x00007fff905fe000)
libpthread.so.0 => /lib/libpthread.so.0
(0x00002ae71a95f000)
libc.so.6 => /lib/libc.so.6 (0x00002ae71ab7b000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
jbrondermejis ~/src/mpi-examples $ ldd
/usr/lib/mpi/mpi-lam/usr/lib64/libmpi.so
linux-vdso.so.1 => (0x00007fff3c5fe000)
liblam.so.0 =>
/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64/liblam.so.0
(0x00002b7b6e778000)
libpthread.so.0 => /lib/libpthread.so.0
(0x00002b7b6e9e7000)
libc.so.6 => /lib/libc.so.6 (0x00002b7b6ec02000)
libdl.so.2 => /lib/libdl.so.2 (0x00002b7b6ef41000)
libtorque.so.2 => /usr/lib/libtorque.so.2
(0x00002b7b6f146000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00002b7b6f39c000)
libutil.so.1 => /lib/libutil.so.1
(0x00002b7b6f5b3000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
Also, for what it's worth, there is one other patch that's
being applied to
deal with the same sort of issue. My fault again for not
including it
earlier. Attached as 7.1.2-liblam-use-extra-libs.patch. It
takes care of
the following build error that again, only occurs with the
noted LDFLAGS.
Making all in ipcdr
make[2]: Entering directory
`/var/tmp/portage/mpi-lam-unpatched/lam-mpi-7.1.4-r1/work/la
m-7.1.4/otb/ipcdr'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/var/tmp/portage/mpi-lam-unpatched/lam-mpi-7.1.4-r1/work/la
m-7.1.4/otb/ipcdr'
Making all in kdump
make[2]: Entering directory
`/var/tmp/portage/mpi-lam-unpatched/lam-mpi-7.1.4-r1/work/la
m-7.1.4/otb/kdump'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/var/tmp/portage/mpi-lam-unpatched/lam-mpi-7.1.4-r1/work/la
m-7.1.4/otb/kdump'
Making all in lamclean
make[2]: Entering directory
`/var/tmp/portage/mpi-lam-unpatched/lam-mpi-7.1.4-r1/work/la
m-7.1.4/otb/lamclean'
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I../../share/include -I../../share/include
-DLAM_BUILDING=1 -O2 -pipe -march=nocona -pthread -MT
lamclean.o -MD -MP -MF .deps/lamclean.Tpo -c -o lamclean.o
lamclean.c
mv -f .deps/lamclean.Tpo .deps/lamclean.Po
/bin/sh ../../libtool --tag=CC --mode=link
x86_64-pc-linux-gnu-gcc -O2 -pipe -march=nocona -pthread
-Wl,--as-needed -o lamclean lamclean.o
../../share/liblam/liblam.la ../../share/libltdl/libltdlc.la
-lutil
mkdir .libs
x86_64-pc-linux-gnu-gcc -O2 -pipe -march=nocona -pthread
-Wl,--as-needed -o .libs/lamclean lamclean.o
../../share/liblam/.libs/liblam.so /usr/lib64/libtorque.so
-lnsl ../../share/libltdl/.libs/libltdlc.a -ldl -lutil
-Wl,--rpath -Wl,/usr/lib64/mpi/mpi-lam-unpatched/usr/lib64
../../share/liblam/.libs/liblam.so: undefined reference to
`openpty'
collect2: ld returned 1 exit status
make[2]: *** [lamclean] Error 1
make[2]: Leaving directory
`/var/tmp/portage/mpi-lam-unpatched/lam-mpi-7.1.4-r1/work/la
m-7.1.4/otb/lamclean'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/mpi-lam-unpatched/lam-mpi-7.1.4-r1/work/la
m-7.1.4/otb'
make: *** [all-recursive] Error 1
--
Justin Bronder
--- lam-7.1.2.orig/share/liblam/Makefile.am 2006-09-25
22:52:17.000000000 -0700
+++ lam-7.1.2/share/liblam/Makefile.am 2006-09-25
22:52:04.000000000 -0700
-35,5
+35,6
$(top_builddir)/share/ssi/libssi_lam.la
$(top_builddir)/share/threads/liblamthreads.la
$(top_builddir)/share/trillium/liblamtrillium.la
- $(top_builddir)/share/tstdio/liblamtstdio.la
+ $(top_builddir)/share/tstdio/liblamtstdio.la
+ $(LIBLAM_EXTRA_LIBS)
liblam_la_LDFLAGS = $(EXTRA_LDFLAGS)
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/
|
|
| Re: LAM: Supporting -Wl,--as-needed in
LDFLAGS. |
United States |
2008-03-16 21:37:28 |
On Mar 13, 2008, at 9:54 PM, Justin Bronder wrote:
> Well, I probably should have included this instead.
This comes from
> the
> single line added to share/libmpi/Makefile.am
Ok, that makes more sense . Attached
is the patch I committed to
both the trunk and 7.1.x branch for LAM. I think it's
essentially the
same as the three patches you mentioned. It cured all
--as-needed
problems I experienced on my recent Debian machine. Of
course, I make
no promises of there ever being another LAM release, but if
there is,
this patch will be included.
Thanks,
Brian
--
Brian Barrett
LAM/MPI Developer
Make today a LAM/MPI day!
_______________________________________________
This list is archived at http://www.l
am-mpi.org/MailArchives/lam/
|
|
 |
[1-6]
|
|