George -
When I looked at the same problem in LAM, I couldn't get the
dependencies right between libraries when only one makefile was used.
It worked up until I would do a parallel build, then would die because
the libraries weren't ready at the right time. There's probably a
way, but I ended up with Jeff's approach.
Brian
--
Brian Barrett
There is an art . . . to flying. The knack lies in learning how to
throw yourself at the ground and miss.
On Jul 24, 2008, at 2:23, George Bosilca <bosi...@eecs.utk.edu> wrote:
I tend to agree with Brian's comments, I would like to see this
pushed into the 1.3 branch asap. However, I'm concerned with the
impact on the code base of the required modifications as described
on the TRAC ticket and on the email thread.
I wonder if we cannot use the same technique that we use for
improving the build time, i.e. getting information from the
Makefile.am in the subdirs and adding it in the upper level
Makefile.am. As an example for the F77 build tree:
- if we create the following directories structure:
-> ompi
-> mpi
-> f77
-> global (this is new and will contain the 5 files
actually in the f77 base)
-> profiling
- then we include in the ompi/Makefile.am: include mpi/f77/global/
Makefile.am
- and in the mpi/f77/global/Makefile.am we add the 5 C files in the
SOURCES.
- the compiling of the f77 bindings and profiling information will
then depend on the libmpi, as long as we enforce the buildinf of the
f77 library after the libmpi.so.
With this approach, all files related to f77 will stay in the f77
directory (and the same will apply for cxx and f90), and the
required modifications to the makefiles are minimal.
Auto* gurus would such a solution works ?
Thanks,
george.
On Jul 23, 2008, at 6:52 PM, Brian Barrett wrote:
First, sorry about the previous message - I'm incapable of using my
e-mail apparently.
Based on discusions with people when this came up for LAM, it
sounds like this will become common for the next set of major
releases from the distros. The feature is fairly new to GNU ld,
but has some nice features for the OS, which I don't totally
understand.
Because this problem will only become more common during the
lifespan of 1.3.x , it makes sense to put this in v1.3, in my
opinion.
Brian
--
Brian Barrett
There is an art . . . to flying. The knack lies in learning how to
throw yourself at the ground and miss.
On Jul 23, 2008, at 9:32, Jeff Squyres <jsquy...@cisco.com> wrote:
Release managers: I have created ticket 1409 for this issue. I
need a ruling: do you want this fixed for v1.3?
https://svn.open-mpi.org/trac/ompi/ticket/1409
PRO: It's not too heinous to fix, but it does require moving some
code around.
CON: This is the first time anyone has ever run into this issue.
???: I don't know if this is a trend where distros will start
wanting to compile with -Wl,--no-undefined.
On Jul 23, 2008, at 10:15 AM, Jeff Squyres wrote:
On Jul 23, 2008, at 10:08 AM, Ralf Wildenhues wrote:
Is the attached patch what you're talking about?
If so, I'll commit to trunk, v1.2, and v1.3.
Can you verify that it work with a pristine build? The
dependencies as
such look sane to me, also the cruft removal, but I fail to see
how
your directory ordering can work:
You're right; I tested only in an already-built tree. I also
didn't run "make install" to an empty tree, which also shows the
problem.
Let me twonk around with this a bit...
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
