This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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 this rule for all things inside, libltdl included. Later, when the
libtool-2.x will became available we can add a define in the ompi_config.h
that will trigger the correct include.
If we provide a ltdl.h file and finally the compilation use the one from
/usr/include that's really confusing. Look to me like random behaviour
depending on the willingness of the system administrator (if he/she
install it or not in the system directories). I think we correct way to do
it is either to use the one that we provide or to don't provide it if
there is another alternative.
On Thu, 1 Sep 2005, Ralf Wildenhues wrote:
> * 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 system directories. I don't think that's the expected behavior for
> > the compilation, if we have our own ltdl.h file why should we use the
> > system wide one ...
> This is usually up to the user's choice at some point (I don't know
> about OpenMPI with that respect).
> > 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 the ompi source code and the ldtl.h file.
> > Having to modify all the Makefile.am is a herculean task ...
> Ah, ok, I was blind then, in thinking only the parts that compiled over
> here used ltdl.h. There are a couple of ways to add include paths to
> many Makefile.am's: You could leverage config/Makefile.options, and set
> a default value for AM_CPPFLAGS (surely you have to change the
> Makefile.am's once to only add to AM_CPPFLAGS afterwards; or, maybe
> better, to add some other variable CPPFLAGS_LTDL set in
> But surely, once the work has to be done. I suggested that change
> because before, the code would've broken with Libtool-2.x anyway.
> devel mailing list
"We must accept finite disappointment, but we must never lose infinite
Martin Luther King