Re: Libtool roadmap
Other than Bob's humorous reply, any comment from the Libtool team? Thanks! -- Jeff Squyres jsquy...@cisco.com From: Bob Friesenhahn Sent: Friday, March 25, 2022 4:01 PM To: Jeff Squyres (jsquyres) Cc: libtool@gnu.org Subject: Re: Libtool roadmap On Fri, 25 Mar 2022, Jeff Squyres (jsquyres) wrote: > Congratulations on the Libtool 2.4.7 release! > (https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html) > > Given that this is the first Libtool release in ~7 years, should we -- the > general developer community -- take this as an indication that the GNU > Libtool is back under active development? If so, is there a roadmap and/or > set of timeframes for future GNU Libtool work? >From the above, it sounds like you are interested in being a libtool developer. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Libtool roadmap
Congratulations on the Libtool 2.4.7 release! (https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html) Given that this is the first Libtool release in ~7 years, should we -- the general developer community -- take this as an indication that the GNU Libtool is back under active development? If so, is there a roadmap and/or set of timeframes for future GNU Libtool work? Thanks for any information that you can provide. -- Jeff Squyres jsquy...@cisco.com
Re: Can you force the use of the internal argz?
On Sep 10, 2012, at 4:33 PM, Jeff Squyres wrote: I'll followup with a local edit to my valgrind suppression file and send a note upstream to the valgrind folks. If anyone cares, Julian came back with a better solution within a few minutes: https://bugs.kde.org/show_bug.cgi?id=306612 Hopefully this will get into the next upstream release. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Can you force the use of the internal argz?
On Sep 10, 2012, at 3:32 PM, Eric Blake wrote: You can see that the error is that the glibc argz_insert is apparently doing an optimized memmove that is assumedly doing some kind of 8 byte read. The only problem is that there is less than 8 bytes left in the string but AT LEAST 8 bytes before the next page boundary, so it won't fault. This is a valid optimization in glibc, and the glibc valgrind suppression file is supposed to silence warnings about this and other valid optimizations where glibc does large but aligned reads, and even does computations on the tail bytes, but where the computations don't matter because the algorithm necessarily detects the end of string the the hed bytes. Ah -- this is a much better solution. I'll followup with a local edit to my valgrind suppression file and send a note upstream to the valgrind folks. Thanks! -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Can you force the use of the internal argz?
Short version: -- The glibc argz functions in RHEL produce valgrind warnings about illegal reads. Can I force the use of libltdl's internal argz functionality to avoid these issues? More details: - This weekend, I finally sat down to figure out some valgrind libltdl warnings that have annoyed me for a very long time (from the embedded libltdl that we have in Open MPI). Here's an example: - ==8436== Invalid read of size 8 ==8436==at 0x3D5908848D: _wordcopy_fwd_dest_aligned (in /lib64/libc-2.12.so) ==8436==by 0x3D5908211D: __GI_memmove (in /lib64/libc-2.12.so) ==8436==by 0x3D590897DB: argz_insert (in /lib64/libc-2.12.so) ==8436==by 0x403C8B: lt_argz_insert (ltdl.c:1723) ==8436==by 0x403E71: lt_argz_insertinorder (ltdl.c:1768) ==8436==by 0x4040F3: lt_argz_insertdir (ltdl.c:1826) ==8436==by 0x404298: list_files_by_dir (ltdl.c:1854) ==8436==by 0x40433D: foreachfile_callback (ltdl.c:1882) ==8436==by 0x402053: foreach_dirinpath (ltdl.c:720) ==8436==by 0x404429: lt_dlforeachfile (ltdl.c:1920) ==8436==by 0x40120B: main (main.c:44) ==8436== Address 0x4c2e780 is 16 bytes inside a block of size 21 alloc'd ==8436==at 0x4A066FA: malloc (vg_replace_malloc.c:263) ==8436==by 0x405C96: lt__malloc (lt__alloc.c:54) ==8436==by 0x404049: lt_argz_insertdir (ltdl.c:1814) ==8436==by 0x404298: list_files_by_dir (ltdl.c:1854) ==8436==by 0x40433D: foreachfile_callback (ltdl.c:1882) ==8436==by 0x402053: foreach_dirinpath (ltdl.c:720) ==8436==by 0x404429: lt_dlforeachfile (ltdl.c:1920) ==8436==by 0x40120B: main (main.c:44) - You can see that the error is that the glibc argz_insert is apparently doing an optimized memmove that is assumedly doing some kind of 8 byte read. The only problem is that there is less than 8 bytes left in the string (specifically: doing an 8 byte read starting 16 bytes into a 21-byte allocation). This is quite definitely a problem with the RHEL glibc argz -- not libltdl. But it's still quite annoying. I would very much like to avoid the system-level argz for this reason, and use libltdl's internal argz instead. If I manually edit libltdl's m4 to make it fail all the argz tests -- thereby forcing libltdl to use its internal argz functionality -- then all is fine. Can an option be added to make this supported functionality, perchance? I would be happy to provide a patch if the idea isn't terrible. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ https://lists.gnu.org/mailman/listinfo/libtool
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: [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: GNU Libtool 2.2.6b released
On Nov 16, 2009, at 7:21 AM, Peter O'Gorman wrote: We are intending to release 2.2.8 sometime (hopefully soon) with all the new features and lots of bug fixes from git HEAD. So why not call this release 2.2.8 and bump the version number of the next one to 2.2.10? Is it technically difficult to do so? I ask because version numbers are primarily for users -- not developers. So a little developer discomfort to rename specific releases is (IMHO) acceptable in order to provide a clear, unambiguous meaning of the version number to users. This release only contains two bugfixes to libltdl that were deemed important enough to warrant a separate release from the stable 2.2.6 series. Understood. My only point is that the last 2 public releases of LT have had semantically different meanings of the version number. It is therefore VERY unclear that 2.2.6b is a significant security/bug fix release (even if the actual changes are minor). If I (a random user) saw that LT released 2.2.6b but didn't read anything in the notes, I'd assume that it was another packaging change, like 2.2.6a was. I certainly would not immediately grok that it contains a security update. OTOH, if the LT version number was bumped to 2.2.8 -- or even 2.4 -- I would assume that most users will think, Something important must have changed. I should go a) read the release notes, and b) install this update. (all normal disclaimers on the word assume, of course ;-) ). My $0.02: the version number of a package is a critical method of communication to the rest of the world. It needs to have clear, unambiguous meaning. The last 2 releases of LT have significantly muddied the waters as to what the 3rd field in the LT version number means. Can you clarify what exactly the minor number and suffix mean in the LT version number (for the purposes of understanding future releases)? Sidenote: it's easy for email threads like this to get sidetracked into flamewars. Please understand that I'm a long-time/loyal LT user and greatly appreciate all your efforts -- I'm *NOT* trying to start a flamewar. I sent this email (and the emails back when 2.2.6a was released) not to be a jerk, but rather to ask a genuine user- perspective question and hopefully get some clarity for the future. Thanks! -- Jeff Squyres jsquy...@cisco.com ___ http://lists.gnu.org/mailman/listinfo/libtool
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
Re: Libtool 2.2.6a
On Sep 17, 2008, at 3:00 PM, Peter O'Gorman wrote: Yeah, it is mostly a repacking of the libtool-2.2.6.tar.* that were released the day before. Putting up files with the same name but different sums is also bad. It is noted in the release announcement: I understand, and I saw the version number discrepancy in the release announcement (FWIW, I've had those oops-need-to-rerelease-in-less- than-24-hours kinds of moments as well -- so I feel your pain). But I did not expect the tarball to expand into a directory ending in 2.2.6. Specifically: the tarball has a filename that ends in 2.2.6a. To match the convention used by all the other autoconf/automake/libtool tarballs, I expected it to expand into a directory named 2.2.6a -- and my scripts reflected that expectation. I now have a special case for LT 2.2.6a in my scripts. While this is certainly not the end of the world, it shouldn't really have been necessary. My $0.02 would have been to either rename it 2.2.8 or change the directory and version to report 2.2.6a. Don't get me wrong; I'm a long-time, happy Libtool user. This is just something that surprised me because it went against prior conventions, so I thought I'd mention it on the list. -- Jeff Squyres Cisco Systems ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool 2.2.6a
minor rant I notice that libtool-2.2.6a.tar.* unzips into the libtool-2.2.6/ directory (dropping the a from the directory name). This is unexpected. It actually throws off all my auto-install scripts because the version number is now not the same as the directory. Grumble. /minor rant -- Jeff Squyres Cisco Systems ___ http://lists.gnu.org/mailman/listinfo/libtool
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: 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] ifort: 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
LT 2.2 series regression
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. 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): ... checking whether to build shared libraries... yes checking whether to build static libraries... no checking for ifort option to produce PIC... -KPIC checking if ifort PIC flag -KPIC works... no checking if ifort static flag -static works... yes ... The output from building is therefore fairly predictable: ... 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 /bin/sh ../../../libtool --mode=compile ifort -I../../../ompi/ include -I../../../ompi/include -I. -I. -I../../../ompi/mpi/f90 -c - o mpi_wtime_f90.lo mpi_wtime_f90.f90 libtool: compile: ifort -I../../../ompi/include -I../../../ompi/ include -I. -I. -I../../../ompi/mpi/f90 -c mpi_wtime_f90.f90 -o .libs/ mpi_wtime_f90.o /bin/sh ../../../libtool --mode=link ifort -I../../../ompi/include - I../../../ompi/include -I. -I. -I../../../ompi/mpi/f90-export- dynamic -o libmpi_f90.la -rpath /home/jsquyres/bogus/lib mpi.lo mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo mpi_wtime_f90.lo-lnsl -lutil libtool: link: ifort -shared -nofor_main .libs/mpi.o .libs/ mpi_sizeof.o .libs/mpi_comm_spawn_multiple_f90.o .libs/ mpi_testall_f90.o .libs/mpi_testsome_f90.o .libs/ mpi_waitall_f90.o .libs/mpi_waitsome_f90.o .libs/mpi_wtick_f90.o .libs/ mpi_wtime_f90.o-lnsl -lutil-Wl,-soname -Wl,libmpi_f90.so.0 - o .libs/libmpi_f90.so.0.0.0 ld: .libs/mpi_comm_spawn_multiple_f90.o: relocation R_X86_64_PC32 against `mpi_comm_spawn_multiple_' can not be used when making a shared object; recompile with -fPIC ld: final link failed: Bad value (the compile line for mpi_comm_spawn_multiple_f90.f90 was similar to that of mpi_wtick_f90.f90 and mpi_wtime_f90.f90) I can send the entire output if necessary. I tested LT 2.2, 2.2.2, and 2.2.4: the failure behavior is the same. I also tested the Intel compiler suite versions 9.0, 9.1, 10.0, and 10.1: same failure behavior with the Intel 10.x series, but -KPIC *works* with the Intel 9.x series. Specifically, we get this in the output from configure when using Intel ifort 9.0 and 9.1: checking for ifort option to produce PIC... -KPIC checking if ifort PIC flag -KPIC works... yes ...and building Open MPI works fine (the fortran shared library builds with ifort ... -KPIC ... and everything works properly). But here's the kicker: until yesterday, Open MPI was using a very old LT 2.1a snapshot for building its nightly trunk tarballs (see http://www.open-mpi.org/svn/libtool.tar.gz) . With that 2.1a snapshot, LT was using -fPIC (not -KPIC) for Fortran shared libraries with all versions of the Intel compiler. Additionally, LT 1.5.22 uses -fPIC for ifort shared libraries (I did not test any further in the 1.5 series). Based on the 2.1a tarball and 1.5.22 results, this *looks* like a regression to us. Does anyone know the history of this -fPIC - -KPIC change for ifort? It seems like using -fPIC for all versions of ifort should work properly. Thanks for all your hard work on Libtool! -- Jeff Squyres Cisco Systems ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: LT 2.2 series regression
Disregard -- I really should have sent this to the bug-libtool list. I'll follow up with this issue there. Sorry for the spam! :-( On May 21, 2008, at 11:03 AM, Jeff Squyres wrote: 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. 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): ... checking whether to build shared libraries... yes checking whether to build static libraries... no checking for ifort option to produce PIC... -KPIC checking if ifort PIC flag -KPIC works... no checking if ifort static flag -static works... yes ... The output from building is therefore fairly predictable: ... 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 /bin/sh ../../../libtool --mode=compile ifort -I../../../ompi/ include -I../../../ompi/include -I. -I. -I../../../ompi/mpi/f90 -c -o mpi_wtime_f90.lo mpi_wtime_f90.f90 libtool: compile: ifort -I../../../ompi/include -I../../../ompi/ include -I. -I. -I../../../ompi/mpi/f90 -c mpi_wtime_f90.f90 - o .libs/mpi_wtime_f90.o /bin/sh ../../../libtool --mode=link ifort -I../../../ompi/include -I../../../ompi/include -I. -I. -I../../../ompi/mpi/f90-export- dynamic -o libmpi_f90.la -rpath /home/jsquyres/bogus/lib mpi.lo mpi_sizeof.lo mpi_comm_spawn_multiple_f90.lo mpi_testall_f90.lo mpi_testsome_f90.lo mpi_waitall_f90.lo mpi_waitsome_f90.lo mpi_wtick_f90.lo mpi_wtime_f90.lo-lnsl -lutil libtool: link: ifort -shared -nofor_main .libs/mpi.o .libs/ mpi_sizeof.o .libs/mpi_comm_spawn_multiple_f90.o .libs/ mpi_testall_f90.o .libs/mpi_testsome_f90.o .libs/ mpi_waitall_f90.o .libs/mpi_waitsome_f90.o .libs/ mpi_wtick_f90.o .libs/mpi_wtime_f90.o-lnsl -lutil-Wl,-soname -Wl,libmpi_f90.so.0 -o .libs/libmpi_f90.so.0.0.0 ld: .libs/mpi_comm_spawn_multiple_f90.o: relocation R_X86_64_PC32 against `mpi_comm_spawn_multiple_' can not be used when making a shared object; recompile with -fPIC ld: final link failed: Bad value (the compile line for mpi_comm_spawn_multiple_f90.f90 was similar to that of mpi_wtick_f90.f90 and mpi_wtime_f90.f90) I can send the entire output if necessary. I tested LT 2.2, 2.2.2, and 2.2.4: the failure behavior is the same. I also tested the Intel compiler suite versions 9.0, 9.1, 10.0, and 10.1: same failure behavior with the Intel 10.x series, but -KPIC *works* with the Intel 9.x series. Specifically, we get this in the output from configure when using Intel ifort 9.0 and 9.1: checking for ifort option to produce PIC... -KPIC checking if ifort PIC flag -KPIC works... yes ...and building Open MPI works fine (the fortran shared library builds with ifort ... -KPIC ... and everything works properly). But here's the kicker: until yesterday, Open MPI was using a very old LT 2.1a snapshot for building its nightly trunk tarballs (see http://www.open-mpi.org/svn/libtool.tar.gz) . With that 2.1a snapshot, LT was using -fPIC (not -KPIC) for Fortran shared libraries with all versions of the Intel compiler. Additionally, LT 1.5.22 uses -fPIC for ifort shared libraries (I did not test any further in the 1.5 series). Based on the 2.1a tarball and 1.5.22 results, this *looks* like a regression to us. Does anyone know the history of this -fPIC - - KPIC change for ifort? It seems like using -fPIC for all versions of ifort should work properly. Thanks for all your hard work on Libtool! -- Jeff Squyres Cisco Systems -- Jeff Squyres Cisco Systems ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: .ctor section of shared libraries with PathScale compiler
Noah --
Awesome; thanks! (you code is a bit simpler than mine, which is good)
I think the only difference is that the C++ library must be a shared
library. It will always work fine if the library is static. I saw
some references in some of the other .at files that there is a way to
figure out if Libtool was built with shared library support, but I
didn't figure that part out before I sent my original patch.
On Apr 25, 2007, at 10:58 PM, Noah Misch wrote:
On Wed, Apr 25, 2007 at 12:36:23PM -0400, Jeff Squyres wrote:
I'm told that I can describe the patch in implementation-free terms
in the hope that someone else can implement it who either can setup
to transfer copyright to the FSF or already has such a transfer
agreement in place.
The patch is very simple. It's a test that makes a shared library
containing a single instance of a class in the global scope. The
class has a specific constructor that should be invoked before main()
(since the instance is in the global scope). It is easy enough to
test whether the constructor has run before main(); if it has, the
test passes. If it has not, the test fails.
Does the test this patch adds exercise the bug affecting your
compiler?
2007-04-25 Noah Misch [EMAIL PROTECTED]
* tests/ctor.at: New file.
* Makefile.am (TESTSUITE_AT): Add tests/ctor.at.
diff -NurpX dontdiff lt-bootstrap/Makefile.am lt-ctortest/Makefile.am
--- lt-bootstrap/Makefile.am2007-04-24 16:46:17.0 -0400
+++ lt-ctortest/Makefile.am 2007-04-25 22:52:10.0 -0400
@@ -448,6 +448,7 @@ TESTSUITE_AT= tests/testsuite.at \
tests/nonrecursive.at \
tests/recursive.at \
tests/template.at \
+ tests/ctor.at \
tests/early-libtool.at \
tests/deplibs-ident.at \
tests/stresstest.at \
diff -NurpX dontdiff lt-bootstrap/tests/ctor.at lt-ctortest/tests/
ctor.at
--- lt-bootstrap/tests/ctor.at 1969-12-31 19:00:00.0 -0500
+++ lt-ctortest/tests/ctor.at 2007-04-25 22:54:19.0 -0400
@@ -0,0 +1,66 @@
+# ctor.at -- Test constructors via C++-*-
Autotest -*-
+#
+# Copyright (C) 2007 Free Software Foundation, Inc.
+# Written by Noah Misch, 2007
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_BANNER([Constructors.])
+
+AT_SETUP([C++ static constructors])
+LT_AT_TAG([CXX])
+AT_KEYWORDS([libtool])
+
+AT_DATA(class.h,
+[[class Foo {
+public:
+ Foo() { bar = 0xaabbccdd; }
+ unsigned bar;
+};
+
+extern Foo instance;
+]])
+
+AT_DATA(libctor.cpp,
+[[#include class.h
+Foo instance;
+]])
+
+AT_DATA(main.cpp,
+[[#include class.h
+
+int main(int argc, char **argv)
+{
+ return instance.bar != 0xaabbccdd;
+}
+]])
+
+AT_CHECK([$LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS
$CXXFLAGS \
+ -c libctor.cpp -o libctor.lo], [0], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS
$CXXFLAGS \
+ -c main.cpp -o main.lo], [0], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS \
+ libctor.lo -o libctor.la -rpath /none], [0], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS \
+ main.lo libctor.la -o main], [0], [ignore], [ignore])
+
+LT_AT_EXEC_CHECK([./main], [0])
+
+AT_CLEANUP
--
Jeff Squyres
Cisco Systems
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: .ctor section of shared libraries with PathScale compiler
After some more off-list mails with Ralf, I found that non-trivial
patches to Libtool must be accompanied by a copyright transfer to the
FSF (this is FSF policy).
I understand the rationale for this policy, but I'm told by Cisco
lawyers that we cannot do this, unfortunately (long, uninteresting
reasons). So the patch that I sent will not make it into Libtool.
I'm told that I can describe the patch in implementation-free terms
in the hope that someone else can implement it who either can setup
to transfer copyright to the FSF or already has such a transfer
agreement in place.
The patch is very simple. It's a test that makes a shared library
containing a single instance of a class in the global scope. The
class has a specific constructor that should be invoked before main()
(since the instance is in the global scope). It is easy enough to
test whether the constructor has run before main(); if it has, the
test passes. If it has not, the test fails.
Hope that helps.
On Apr 23, 2007, at 10:28 AM, Jeff Squyres wrote:
With some off-list help from Ralf, I was able to create a .at test
that shows the problem (see attached).
I'm sure you guys will want to tweak it a bit more (e.g., it
blindly uses -shared and doesn't check to see if Libtool has shared
library support).
The test itself is pretty simple:
- a shared library is created with a global instance of a class
that has a static constructor. This constructor should fire before
main().
- a trivial application is linked against this library and simply
checks to see if the constructor for the global object has fired.
The C++ portion of the test could probably be made a little more
simple if desired -- I was testing for something slightly different
when we Googled and found the old libtool posting.
The specific cause for the failure is what Peter originally posted
-- Libtool is not properly snarfing all the extra libraries/flags
from pathCC that it needs (e.g., the library that ensures to call
static initializer constructors on global objects).
If you configure libtool with the pathscale suite, you'll see the
problem, and test 50 will fail (at least, it's test 50 for me):
% ./configure CC=pathcc CXX=pathCC FC=pathf90 F77=pathf77
[...lots of output...]
% make TESTSUITEFLAGS=50 check-local
abs_srcdir=`CDPATH=${ZSH_VERSION+.}: cd . pwd`; cd tests; \
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite \
MAKE=make CC=pathcc CFLAGS=-g -O2 CPP=pathcc -E
CPPFLAGS= LD=/usr/bin/ld -m elf_x86_64 LDFLAGS= LIBS=-ldl
LN_S=ln -s NM=/usr/bin/nm -B RANLIB=ranlib OBJEXT=o
EXEEXT= SHELL=/bin/sh CONFIG_SHELL=/bin/sh CXX=pathCC
CXXFLAGS=-g -O2 CXXCPP=pathCC -E F77=pathf77 FFLAGS=
FC=pathf90 FCFLAGS=-g -O2 GCJ=gcj GCJFLAGS=-g -O2
_lt_pkgdatadir=/home/jsquyres/cvs/libtool LIBTOOLIZE=/home/
jsquyres/cvs/libtool/libtoolize LIBTOOL=/home/jsquyres/cvs/
libtool/libtool tst_aclocaldir=/home/jsquyres/cvs/libtool/libltdl/
m4 50
## ##
## libtool 2.1a test suite. ##
## ##
50: simple test FAILED
(pathscale-ctor.at:69)
...etc.
With gcc, it works fine.
Hope this test is helpful.
pathscale-ctor.at
On Apr 23, 2007, at 1:26 AM, Ralf Wildenhues wrote:
[ http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5697
http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5465 ]
Hello all, and apologies for the huge delay,
* Peter Wainwright wrote on Sun, Jul 23, 2006 at 11:06:36PM CEST:
I'm trying to compile a large existing project which uses libtool,
using the PathScale C++ compiler.
This project has several shared libraries. I found that
the constructors for the global objects in these libraries were not
being called at all. It turns out that the order of linking objects
is wrong: it goes
my objects... crtbeginS.o crtendS.o
instead of
crtbeginS.o my objects... crtendS.o
[...]
* Jeff Squyres wrote on Sat, Apr 21, 2007 at 03:09:45AM CEST:
Greetings Libtool! Long-time Libtool fan here, reporting that we
ran
into the exact same bug as described on this list about 8 months ago
by Peter Wainwright:
http://www.mail-archive.com/bug-libtool@gnu.org/msg00899.html
There was no reply to Peter's post on the list; did anyone have a
chance to look at his patch, perchance?
It was still sitting in my ever-longer queue; sorry.
I think a fix for this issue would be a lot easier for me together
with
a testcase (along the lines of HEAD's tests/template.at) that exposes
this issue. A small self-contained (portable!) example would be a
good
start. This helps ensure that we don't regress with other unrelated
compilers. (And testing will then allow me to evaluate whether the
patch Peter suggested is good enough.)
Thanks,
Ralf
--
Jeff Squyres
Cisco Systems
--
Jeff Squyres
Cisco Systems
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org
Re: .ctor section of shared libraries with PathScale compiler
With some off-list help from Ralf, I was able to create a .at test
that shows the problem (see attached).
I'm sure you guys will want to tweak it a bit more (e.g., it blindly
uses -shared and doesn't check to see if Libtool has shared library
support).
The test itself is pretty simple:
- a shared library is created with a global instance of a class that
has a static constructor. This constructor should fire before main().
- a trivial application is linked against this library and simply
checks to see if the constructor for the global object has fired.
The C++ portion of the test could probably be made a little more
simple if desired -- I was testing for something slightly different
when we Googled and found the old libtool posting.
The specific cause for the failure is what Peter originally posted --
Libtool is not properly snarfing all the extra libraries/flags from
pathCC that it needs (e.g., the library that ensures to call static
initializer constructors on global objects).
If you configure libtool with the pathscale suite, you'll see the
problem, and test 50 will fail (at least, it's test 50 for me):
% ./configure CC=pathcc CXX=pathCC FC=pathf90 F77=pathf77
[...lots of output...]
% make TESTSUITEFLAGS=50 check-local
abs_srcdir=`CDPATH=${ZSH_VERSION+.}: cd . pwd`; cd tests; \
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite \
MAKE=make CC=pathcc CFLAGS=-g -O2 CPP=pathcc -E
CPPFLAGS= LD=/usr/bin/ld -m elf_x86_64 LDFLAGS= LIBS=-ldl
LN_S=ln -s NM=/usr/bin/nm -B RANLIB=ranlib OBJEXT=o EXEEXT=
SHELL=/bin/sh CONFIG_SHELL=/bin/sh CXX=pathCC CXXFLAGS=-g -O2
CXXCPP=pathCC -E F77=pathf77 FFLAGS= FC=pathf90 FCFLAGS=-g -
O2 GCJ=gcj GCJFLAGS=-g -O2 _lt_pkgdatadir=/home/jsquyres/cvs/
libtool LIBTOOLIZE=/home/jsquyres/cvs/libtool/libtoolize LIBTOOL=/
home/jsquyres/cvs/libtool/libtool tst_aclocaldir=/home/jsquyres/cvs/
libtool/libltdl/m4 50
## ##
## libtool 2.1a test suite. ##
## ##
50: simple test FAILED (pathscale-
ctor.at:69)
...etc.
With gcc, it works fine.
Hope this test is helpful.
pathscale-ctor.at
Description: Binary data
On Apr 23, 2007, at 1:26 AM, Ralf Wildenhues wrote:
[ http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5697
http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5465 ]
Hello all, and apologies for the huge delay,
* Peter Wainwright wrote on Sun, Jul 23, 2006 at 11:06:36PM CEST:
I'm trying to compile a large existing project which uses libtool,
using the PathScale C++ compiler.
This project has several shared libraries. I found that
the constructors for the global objects in these libraries were not
being called at all. It turns out that the order of linking objects
is wrong: it goes
my objects... crtbeginS.o crtendS.o
instead of
crtbeginS.o my objects... crtendS.o
[...]
* Jeff Squyres wrote on Sat, Apr 21, 2007 at 03:09:45AM CEST:
Greetings Libtool! Long-time Libtool fan here, reporting that we ran
into the exact same bug as described on this list about 8 months ago
by Peter Wainwright:
http://www.mail-archive.com/bug-libtool@gnu.org/msg00899.html
There was no reply to Peter's post on the list; did anyone have a
chance to look at his patch, perchance?
It was still sitting in my ever-longer queue; sorry.
I think a fix for this issue would be a lot easier for me together
with
a testcase (along the lines of HEAD's tests/template.at) that exposes
this issue. A small self-contained (portable!) example would be a
good
start. This helps ensure that we don't regress with other unrelated
compilers. (And testing will then allow me to evaluate whether the
patch Peter suggested is good enough.)
Thanks,
Ralf
--
Jeff Squyres
Cisco Systems
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Pathscale compiler bug
Greetings Libtool! Long-time Libtool fan here, reporting that we ran into the exact same bug as described on this list about 8 months ago by Peter Wainwright: http://www.mail-archive.com/bug-libtool@gnu.org/msg00899.html There was no reply to Peter's post on the list; did anyone have a chance to look at his patch, perchance? We solved the issue in Open MPI by providing 2 slightly-modified versions of Peter's patch in our source tree -- one for LT 1.5.22 and one for LT 2.1a. We tested these patches on a variety of Linux compilers (gcc 3.4.3, Intel 9.1, PGI 6.2, Pathscale 3.0), and it seems to work for all of them. The patches will be getting more wide- spread testing as the change propagates out to the other Open MPI organizations through our automated testing framework over the next week or so. Is there any chance that this can be fixed for the final LT 2.1 release? Thanks! -- Jeff Squyres Cisco Systems ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Problem with LT 2.1a
Greetings. I'm a longtime Libtool user; we've used both Libtool and libltdl in LAM/MPI and Open MPI (among dozens of other packages!). I've said it before, but I'll say it again -- thanks bunches for Libtool! I have no idea what we'd do without it (and for all the help that Ralf W. and others have provided us over the years). We have run into a problem with LT 2.1a, however (no worries; we realize that it's as-yet unreleased). It took a little poking around to realize what the problem really is: that LT 2.1a's libltdl is no longer lt_dlopen()'ing plugins on Linux with RTLD_GLOBAL. Short version: can libltdl be augmented to allow users to optionally specify using RTLD_GLOBAL? This would solve our problem. Longer version: The situation is as follows: 1. Open MPI has a plugin (call it ompi_plugin) that is linked against a shared library (libibverbs.so). 2. At run time, ompi_plugin is lt_dlopen()'ed by the OMPI core. 3. The code in libibverbs in ompi_plugin eventually dlopen()'s its own plugin (named mthca.so; this is a Linux-specific plugin, so libibverbs directly uses dlopen(), not lt_dlopen()) 4. mthca.so requires some symbols in libibverbs, but is not linked against it. With LT 1.5.22, this works fine. With LT 2.1a, it doesn't because LT 2.1a's lt_dlopen() no longer uses RTLD_GLOBAL. Specifically, the dlopen() of mthca.so fails because it can't access the symbols from libibverbs that are already loaded in the process. This is actually a pretty big problem for us; we do not have direct control over the upstream libibverbs (I might be able to get it changed to link mtcha.so against libibverbs.so, but there would be at least 2 released, stable versions of libibverbs that would not work with Open MPI). I certainly understand the desire to not use RTLD_GLOBAL for everything; separate namespaces are generally a Good Thing. I guess my appeal is to allow the caller of lt_dlopen() to optionally specify that they want to use RTLD_GLOBAL. This would solve our problem. Are there any estimates of how many other applications will be hurt by this change to libltdl? We might be among the first of many to ask about this. :-) -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ http://lists.gnu.org/mailman/listinfo/libtool
OMPI workaround (was: Problem with LT 2.1a)
On 9/6/06 11:10 AM, Ralf Wildenhues [EMAIL PROTECTED] wrote: First let me try to point out a workaround for your specific situation: Since mthca.so is Linux-specific, we can rely on having dlopen available for the workaround. Since I assume you would rather not have to modify the part (3), let's modify (2): Before dlopen(mthca.so) inside libibverbs, let ompi_plugin do an explicit dlopen(libibverbs.so, RTLD_GLOBAL). This should cost almost nothing (no system calls involved, since libibverbs.so is already opened), and should make the set of symbols available for the subsequent mthca.so. Do I understand correctly that since you do not use the lt_dl*search* functions anyway, adding this functionality to opal would be rather painless? (changed the subject to differentiate this reply from the rest of the thread) Actually, I wouldn't put it in opal, but rather in the ompi_plugin directly, because at least currently, it's only a problem for one specific OMPI plugin (specifically, the OpenIB BTL plugin). However, the problem here is that this depends on the C code knowing exactly where the library is. This unfortunately matters for at least one important scenario: the OFED installer (Open Fabrics Enterprise Distribution -- currently, an InfiniBand software stack installer) builds RPMs for all of its software (including OMPI) in a temporary tree. This includes packages that depend on each other (e.g., OMPI depends on libibverbs). Hence, the libibverbs RPM is created and its [staging] installation tree is simply not deleted. Other packages that depend on the libibverbs are expected to use the [staging] installation tree. Once all of OFED is built, all the RPM build/install trees are deleted. Installing the RPMs then installs the software into the real locations (and therefore dependencies change). Currently, OMPI skirts this problem because OMPI is only built once the rest of OFED is installed in their final locations. I am currently tasked with making OMPI be able to be built when all the rest of the OFED software is built (not after the fact, like it is now). Ralf W. and I have had extensive discussions about this and I have not yet had time to try his suggestion (link directly to libibverbs.la in the staging installation tree instead of -L/staging/install/tree -libverbs). But the point remains here that if we go the dlopen() route, then the C code needs to be aware of where libibverbs is -- and at least in this scenario, it could be in one of two places (and at build time, I won't know that). The C code could simply traverse LD_LIBRARY_PATH and look for libibverbs, but that then subverts the ld.so mechanisms and also generally seems icky. -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: PGI and C++ templates
On Mar 14, 2005, at 1:49 PM, Ralf Wildenhues wrote:
I've long since added my own m4 to my configure scripts to see if the
C++ compiler uses a template subdirectory, and if so, add it to
CLEANFILES.
Can you be bothered to share it with us? Has it hung enough to be
considered for Automake?
Sure -- it's attached.
I don't know if it's good enough to be considered for AM; it's really
a shotgun approach (I don't know anything about their coding
standards):
- make a temp dir, cd into it
- compile some C++ stuff that contains templates
- remove all known files
- see what files/dirs are left
There's probably other ways to do it; I have dim recollections of this
macro coming into existence around 3am one night... :-)
(looking at this code again -- it's been years since I've examined it
-- there's a *lot* that would need to be cleaned up and generalized; I
am realizing how much I didn't know about AC when I wrote that macro --
it's embarrassing! ;-) The shotgun approach idea can be extracted from
this code, if it's useful -- that's probably about it)
Has something changed that I no longer need to do this?
We might want to have something like it.
That would be fantastic.
[Template.dir stuff snipped]
I'll let the PGI people reply to this stuff...
Does anybody have some real-world code using C++/templates/libraries
that I (or, even better, you) can test with (and that is not too
complicated to set up)?
'fraid not. We only needed C libraries to build with LAM/MPI -- the
C++ templating issue came up after that was solved. Sorry! :-(
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
cxx_find_template_repository.m4
Description: Binary data
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: PGI and C++ templates
-test % find .
.
./src
./src/foo.cc
./src/Template.dir
./src/foo.o
-
So it looks like pgCC is smart enough to figure this kind of situation
out.
At which time is Template.dir populated (and which dir, in the case of
subdir-objects)? Is is maybe possible to specify the Template.dir with
another parameter (this might be necessary in special cases only)?
Both questions answered above.
Achive or build the shared library as before, except you must include
the new hidden templates in the Template.dir directory:
$ ar qv lib_mylib.a Template.dir/*.o file1.o file2.o etc.
Same questions as above.
I'm guessing a simple test for Template.dir/*.o is good enough to know
whether to include that on the ar command line or not.
Is there any way someone can add this to Libtool (preferably both
1.5.x and 2.0.x), or provide me with some guidance on how to do so? (I
did ok in tinkering around to add simple command line switch
changes,
but the multi-step outlined procedure would take me a lng time to
figure out).
I'd love this to work better with Libtool. One thing that kept me from
putting a solution for one compiler in (apart from the fact that I had
not delved deep into PGCC) is that similar things might be necessary
for
SGI C++ and others. Where possible, larger code snippets should be
factored out. Maybe this is not necessary.
Let's see how far we get with PGI, we can still do refactoring later.
(BTW, I had even once looked at their online docs, but the questions
above are not answered fully in there.)
Ok.
There's one condition: this is only necessary for PGI compiler
versions
5.2-4 and prior of their compiler. With their most recent version
(soon to be released) -- 6.0 -- none of this is necessary, and what we
have now in Libtool will work just fine (i.e., they cleaned up the
compiler to do templates in libraries much better -- the entire
multi-step process listed above is unnecessary).
Nice.
Here's a quick-n-easy way to get the version of the compiler:
pgcc_major_ver=`pgCC -V | awk '/pgCC/ { print \$2 }' | cut -d. -f1`
pgcc_need_extra=`expr $pgcc_major_ver \ 6`
Can we get the complete output of pgCC?
Would
( set `pgCC -V`; pgcc_major_ver=$2
case $pgcc_major_ver in
[1-5].*) :;;
*) false;;
esac )
suffice as yesno-test (little faster)?
(Note you need to double `[' and `]' in most m4 macros.)
This looks ok to me. I cut-n-paste this into a standalone script and
got the expected $? -- 0.
How does that sound?
Thank you for your work on this.
If you want to start fuddling around with the archive_cmds, one further
hint: `~' is used to delimit commands in the *_cmds libtool variables.
So, if we the subdir stuff turns out to be trivial, we can just add a
command to archive_cmds/archive_expsyms_cmds/old_archive_cmds and be
done mostly.
Cheers,
Ralf
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: PGI and C++ templates
On Mar 7, 2005, at 3:07 AM, Ralf Wildenhues wrote:
Achive or build the shared library as before, except you must include
the new hidden templates in the Template.dir directory:
$ ar qv lib_mylib.a Template.dir/*.o file1.o file2.o etc.
At the moment, Template.dir/ is not cleaned by `make clean'. This
should be done, I'm not sure whether by Automake rules or by Libtool.
But this has always been a problem, right? (i.e., not just with the
PGI compilers)
I've long since added my own m4 to my configure scripts to see if the
C++ compiler uses a template subdirectory, and if so, add it to
CLEANFILES.
Has something changed that I no longer need to do this?
What happens if you have source files which used to provide/use
templates, but no longer do so, but still have objects lying around in
Template.dir/, which now get erroneously added to the static/shared
archive?
This is definitely a problem. :-\
I always just took care to run make clean or manually remove the
template subdirs in those cases. If AM/LT/somebody could take of this
for me, that would be fantastic.
What about objects in Template.dir/ which do not belong to the current
link at all (because they belong in a different library)? Do we have
to know the names of all objects from Template.dir/*.o to use or can
we just add all of them without problems? Remember we may not be
allowed to add exported symbols to the library as that will destroy
runtime (in the case of shared linking) or program-link-time (in the
case of static linking) link order.
Hmm. Good question. I guess one option here may be to use the
--instantiation_dir switch to have a different Template.dir (so to
speak) for each target library...? I'm not quite sure how that would
work, though, because AM would be the one with this knowledge (i.e.,
know which source files belong to which library) -- I don't know how AM
would pass this information down to LT [in a clean manner]...
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
PGI and C++ templates
Can I impose on the good will of a libtool wizard? I could attempt
this myself, but I don't have a good track record mucking around in the
LT source. ;-)
Here's the situation: on branch-1-5, we have good PGI compiler support
-- *except* for libraries with C++ templates. For that, we need some
more work (someone identified this recently -- I'm afraid I don't
remember who). I have mailed the PGI support folks (CC'ed on this
mail) and they have told me what needs to be done (if you care, the
full thread is here:
http://www.pgroup.com/userforum/viewtopic.php?
t=172postdays=0postorder=ascstart=0):
--
For each source file in the library, compile it:
$ pgCC -c --one_instantiation_per_object $(YOUR_FLAGS) file.cc
You must now do an extra pre-link step to instantiate all the templates
used in this library, putting all the library .o's on this line, and no
-c flag.
$ pgCC --one_instantiation_per_object --prelink_objects $(YOUR_FLAGS)
file1.o file2.o etc.
Achive or build the shared library as before, except you must include
the new hidden templates in the Template.dir directory:
$ ar qv lib_mylib.a Template.dir/*.o file1.o file2.o etc.
-
Is there any way someone can add this to Libtool (preferably both
1.5.x and 2.0.x), or provide me with some guidance on how to do so? (I
did ok in tinkering around to add simple command line switch changes,
but the multi-step outlined procedure would take me a lng time to
figure out).
There's one condition: this is only necessary for PGI compiler versions
5.2-4 and prior of their compiler. With their most recent version
(soon to be released) -- 6.0 -- none of this is necessary, and what we
have now in Libtool will work just fine (i.e., they cleaned up the
compiler to do templates in libraries much better -- the entire
multi-step process listed above is unnecessary).
Here's a quick-n-easy way to get the version of the compiler:
pgcc_major_ver=`pgCC -V | awk '/pgCC/ { print \$2 }' | cut -d. -f1`
pgcc_need_extra=`expr $pgcc_major_ver \ 6`
So if $pgcc_need_extra is 1, then we need to do the multi-step
procedure listed above.
How does that sound?
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Portland compiler support
For those not following the libtool-patch list, Peter wrote up a nice
patch that seems to be working perfectly. It's been committed on
branch-1-5.
On Feb 22, 2005, at 5:35 PM, Peter O'Gorman wrote:
Jeff Squyres wrote:
I have recently discovered that the Portland support that I sent
patches in for does not work for shared libraries (a LAM/MPI user
told me this -- not the Portland support group, which I find odd).
The issue is that when making shared libraries with --whole-archive,
the PGI linker needs one big argument
(-Wl,--whole-archive,foo.a,bar.a,baz.a) as opposed to a
space-sparated list (-Wl,--whole-archive foo.a bar.a baz.a).
I'm trolling through the source code to figure out how to do this --
I see that $convenience is built up as a space separated list. I'm
trying to figure out the exact flow of things, but my first
impression is that it might be easiest to just parameterize on the
delimiter ( or ,) in $convenience. Am I off base here?
Hi Jeff,
In a case such as this it would probably be best to set
whole_archive_flag_spec to the empty string. This will cause libtool to
unpack the static archive and add the objects to the link line. I'll
look
and send you a patch to try tonight (JST).
Peter
--
Peter O'Gorman - http://www.pogma.com
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Portland compiler support
On Feb 24, 2005, at 9:37 AM, Jeff Squyres wrote:
For those not following the libtool-patch list, Peter wrote up a nice
patch that seems to be working perfectly. It's been committed on
branch-1-5.
Oops! I lied -- it *hasn't* been committed yet; it's awaiting peer
review.
Sorry for the confusion...
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
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/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Portland compiler support
I just created a toy project based with templated functions on the one
from that thread and I get similar errors. So no, it's not solved.
Do you know the right pgCC mojo to compile libraries with templates?
On Feb 24, 2005, at 9:45 AM, Markus Christen wrote:
Jeff Squyres wrote:
I have recently discovered that the Portland support that I sent
patches in for does not work for shared libraries (a LAM/MPI user
told me this -- not the Portland support group, which I find odd).
HINT: PGI -- I'd really like to hear from you; I heard nothing from
you last time, which ended up in incorrect support for PGI compilers
in Libtool. Let's not get this wrong again and cause confusion for
your customers...
The issue is that when making shared libraries with --whole-archive,
the PGI linker needs one big argument
(-Wl,--whole-archive,foo.a,bar.a,baz.a) as opposed to a
space-sparated list (-Wl,--whole-archive foo.a bar.a baz.a).
I'm trolling through the source code to figure out how to do this --
I see that $convenience is built up as a space separated list. I'm
trying to figure out the exact flow of things, but my first
impression is that it might be easiest to just parameterize on the
delimiter ( or ,) in $convenience. Am I off base here?
(still trolling through the code; I am *not* a Libtool expert!
Comments / suggestions would be appreciated!)
hi
would that take care of the problem with templates and libraries (and
convenience libraries)?
(confirmed by Ralf)
i would still be interested...
thread: portland compiler, convenience libraries and templates
http://lists.gnu.org/archive/html/libtool/2004-12/msg00015.html
thanks
markus
___
http://lists.gnu.org/mailman/listinfo/libtool
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Portland compiler support
I have recently discovered that the Portland support that I sent
patches in for does not work for shared libraries (a LAM/MPI user told
me this -- not the Portland support group, which I find odd).
HINT: PGI -- I'd really like to hear from you; I heard nothing from you
last time, which ended up in incorrect support for PGI compilers in
Libtool. Let's not get this wrong again and cause confusion for your
customers...
The issue is that when making shared libraries with --whole-archive,
the PGI linker needs one big argument
(-Wl,--whole-archive,foo.a,bar.a,baz.a) as opposed to a
space-sparated list (-Wl,--whole-archive foo.a bar.a baz.a).
I'm trolling through the source code to figure out how to do this -- I
see that $convenience is built up as a space separated list. I'm
trying to figure out the exact flow of things, but my first impression
is that it might be easiest to just parameterize on the delimiter (
or ,) in $convenience. Am I off base here?
(still trolling through the code; I am *not* a Libtool expert!
Comments / suggestions would be appreciated!)
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug in libtoolize
On Feb 17, 2005, at 12:59 PM, Albert Chin wrote:
From the autoconf manual:
Commands like `cp -p' and `touch -r' typically do not copy file
timestamps to their full resolutions (*note Limitations of Usual
Tools::). Hence you should be wary of rules like this:
dest: src
cp -p src dest
as `dest' will often appear to be older than `src' after the
timestamp is truncated, and this can cause `make' to do needless
rework the next time it is invoked. To work around this problem,
you can use a timestamp file, e.g.:
dest-stamp: src
cp -p src dest
date dest-stamp
I don't see any signs in it of `cp -p' being non-portable.
If this is true, then even if -p is portable, it potentially won't
solve the problem. :-\
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Bug in libtoolize
I have found a bug in libtoolize which has bit me for a long, long time
but I've never gotten around to checking it out (it was a minor
annoyance). But today, it bit one of my other developers in a rather
awkward moment. So I guess it's time to investigate and report this
bug. :-)
The problem is with libtoolize --copy --ltdl. libtoolize makes the
subdirectory libltdl/ and copies all the relevant files over. However,
the problem is that it simply globs the files from the source directory
and then copies them over one-by-one. This can violate the strict
ordering of files required by Automake and can cause needless
re-building of files, even after a successful run of libltdl's
configure script.
In my developer's case, the following happened:
--
libtoolize --copy --ltdl
cd libltdl
./configure .
[configure runs successfully]
make -d
--
Here's the end of the output from make -d:
-
No need to remake target `configure.ac'.
Considering target file `aclocal.m4'.
Pruning file `acinclude.m4'.
Pruning file `configure.ac'.
Finished prerequisites of target file `aclocal.m4'.
Prerequisite `acinclude.m4' is older than target `aclocal.m4'.
Prerequisite `configure.ac' is newer than target `aclocal.m4'.
Must remake target `aclocal.m4'.
cd . /bin/bash [/path/to]/libltdl/missing --run aclocal-1.8
-
Doh! That shouldn't be!
Checking the fine-grained timestamps, we can see that yes, indeed,
acinclude.m4 is older than aclocal.m4. So let's try a controlled
experiment:
-
$ rm -rf libltdl
$ libtoolize --automake --copy --ltdl
$ cd libltdl/
$ /usr/local/gnu/bin/ls --full-time ac*
-rw-r--r-- 1 jsquyres lam 226073 2005-02-15 18:48:58.458929000 -0500
acinclude.m4
-rw-r--r-- 1 jsquyres lam 35379 2005-02-15 18:48:58.478986000 -0500
aclocal.m4
-
Yowza!
Looking in the code for libtoolize (v1.5.14), I see the following:
-
if test x$ltdl = xyes; then
test -d libltdl || $mkdir libltdl
ltdlfiles=`cd $pkgdatadir ls libltdl/*`
else
ltdlfiles=
fi
for file in $ltdlfiles; do
if test -f $file test -z $force; then
test -z $automake echo $progname: \`$file' exists: use
\`--force' to overwrite 12
continue
fi
$rm $file
if test -n $ln_s $ln_s $pkgdatadir/$file $file; then :
elif $cp $pkgdatadir/$file $file; then :
else
echo $progname: cannot copy \`$pkgdatadir/$file' to \`$file' 12
status=1
fi
done
-
This quite definitely does not honor any ordering of the copy -- so the
dependencies that Automake sets up in its Makefiles are potentially
going to be violated (as it is in my case).
Some suggestions for a fix:
1. Do the copy as now, but then have a series of touch statements to
modify the mtime/ctime all the relevant AM-specific files in the Right
Order so that the timestamps will be proper.
2. Copy the files over in order in the first place (i.e., don't use a
glob).
3. Tar up the source directory and untar it in the destination.
Each of the three has benefits and drawbacks -- I guess I'd lean
towards #1. It's probably the least elegant, but it guarantees to get
it Right with the least amount of work.
Thanks!
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Our IT Services
Wow -- this is a great opportunity to finally move the libtool web site
offshore!
;-)
On Feb 11, 2005, at 11:37 AM, Consultants wrote:
Hi ,
I hope things are going well, at your end.
This is my periodic check with you to see how can I help with your
current need for IT Consultants with your company? CGT Consulting
provides highly specialized contract consultants for immediate
results. We maintain a base of deployable consultants in the areas of
ERP, CRM, Wireless and Web-based technology. In addition, CGT draws
from an immense in-house database of over 1 Million candidates.
We provide the following services:
1) IT Consultants / IT Contractors
2) Help you fill your Full Time Employee positions, including
contract-to-hire
3) Offshore Services:
a) Customer Service
b) Website Development Maintenance
c) Offshore Projects
d) Database Development Maintenance
e) Offshore Employee Leasing
We are committed to fast and effective technology services paired with
a unique corporate philosophy of Cost-Conscious Consulting / Offshore
Solutions.
How can I be of service, to you and your company?
Thank you.
Naren Mistry
Manager of Consulting Services
CGT Consulting Inc.
18032-C Lemon Drive, Suite 350
Yorba Linda, CA 92886
Tel: (714) 572-1055 - 714-579-1248
Fax: (714) 364-9705
[EMAIL PROTECTED]
www.cgt-consult.com
Emailed to: libtool@gnu.org
Anti-SPAM Policy Disclaimer:
mailto:[EMAIL PROTECTED]
Under Bill s.1618 Title III passed by the 105th U. S. Congress, mail
cannot be considered Spam as long as we include contact information
and a remove link for removal from our mailing list. If this e-mail is
unsolicited, please accept our apologies and click on the following
removal link:
mailto:[EMAIL PROTECTED] or
reply back with REMOVE in the SUBJECT with this email address:
libtool@gnu.org
___
http://lists.gnu.org/mailman/listinfo/libtool
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Problem with LT 1.5.12: -pthread
It looks like LT 1.5.12 changed some behavior with respect to the
-pthread flag and the GNU compilers. Here's a snipit of output from
building my project (using AM + LT):
/bin/sh ../../../libtool --mode=link g++ -g -Wall -Wundef
-Wno-long-long -finline-functions -pthread -export-dynamic -o
ompi_info components.o ompi_info.o output.o param.o version.o
../../../src/libmpi.la
# So far, so good -- this is pretty normal.
mkdir .libs
# Also so far, so good.
g++ -g -Wall -Wundef -Wno-long-long -finline-functions -o ompi_info
components.o ompi_info.o output.o param.o version.o
-Wl,--export-dynamic ../../../src/.libs/libmpi.a -ldl
# Whoa! What happened to -pthread?
From here, I get lots of [expected] messages about missing pthread
symbols. This is somewhat of a Big Problem; it did not happen with
1.5.10 -- meaning that -pthead was passed down to the final link in
(ditto for LT 1.5.10 that I can remember).
What happened?
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Problem with LT 1.5.12: -pthread
I would clearly vote for it. :D
I think that any project that uses AM+LT for compiling multi-threaded
applications that uses any of those flags will fail to link properly,
right? And these flags (-pthread, -mt, etc.) are typically the
recommended method of compiling / linking multi-threaded applications.
So I'd say that it's probably a pretty big problem. :-\
On Feb 7, 2005, at 11:01 PM, Peter O'Gorman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Squyres wrote:
|
| From here, I get lots of [expected] messages about missing pthread
| symbols. This is somewhat of a Big Problem; it did not happen with
| 1.5.10 -- meaning that -pthead was passed down to the final link in
| (ditto for LT 1.5.10 that I can remember).
|
| What happened?
|
I broke it :(
I applied the attached patch to the branch last night. The ltmain.in
bit
should apply to your ltmain.sh too.
Opinions on how badly broken this is are welcome, perhaps I need to
release
a 1.5.14? :((
Peter
- --
Peter O'Gorman - http://www.pogma.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (Darwin)
iQCVAwUBQgg5fLiDAg3OZTLPAQKvpgP+Kwk7tSTDicU5k7fd0NUgNAqmqUUNeTux
lbY02iohCZJyXoUOSc1b96N+kl7JQo1eMUsTX9RUV+hViXKc6BlUpWhy58OsDGMl
TdQ0B4izFqz2d7RLP1q5iTvXe3UKHsfzyGHl+z0f0A/lO2ECN8i8rdhlUOfDJMuN
RsXSPOpnD/I=
=bLom
-END PGP SIGNATURE-
Index: ChangeLog
2005-02-07 Peter O'Gorman [EMAIL PROTECTED]
* ltmain.in: Add -pthread like flags when linking executables too.
Reported by Andreas Schwab [EMAIL PROTECTED]
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.60
diff -u -3 -p -u -r1.334.2.60 ltmain.in
--- ltmain.in 5 Feb 2005 13:59:47 - 1.334.2.60
+++ ltmain.in 7 Feb 2005 14:02:09 -
@@ -1525,6 +1525,8 @@ EOF
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe)
compiler_flags=$compiler_flags $arg
+ compile_command=$compile_command $arg
+ finalize_command=$finalize_command $arg
continue
;;
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Trying to run 2.1a test suite
Ah -- excellent! I think someone said this (work in the branch-2-0
branch), but I ignored it and worked on the trunk because I foolishly
assumed that they were effectively the same (note to self: your own
development practices are not the same as everyone else's! ;-) ).
On Nov 24, 2004, at 3:05 AM, Ralf Wildenhues wrote:
Hi Jeff,
* Jeff Squyres wrote on Tue, Nov 23, 2004 at 08:12:43PM CET:
I'm working on the Portland Group compilers patch for both the libtool
CVS HEAD and the 1-5 branch (both are attached), and as suggested, am
trying to run the make check test suite against the CVS HEAD (it
passes on the 1-5 branch).
However, make check does not appear to be running properly at the
head (or, more specifically, I can't get it to run right). I've
attached the testsuite.log.pgi and testsuite.log.gnu file to show what
I mean (trying to use both the Portland and GNU compilers,
respectively). It seems like some paths are incorrect, and it can't
find some subdirectories.
Yes. The HEAD testsuite is somewhat borked at the moment.
The branch-2-0 testsuite, however, should be running just fine.
I hoped you would be using that (would have saved you some grief).
Now if you would just try to apply your HEAD patch to branch-2-0 and
the test suite doesn't complain, I'll commit your patches. If you're
short on time, it should be sufficient to run all the f77* tests --
their behavior changed the most. Report SKIPs as well as FAILs,
please.
*snip*
Both testsuite logs show the same kinds of failures.
Am I doing something wrong? (similar behavior occurs with
gcc/g++/g77)
Nope, as far as I can tell. We need to fix the HEAD testsuite.
Sorry for the inconvenience.
Regards,
Ralf
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Patches for Portland Group (aka pgi) compiler support
(I figured I'd start this in a different thread so that it would be
easy to find when searching; the patches are identical to what I
submitted before, but in the interest of tying this all up in one
thread...)
I've attached 2 patches to libtool.m4 -- one for branch-1-5 and one for
branch-2-0 -- that add support for the Portland Group pgcc, pgCC, and
pgf77 compilers to Libtool. Both pass their respective test suites.
The 2-0 patch ended its test suite with:
All 115 tests passed
(no tests were skipped or failed)
Thanks!
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
lt-1-5-pgi.patch
Description: Binary data
lt-2-0-pgi.patch
Description: Binary data
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Trying to run 2.1a test suite
I'm working on the Portland Group compilers patch for both the libtool
CVS HEAD and the 1-5 branch (both are attached), and as suggested, am
trying to run the make check test suite against the CVS HEAD (it
passes on the 1-5 branch).
However, make check does not appear to be running properly at the
head (or, more specifically, I can't get it to run right). I've
attached the testsuite.log.pgi and testsuite.log.gnu file to show what
I mean (trying to use both the Portland and GNU compilers,
respectively). It seems like some paths are incorrect, and it can't
find some subdirectories.
Here's the script that I'm using to run the tests:
-
rm -rf autoconf-2.59 libtool-1.5.8 automake-1.9.3 /tmp/bogus
tar zxf autoconf-2.59.tar.gz
cd autoconf-2.59
./configure --prefix=/tmp/bogus
make all install
cd ..
export PATH=/tmp/bogus/bin:$PATH
tar zxf automake-1.9.3.tar.gz
cd automake-1.9.3
./configure --prefix=/tmp/bogus
make all install
cd ..
tar zxf libtool-1.5.8.tar.gz
cd libtool-1.5.8
./configure --prefix=/tmp/bogus
make all install
cd ..
rm -rf libtool
cvs -z3 -d :ext:[EMAIL PROTECTED]:/cvsroot/libtool co libtool
cd libtool
# This patch is my pgi work; a patch to m4/libtool.m4
patch -p0 ../lt-head-pgi.patch
cp m4/*m4 /tmp/bogus/share/aclocal
./bootstrap
./configure CC=pgcc CXX=pgCC F77=pgf77 --prefix=/tmp/bogus
make all install
make check
--
Attached files:
- lt-1-5-pgi.patch: patch for the 1-5 branch to include support for the
Portland compilers
- lt-head-pgi.patch: patch for the CVS HEAD to include support for the
Portland compilers
- testsuite.log.pgi: testsuite.log from the CVS HEAD's make check
using the Portland compilers
- testsuite.log.gnu: testsuite.log from the CVS HEAD's make check
using the GNU compilers
Both testsuite logs show the same kinds of failures.
Am I doing something wrong? (similar behavior occurs with gcc/g++/g77)
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
lt-1-5-pgi.patch
Description: Binary data
lt-head-pgi.patch
Description: Binary data
testsuite.log.pgi
Description: Binary data
testsuite.log.gnu
Description: Binary data
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
On Nov 18, 2004, at 3:49 AM, Ralf Wildenhues wrote:
I did [at least] one questionable thing: in the Linux linker
section, I had to check for pgf77 or pgf90, because, contrary to the
PG
documentation, pgf77 and pgf90 need an additional -fpic in their
linker command to create a shared library properly.
Is this necessary for just a regular shared library or for a shared
module (that can be loaded with dlopen)? If the former, then I think
your patch is ok.
It seems to be necessary even for normal shared libraries -- without
it, I get an error from the Portland linker.
Glancing at libtool.m4, there are a number of cases where it's
necessary, maybe we should put them in a separate variable, like
pic_link_flag or so. That'll only be for libtool HEAD, though.
Sounds reasonable.
Here's the revised patch (including some fixes from this morning;
based
on tests, not the PG documentation ;-) ):
Note that branch-2-0 tests are somewhat more challenging, esp. on the
Fortran front. I might want to wait with applying this patch until you
get to those (in case you find out more necessary stuff there).
Other than that, I'll take the patch.
That sounds like a reasonable plan. Let me port this over to the CVS
HEAD and see if it helps refine the 1.5 patch. Today's pretty hosed
for me; I can probably get to this tomorrow or over the weekend.
Many thanks.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Patch for Portland compiler support
Greetings.
As I've posted to the list before, we use libtool in some fairly large
software packages. Thanks for all the excellent work on libtool!
Some of the consumers of our software use the Portland Group compilers
(http://www.pgroup.com/). Libtool 1.5.x doesn't seem to recognize
these compilers, and therefore doesn't always do the Right Things.
I have *barely* dived into the libtool source, but I have come up with
a patch for the current CVS branch-1-5 that seems to make libtool do
the Right Things for pgcc on Linux (I didn't try for an analogue on the
CVS trunk for the 2.x series). Could this patch be considered for
future releases of Libtool?
[5:51] hbar:~/libtool % cvs diff libtool.m4
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.50
diff -u -r1.314.2.50 libtool.m4
--- libtool.m4 19 Sep 2004 12:13:50 - 1.314.2.50
+++ libtool.m4 17 Nov 2004 13:54:58 -
@@ -4952,6 +4952,11 @@
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
+ pgcc*)
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+;;
ccc*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
# All Alpha code is PIC.
Please forgive me if this patch is egregiously wrong -- if it is, any
advice on making it Right would be tremendously appreciated!
Many thanks for your time.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
On Nov 17, 2004, at 9:38 AM, Ralf Wildenhues wrote:
Some of the consumers of our software use the Portland Group compilers
(http://www.pgroup.com/). Libtool 1.5.x doesn't seem to recognize
these compilers, and therefore doesn't always do the Right Things.
Libtool doesn't know about Portland's compilers at all (so far).
Gotcha.
I have *barely* dived into the libtool source, but I have come up with
a patch for the current CVS branch-1-5 that seems to make libtool do
the Right Things for pgcc on Linux (I didn't try for an analogue on
the
CVS trunk for the 2.x series). Could this patch be considered for
future releases of Libtool?
Actually, I'm wondering about the name. There has once been a pentium
gcc, abbreviated pgcc as well. How unfortunate :(
I don't know how much the pentium gcc is still in use, but the fact
that
this one is not meant deserves at least a comment within the m4
snippet.
Looking at its webpage, it looks pretty dead, though.
Yikes! I had no idea about pentium-gcc. I trust your judgment on this
one -- if it's ok with you guys to ignore, I'm happy to ignore it, too.
;-)
(Fortunately, gcc on linux understands all the variable values you've
submitted so far. We might just get away with it anyway.)
But certainly there will be more problems with pgcc? What about pgf77
and pgCC? Could you or one of your consumers be bothered to try
branch-2-0 of libtool (1.9f will do fine as well) and report us more
possible problems its testsuite reports (VERBOSE=x output for failed
tests is good), so that we can support it right, not only halfway?
(This is the more interesting for you since we won't bother much with
libtool-1.5 any more as soon as 2.0 is out).
Shirley -- I can do this right now. I'll post back shortly.
Do you/your consumers use pgcc on Windows? That's probably going to be
a whole different (and scarier) story.
Unfortunately, no. We have a Cygwin port, but to my knowledge people
only use gcc with it there.
[snippage]
Please forgive me if this patch is egregiously wrong -- if it is, any
advice on making it Right would be tremendously appreciated!
Looks good. The branch-2-0 equivalent would be similar -- just grep
for
ccc in libtool/m4/libtool.m4.
Will do.
I'll check into CC/f77 issues and post back with a new set of patches
-- for 1.5.x and 2.x.
Thanks!
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
