The problem seems to be fixed now.
Thanks,
george.
On Nov 23, 2005, at 2:39 PM, Brian Barrett wrote:
Fixed in SVN. Sorry about that...
On Nov 23, 2005, at 2:15 AM, George Bosilca wrote:
As I continue to have the same problem with the missing ltdl.h
header I
reported few days ago, I s
Fixed in SVN. Sorry about that...
On Nov 23, 2005, at 2:15 AM, George Bosilca wrote:
As I continue to have the same problem with the missing ltdl.h
header I
reported few days ago, I spend some time today to dig a little bit
inside
to find out what and how happens. Finally, I figure out the
Hi George,
* George Bosilca wrote on Wed, Nov 23, 2005 at 08:15:30AM CET:
> As I continue to have the same problem with the missing ltdl.h header I
> reported few days ago, I spend some time today to dig a little bit inside
> to find out what and how happens. Finally, I figure out the problem. I
As I continue to have the same problem with the missing ltdl.h header I
reported few days ago, I spend some time today to dig a little bit inside
to find out what and how happens. Finally, I figure out the problem. It
happens only after the last set of changes on the Makefile.am and only on
sys
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 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 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
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
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 include files
(starting the main components top directories). Personally, I prefer to
keep
* George Bosilca wrote on Thu, Sep 01, 2005 at 06:27:27AM CEST:
> 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 sys
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. I don't think that's the expected behavior for
the comp
Hi George,
* George Bosilca wrote on Thu, Sep 01, 2005 at 05:54:15AM CEST:
> Starting from yesterday I'm unable to compile on several clusters. I check
> the version of libtool, automake and autoconf and they all are the latest.
> However, in all the component I get similar errors:
>
> In file in
Starting from yesterday I'm unable to compile on several clusters. I check
the version of libtool, automake and autoconf and they all are the latest.
However, in all the component I get similar errors:
In file included from
../../../../../ompi-trunk/opal/mca/maffinity/base/maffinity_base_close.c:2
13 matches
Mail list logo
