Hi George,
* George Bosilca wrote on Thu, Sep 01, 2005 at 06:49:48AM CEST:
>
> Now I see the reason behind this change. Anyway, few month ago we decide
> to switch the compilation process, and to modify all the files in order to
> start all the #include directives with the full path of the includ
On Sep 1, 2005, at 12:37 AM, Ralf Wildenhues wrote:
I trace this one as far as I could. And the results are mostly
unexpected.
On some of the clusters it compiles without any problems and on some
others it doesn't. The difference is ... if there is an ltdl.h
installed
in the system directories
On Sep 1, 2005, at 6:38 AM, Jeff Squyres wrote:
I see the issue in the source code, and I'll fix it
(opal/mca/base/base.h, which is widely included throughout the tree,
has declarations of some internal functions).
Fixed and committed. I tested both a regular and a VPATH build, but I
do not
On Aug 31, 2005, at 7:46 AM, Ralf Wildenhues wrote:
Please apply the first patch (or a similar solution) to include
ltdl.h directly. This is both how it's documented and how
it will work with Libtool 1.5.x and 2.x: the latter has other
included files, which live one directory level further down
Yo folks
Several people have asked lately what I am planning to do next on
ORTE. Just to help maintain coordination, here is my current list of
planned activities (in priority order). Any requests/suggestions are
welcomed - this isn't in concrete by any means.
1. Add George's architecture in
On Sep 1, 2005, at 12:37 AM, Ralf Wildenhues wrote:
For some component it work as expected because on the revision 7106
the
-I$(top_srcdir)/opal/libltdl has been added to the AM_CPPFLAGS in the
Makefile.am. As most of our code use components there is a dependency
between nearly every file in th
Heh. Well, it's good to see that the illegal symbol report is working
properly. :-)
I'll add MPIR_ as an acceptable prefix so that these get ignored from
now on.
On Sep 1, 2005, at 6:11 AM, jsquy...@odin.cs.indiana.edu wrote:
Found global symbols with missing or illegal prefixes
File
What is the status of the gm configure issue:
mpicc -O -DMPI ./src/netpipe.c ./src/mpi.c -o NPmpi -I./src
gcc: WRAPPER_ALWAYS_EXTRA_LIBS: No such file or directory
gcc: WRAPPER_ALWAYS_EXTRA_LIBS: No such file or directory
Is there a simple work-around, or should I just compile/link
the app w/ou
I think Brian sent the workaround the other day (I don't know if he got
to commit a proper fix or not -- he left for travel shortly after
that), but I also thought that George fixed the issue in his
configure.m4...? (could be wrong; I don't build GM regularly)
-
From: brbar..
Well ... I actually needed both. This is still an issue w/ static builds.
I'll try a shared build.
Tim
Jeff Squyres wrote:
I think Brian sent the workaround the other day (I don't know if he got
to commit a proper fix or not -- he left for travel shortly after
that), but I also thought that G
Everyone using the odin cluster at IU:
There was an unscheduled upgrade of the g++ compiler on the odin
cluster at IU this afternoon (from 3.4.3 to 3.4.4 to get an important
bug fix). The end result is that if you're compiling the C++ MPI
bindings in an OMPI tree (which is the default), you'l
Yo folks
I have now completed the first three of these items. I believe this
brings ORTE to a stage that is - at the least - very close to release
quality. There are a few memory leaks left (oob and iof subsystems),
but I'm not as familiar with those and have asked for help.
Barring any requ
This is fixed in SVN. Sorry for the delay in getting it fixed.
Brian
On Sep 1, 2005, at 9:50 AM, Tim S. Woodall wrote:
Well ... I actually needed both. This is still an issue w/ static
builds.
I'll try a shared build.
Tim
Jeff Squyres wrote:
I think Brian sent the workaround the other d
13 matches
Mail list logo
