Re: [OMPI devel] 1.4.4rc2 is up
(adding libtool-patches@gnu.org)
Is this guaranteed to work for all versions of the PGI compiler? I.e., does
"pgCC -V" always return something in the form of (digit)+\. ?
On May 17, 2011, at 8:52 PM, Larry Baker wrote:
> This bug applies to OpenMPI 1.4.x and 1.5.x.
>
> The libtool.m4 in config and opal/libltdl/m4 do not properly determine the
> version of the PGI compiler, which then set the wrong compile/link options.
> They interpret V11.4 (version no. begins with a 1), for example, as being a
> V1 to V5 compiler. There is a missing period in the pattern, so that only
> text like 1.x through 5.x matches.
>
> Here's the diff -u from OpenMPI 1.4.3 (same code, same bug):
>
>> [root@hydra openmpi-1.4.3]# diff -u config/libtool.m4{.original,}
>> --- config/libtool.m4.original 2010-10-05 15:45:44.0 -0700
>> +++ config/libtool.m42011-05-17 15:32:31.0 -0700
>> @@ -5896,7 +5896,7 @@
>>pgCC* | pgcpp*)
>> # Portland Group C++ compiler
>> case `$CC -V` in
>> -*pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
>> +*pgCC\ [[1-5]].* | *pgcpp\ [[1-5]].*)
>>_LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
>> rm -rf $tpldir~
>> $CC --prelink_objects --instantiation_dir $tpldir $objs
>> $libobjs $compile_deplibs~
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
> On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
>
>> Fixed the ROMIO attribute problem properly this time -- it's in the usual
>> place:
>>
>>http://www.open-mpi.org/software/ompi/v1.4/
>>
>> --
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>>
>> ___
>> 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
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] 1.4.4rc2 is up
With all the outputs from Paul and Sam, I think we'll be good.
...hmmm. Wait. I see that our 1.4.x configure *is* patched to have the extra
".". Here's the lines from configure in 1.4.3 and 1.4.4rc2:
# Portland Group C++ compiler
case `$CC -V` in
*pgCC\ [1-5].* | *pgcpp\ [1-5].*)
It's not in the .m4 file because we patch configure *after* the m4 file is used
to generate configure (Don't ask -- it's a long, twisted story).
Can you say what the original problem was that eventually led you to this patch?
On May 18, 2011, at 2:08 PM, Larry Baker wrote:
> Jeff,
>
>> Is this guaranteed to work for all versions of the PGI compiler? I.e., does
>> "pgCC -V" always return something in the form of (digit)+\. ?
>
> I don't know, but I think so. See your Nov 2009 discussion of this bug and
> Ralf Wildenhues' libtool.m4 patches at
> http://www.open-mpi.org/community/lists/users/2009/11/11277.php.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
> On 18 May 2011, at 5:50 AM, Jeff Squyres wrote:
>
>> (adding libtool-patches@gnu.org)
>>
>> Is this guaranteed to work for all versions of the PGI compiler? I.e., does
>> "pgCC -V" always return something in the form of (digit)+\. ?
>>
>>
>> On May 17, 2011, at 8:52 PM, Larry Baker wrote:
>>
>>> This bug applies to OpenMPI 1.4.x and 1.5.x.
>>>
>>> The libtool.m4 in config and opal/libltdl/m4 do not properly determine the
>>> version of the PGI compiler, which then set the wrong compile/link options.
>>> They interpret V11.4 (version no. begins with a 1), for example, as being
>>> a V1 to V5 compiler. There is a missing period in the pattern, so that
>>> only text like 1.x through 5.x matches.
>>>
>>> Here's the diff -u from OpenMPI 1.4.3 (same code, same bug):
>>>
>>>> [root@hydra openmpi-1.4.3]# diff -u config/libtool.m4{.original,}
>>>> --- config/libtool.m4.original 2010-10-05 15:45:44.0 -0700
>>>> +++ config/libtool.m4 2011-05-17 15:32:31.0 -0700
>>>> @@ -5896,7 +5896,7 @@
>>>> pgCC* | pgcpp*)
>>>># Portland Group C++ compiler
>>>>case `$CC -V` in
>>>> - *pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
>>>> + *pgCC\ [[1-5]].* | *pgcpp\ [[1-5]].*)
>>>> _LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
>>>>rm -rf $tpldir~
>>>> $CC --prelink_objects --instantiation_dir $tpldir $objs
>>>> $libobjs $compile_deplibs~
>>>
>>> Larry Baker
>>> US Geological Survey
>>> 650-329-5608
>>> ba...@usgs.gov
>>>
>>> On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
>>>
>>>> Fixed the ROMIO attribute problem properly this time -- it's in the usual
>>>> place:
>>>>
>>>> http://www.open-mpi.org/software/ompi/v1.4/
>>>>
>>>> --
>>>> Jeff Squyres
>>>> jsquy...@cisco.com
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>
>>>>
>>>> ___
>>>> 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
>>
>>
>> --
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: Bug in libtoolize
I see that there was a patch committed on this, but I think it's not
quite right, specifically in the Makefile.am area.
In the top-level Makefile.am, the following statement was added:
cd libltdl && $(MAKE) local-install-files
However, there's no such target in libltdl/Makefile.am (nor
libltdl/Makefile). Was install-local-data meant, instead?
On Feb 21, 2005, at 10:55 AM, Gary V. Vaughan wrote:
Gary V. Vaughan wrote:
Peter O'Gorman wrote:
I question that we can rely on tar being installed, although I have
not
come across a system where it isn't.
Maybe I should add a --no-tar option to fallback to 'cp -p'
to cover that eventuality?
I take it back. GCS allows us to rely on a tar command being
available.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
Re: ltdl bugs
I apologize for my delay in replying -- I can confirm that this patch
works nicely for me, and is a far better solution than my crufty
attempts at patching lt_dlclose().
Many thanks, Ralf!
On Apr 4, 2005, at 8:16 AM, Ralf Wildenhues wrote:
Jeff,
* Ralf Wildenhues wrote on Sun, Apr 03, 2005 at 05:33:12PM CEST:
I'll try to rephrase: You may actually do what you intend in
lt_dlexit(), because that is (like MPI_Finalize) final in the sense,
that after as many lt_dlexit's as lt_dlinit's we may completely shut
down our stuff and free every data we own.
You may _not_ do this in lt_dlclose(), however, because the user may
issue another lt_dlopen() of the very same module (which may be NULL,
or
"foo.la" made resident), which in fact is already open.
So, here's a different try at a patch, against branch-1-5,
which does what I think is correct: free only in lt_dlexit,
not in lt_dlclose.
Could you try it?
Regards,
Ralf
Free all remaining handles and our associated storage, even for
resident modules, at lt_dlexit time (cosmetic change to please
memory checkers).
* libltdl/ltdl.c (lt_dlclose): Make wrapper, rename to..
(do_dlclose): Accept new parameter force_free to enable mere
deallocation and delisting, but not unloading of resident
modules. Do not error out in force_free case.
(lt_dlexit): Call do_dlclose with force_free, for all modules,
not just non-resident ones.
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.174.2.13
diff -u -r1.174.2.13 ltdl.c
--- libltdl/ltdl.c 1 Feb 2005 13:57:11 - 1.174.2.13
+++ libltdl/ltdl.c 4 Apr 2005 12:14:41 -
@@ -2145,6 +2145,7 @@
lt_ptr data2));
+static int do_dlclose LT_PARAMS((lt_dlhandle handle, int
force_free));
static int canonicalize_path LT_PARAMS((const char *path,
char **pcanonical));
static int argzize_path LT_PARAMS((const char *path,
@@ -2306,11 +2307,6 @@
{
int level;
- while (handles && LT_DLIS_RESIDENT (handles))
- {
- handles = handles->next;
- }
-
/* close all modules */
for (level = 1; handles; ++level)
{
@@ -2323,9 +2319,9 @@
cur = cur->next;
if (!LT_DLIS_RESIDENT (tmp))
saw_nonresident = 1;
- if (!LT_DLIS_RESIDENT (tmp) && tmp->info.ref_count <= level)
+ if (tmp->info.ref_count <= level)
{
- if (lt_dlclose (tmp))
+ if (do_dlclose (tmp, 1))
{
++errors;
}
@@ -3768,9 +3764,10 @@
return is_done;
}
-int
-lt_dlclose (handle)
+static int
+do_dlclose (handle, force_free)
lt_dlhandle handle;
+ int force_free;
{
lt_dlhandle cur, last;
int errors = 0;
@@ -3798,10 +3795,10 @@
correctly incase the user decides to reset the residency flag
later (even though the API makes no provision for that at the
moment). */
- if (handle->info.ref_count <= 0 && !LT_DLIS_RESIDENT (handle))
+ if (handle->info.ref_count <= 0
+ && (!LT_DLIS_RESIDENT (cur) || force_free))
{
- lt_user_data data = handle->loader->dlloader_data;
-
+ /* Remove this handle from the list of handles */
if (handle != handles)
{
last->next = handle->next;
@@ -3811,9 +3808,14 @@
handles = handle->next;
}
- errors += handle->loader->module_close (data, handle->module);
- errors += unload_deplibs(handle);
+ /* If the module is not resident, then unload, etc. */
+ if (!LT_DLIS_RESIDENT (handle))
+ {
+ lt_user_data data = handle->loader->dlloader_data;
+ errors += handle->loader->module_close (data, handle->module);
+ errors += unload_deplibs(handle);
+ }
/* It is up to the callers to free the data itself. */
LT_DLFREE (handle->caller_data);
@@ -3824,7 +3826,7 @@
goto done;
}
- if (LT_DLIS_RESIDENT (handle))
+ if (LT_DLIS_RESIDENT (handle) && !force_free)
{
LT_DLMUTEX_SETERROR (LT_DLSTRERROR (CLOSE_RESIDENT_MODULE));
++errors;
@@ -3836,6 +3838,13 @@
return errors;
}
+int
+lt_dlclose (handle)
+ lt_dlhandle handle;
+{
+ return do_dlclose (handle, 0);
+}
+
lt_ptr
lt_dlsym (handle, symbol)
lt_dlhandle handle;
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
Re: LT 2.2 series regression
This patch unfortunately does not seem to work -- here's some output
from the build:
/bin/sh ../../../libtool --mode=compile ifort -I../../../ompi/
include -I../../../ompi/include -I. -I. -I../../../ompi/mpi/f90 -c -
o mpi_wtick_f90.lo mpi_wtick_f90.f90
libtool: compile: ifort -I../../../ompi/include -I../../../ompi/
include -I. -I. -I../../../ompi/mpi/f90 -c mpi_wtick_f90.f90 -o .libs/
mpi_wtick_f90.o
./scripts/mpi_wtime_f90.f90.sh /users/jsquyres/svn/ompi/ompi/mpi/f90 >
mpi_wtime_f90.f90
Note that it still doesn't have a -fPIC in there. Looking in the
output of configure, it's still trying to use -KPIC:
checking for ifort option to produce PIC... -KPIC
checking if ifort PIC flag -KPIC works... no
I notice that you patched [opal/]libltdl/m4/libtool.m4 -- did you mean
to patch config/libtool.m4? I tried patching both of these, but got
the same result (listed above).
On May 25, 2008, at 4:50 AM, Ralf Wildenhues wrote:
Hi Jeff,
* Jeff Squyres wrote on Wed, May 21, 2008 at 05:08:57PM CEST:
The Open MPI project just switched yesterday to using LT 2.2.4, AC
2.62,
and AM 1.10.1 for our nightly trunk snapshot tarballs. Several
developers have been using this combo for a while (including me), but
using this trio for the nightly tarballs opens it up to a much wider
testing audience.
Thanks for the move, that really helps find those system-dependent
regressions we cannot test ourselves.
We ran into a problem with last night's regression testing with the
Fortran Intel compiler suite and shared libraries.
It seems that LT 2.2.x determines that the Intel ifort compiler
option
for building shared libraries is -KPIC (when it should be -fPIC). It
then tests -KPIC, determines that it doesn't work, and then
discards it.
Hence, sources built with ifort have *no* PIC option, and therefore
you
can't build shared libraries for them. Here's the relevant output
from
configure (RHEL4U4, x86_64, Intel compiler suite 10.1):
Do you have an idea how many different Intel compiler versions your
users use? Because commit 319a767ce6d3eb131cc6d4d64809af1859d1a801
was added here:
<http://lists.gnu.org/archive/html/libtool-patches/2008-02/msg7.html
>
and I'm pretty sure that the version I tested then did work with -KPIC
(and I think I tested with a fairly new one).
I have only old version 8 to look at here right now, which states that
-KPIC is supported but deprecated, and that -fPIC is OK.
I've applied the patch below now. Can you report back how it worked
for
you?
Thanks,
Ralf
Fix ifort settings again.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] :
Unlike icc and ecc, not all ifort versions understand `-KPIC',
e.g. version 10.1, so use `-fPIC' instead.
Report by Jeff Squyres.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 6f9ac1b..654f54a 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3964,11 +3964,16 @@ m4_if([$1], [CXX], [
linux* | k*bsd*-gnu)
case $cc_basename in
- icc* | ecc* | ifort*)
+ icc* | ecc*)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
+ ifort*)
+ _LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+ _LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
+;;
pgcc* | pgf77* | pgf90* | pgf95*)
# Portland Group compilers (*not* the Pentium gcc compiler,
# which looks to be a dead project)
--
Jeff Squyres
Cisco Systems
Re: LT 2.2 series regression
Ralf -- After making all the changes you suggested (see https://svn.open-mpi.org/trac/ompi/changeset/18514 and https://svn.open-mpi.org/trac/ompi/changeset/18515), everything works. Note that I couldn't completely remove acinclude.m4; we have a few files that are generated by autogen.sh that must be manually included (these files don't AC_DEFUN functions; they m4_define values and do other nasty tricks). Note that the above commits include the patch you originally sent in http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00049.html ; it works for me in manual tests with the Intel compiler suite (I have no reason to believe that it'll fail in our automated testing). Many thanks! On May 27, 2008, at 4:46 PM, Ralf Wildenhues wrote: Hi Jeff, * Jeff Squyres wrote on Tue, May 27, 2008 at 03:07:02PM CEST: On May 26, 2008, at 1:42 PM, Ralf Wildenhues wrote: I notice that you patched [opal/]libltdl/m4/libtool.m4 -- did you mean to patch config/libtool.m4? I tried patching both of these, but got the same result (listed above). Are you sure that you re-ran autogen.sh after patching config/libtool.m4? Because over here, I can reproduce the fact that -KPIC was used before, and -fPIC with the patch. I actually patched autogen.sh to add your patch in while it was running. And I can confirm that it's there in the 2 m4 files (config/ libtool.m4 and opal/libltdl/m4/libtool.m4) after autogen.sh completes. But it is *not* in configure. Digging a little deeper, I wonder if we are running the GNU tools in the wrong sequence in autogen.sh -- it does the following (abridged output): [Running] autom4te --language=m4sh ompi_get_version.m4sh -o ompi_get_version.sh [Running] aclocal [Running] autoheader [Running] autoconf [Running] libtoolize --automake --copy --ltdl [Running] automake --foreign -a --copy --include-deps Should we be running libtoolize much earlier, before aclocal? Yes, and you should be running 'aclocal -I config' in the toplevel, if you want config/*.m4 to take precedence over installed m4 files, for example. Technically, the first time you ever invoke autogen.sh on a pristine SVN checkout, it may be necessary to run aclocal, then libtoolize, then rerun aclocal, but I think the first aclocal invocation is not necessary as long as AC_PROG_LIBTOOL is present in configure.ac. At that point (when you have added -I config), your aclocal.m4 file will shrink by about 340K in size. Also, at that point you can start thinking about simply removing the toplevel acinclude.m4 file, as 'aclocal -I config' will cause the needed macro files from config/ to be m4_included from aclocal.m4. One file less to keep up to date manually. :-) Cheers, Ralf -- Jeff Squyres Cisco Systems
Re: Portland Fortran compiler changing executable name
Thanks Ralf!
If it matters, as I understand it, the name pgfortran is meant to
symbolize that the compiler now supports things beyond Fortran 90 --
it supports Fortran 95 and some Fortran 03 (and beyond?) features. So
I don't know if you want to update the comment that specifically
states F77 and F90 or not...
On Nov 14, 2009, at 2:35 AM, Ralf Wildenhues wrote:
Hi Jeff,
* Jeff Squyres wrote on Wed, Nov 11, 2009 at 09:45:53PM CET:
> Could Libtool be adjusted now to look for the "pgfortran" name first
> for all Fortran variants, and if not found, fall back to the old
> names? That would seem to give flexibility for the future.
That name doesn't seem to be problematic, can't see any other use of
it
out there. I'm pushing this patch.
Thanks,
Ralf
Recognize `pgfortran' as Portland compiler.
* libltdl/m4/libtool.m4 (_LT_COMPILER_PIC, _LT_LINKER_SHLIBS):
Accept `pgfortran*' too.
Report by Jeff Squyres.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 206940e..1f58a38 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4042,7 +4042,7 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_pic, $1)='--shared'
_LT_TAGVAR(lt_prog_compiler_static, $1)='--static'
;;
- pgcc* | pgf77* | pgf90* | pgf95*)
+ pgcc* | pgf77* | pgf90* | pgf95* | pgfortran*)
# Portland Group compilers (*not* the Pentium gcc compiler,
# which looks to be a dead project)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
@@ -4454,7 +4454,8 @@ _LT_EOF
_LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-
archive`for conv in $convenience\"\"; do test -n \"$conv\" &&
new_convenience=\"$new_convenience,$conv\"; done; func_echo_all
\"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag'
;;
- pgf77* | pgf90* | pgf95*) # Portland Group f77 and f90
compilers
+ pgf77* | pgf90* | pgf95* | pgfortran*)
+ # Portland Group f77 and f90
compilers
_LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-
archive`for conv in $convenience\"\"; do test -n \"$conv\" &&
new_convenience=\"$new_convenience,$conv\"; done; func_echo_all
\"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag -Mnomain' ;;
ecc*,ia64* | icc*,ia64*)# Intel C compiler on ia64
--
Jeff Squyres
jsquy...@cisco.com
