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
Hi Jeff, * Jeff Squyres wrote on Wed, Nov 17, 2004 at 03:00:22PM CET: > > 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). > 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. (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). Do you/your consumers use pgcc on Windows? That's probably going to be a whole different (and scarier) story. Other than that, we love ChangeLog entries. :) > --- 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! Looks good. The branch-2-0 equivalent would be similar -- just grep for ccc in libtool/m4/libtool.m4. Regards, Ralf ___ 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
Re: libtool 1.5.6 still not supporting make distcheck
On Tue, Nov 16, 2004 at 06:32:51PM -0800, Jacob Meuser wrote: > curious also what's in ../utils/libopenhpiutils.la > > probably > > installed=yes > > and > > libdir='/home/sdague/openhpi/openhpi-1.9.3/_inst/lib' > > but openhpi/openhpi-1.9.3/_build/utils/libopenhpiutils.la contains the following: ... # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/home/sdague/openhpi/openhpi-1.9.3/_inst/lib' > /home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so > doesn't yet exist? Nothing exists in _inst except directories, as this phase of make distcheck is happening after it has done make uninstall on the _inst directory. If I scroll back through the logs a little I see the following: make[3]: Entering directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' make[4]: Entering directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' /bin/sh ../../mkinstalldirs /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib mkdir -p -- /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libopenhpiutils.la /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.la /usr/bin/install -c .libs/libopenhpiutils.so.1.9.3 /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so.1.9.3 (cd /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib && rm -f libopenhpiutils.so.1 && ln -s libopenhpiutils.so.1.9.3 libopenhpiutils.so.1) (cd /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib && rm -f libopenhpiutils.so && ln -s libopenhpiutils.so.1.9.3 libopenhpiutils.so) /usr/bin/install -c .libs/libopenhpiutils.lai /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.la /usr/bin/install -c .libs/libopenhpiutils.a /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.a ranlib /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.a chmod 644 /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.a libtool: install: warning: remember to run libtool --finish /home/sdague/openhpi/openhpi-1.9.3/_inst/lib' /bin/sh ../../mkinstalldirs /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/pkgconfig mkdir -p -- /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/pkgconfig /usr/bin/install -c -m 644 openhpiutils.pc /home/sdague/tmp/am-dc-21193//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/pkgconfig/openhpiutils.pc make[4]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' make[3]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' make[2]: Leaving directory /home/sdague/openhpi/openhpi-1.9.3/_build/utils' Which looks all well and good, *except*: dargo:~> find /home/sdague/tmp/am-dc-21193 find: /home/sdague/tmp/am-dc-21193: No such file or directory I don't see anything in the make output that should have removed this. > maybe this patch helps? > > --- ltmain.in.origTue Aug 3 00:49:02 2004 > +++ ltmain.in Sat Aug 7 17:00:56 2004 > @@ -2611,7 +2611,7 @@ EOF > add_dir= > add= > # Finalize command for both is simple: just hardcode it. > - if test "$hardcode_direct" = yes; then > + if test "$hardcode_direct" = yes && test -f $libdir/$linklib; then > add="$libdir/$linklib" > elif test "$hardcode_minus_L" = yes; then > add_dir="-L$libdir" I've applied this patch, but still no luck. :( Thanks for the attempt though. -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpGaVSzxqDMK.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
On Tue, Nov 16, 2004 at 09:49:46PM -0600, Bob Friesenhahn wrote: > On Tue, 16 Nov 2004, Jacob Meuser wrote: > > > >curious also what's in ../utils/libopenhpiutils.la > > > >probably > > > >installed=yes > > > >and > > > >libdir='/home/sdague/openhpi/openhpi-1.9.3/_inst/lib' > > > >but > > > >/home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so > >doesn't yet exist? > > If this is the case then this means that the lib_LTLIBRARIES > specification is ordered incorrectly in Makefile.am. Unfortunately, > Automake does not yet have a way to ensure that libraries are > installed in the correct order. It becomes the developer's > responsibility to ensure that lib_LTLIBRARIES is in the ideal order. ... AM_CFLAGS = @CFLAGS@ lib_LTLIBRARIES = libopenhpi.la libopenhpi_la_SOURCES = \ ... There is only one library being built in this directory, so there can't be an ordering issue here. The other library is built in a different directory which is listed well before in the SUBDIR order. To be extra safe I even added: $(top_builddir)/utils/libopenhpiutils.la: make -C $(top_builddir)/utils libopenhpiutils.la to the Makefile.am -Sean -- __ Sean Dague Mid-Hudson Valley sean at dague dot netLinux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __ pgpOojSMJVuCl.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
On Wed, 17 Nov 2004, Sean Dague wrote: /home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so doesn't yet exist? If this is the case then this means that the lib_LTLIBRARIES specification is ordered incorrectly in Makefile.am. Unfortunately, Automake does not yet have a way to ensure that libraries are installed in the correct order. It becomes the developer's responsibility to ensure that lib_LTLIBRARIES is in the ideal order. ... AM_CFLAGS = @CFLAGS@ lib_LTLIBRARIES = libopenhpi.la libopenhpi_la_SOURCES = \ ... There is only one library being built in this directory, so there can't be an ordering issue here. The other library is built in a different directory which is listed well before in the SUBDIR order. To be extra safe I even added: If the library fails to be found, that must mean that the Makefile in the other directory failed to install the library at the right time, or into the right location. There is also the possibility that a necessary -L option is missing so libtool fails to find the library in the installation directory. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.6 still not supporting make distcheck
* Sean Dague wrote on Wed, Nov 17, 2004 at 06:07:55PM CET:
> On Tue, Nov 16, 2004 at 06:32:51PM -0800, Jacob Meuser wrote:
>
>
> > /home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpiutils.so
> > doesn't yet exist?
>
> Nothing exists in _inst except directories, as this phase of make distcheck
> is happening after it has done make uninstall on the _inst directory.
Thanks for this hint. I know now what the problem is.
One of the bugs that will hit on cross-compile. Just need to find out
where the buggy code is:
What I overlooked until now: The error occurs only in the DESTDIR
install, not in the regular one. The failure is here (last few lines of
the log Sean made available online):
/bin/sh ../libtool --mode=install /usr/bin/install -c libopenhpi.la
/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib/libopenhpi.la
libtool: install: warning: relinking `libopenhpi.la'
(cd /home/sdague/openhpi/openhpi-1.9.3/_build/src; /bin/sh ../libtool
--mode=relink gcc -g -O2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wpointer-arith -Wformat=2 -Wformat-security
-Wformat-nonliteral -Wno-format-y2k -Wcast-qual -Wcast-align -Werror
-D_GNU_SOURCE -D_REENTRANT -fexceptions -g -O2 -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -Wall -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes -Wpointer-arith -Wformat=2 -Wformat-security
-Wformat-nonliteral -Wno-format-y2k -Wcast-qual -Wcast-align -Werror
-D_GNU_SOURCE -D_REENTRANT -fexceptions -o libopenhpi.la -rpath
/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L../utils -version-info 10:3:9
-export-symbols ../../src/hpi.sym config.lo domain.lo event.lo alarm.lo
hotswap.lo lock.lo plugin.lo plugin_static.lo init.lo safhpi.lo session.lo
oHpi.lo ../utils/libopenhpiutils.la -lltdl -pthread -lgthread-2.0 -lglib-2.0
-lm -lpthread -inst-prefix-dir /home/sdague/tmp/am-dc-28498/)
echo "{ global:" > .libs/libopenhpi.ver
cat ../../src/hpi.sym | sed -e "s/\(.*\)/\1;/" >> .libs/libopenhpi.ver
echo "local: *; };" >> .libs/libopenhpi.ver
gcc -shared .libs/config.o .libs/domain.o .libs/event.o .libs/alarm.o
.libs/hotswap.o .libs/lock.o .libs/plugin.o .libs/plugin_static.o .libs/init.o
.libs/safhpi.o .libs/session.o .libs/oHpi.o
-L/home/sdague/tmp/am-dc-28498//usr/lib -Wl,--rpath
-Wl,/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -L/usr/lib
-L/home/sdague/openhpi/openhpi-1.9.3/_build/utils
-L/home/sdague/openhpi/openhpi-1.9.3/_inst/lib -lopenhpiutils -lltdl -pthread
-lgthread-2.0 -lglib-2.0 -lm -lpthread -Wl,-soname -Wl,libopenhpi.so.1
-Wl,-version-script -Wl,.libs/libopenhpi.ver -o .libs/libopenhpi.so.1.9.3
/usr/bin/ld: cannot find -lopenhpiutils
collect2: ld returned 1 exit status
libtool: install: error: relink `libopenhpi.la' with the above command before
installing it
The line starting with
| gcc -shared
contains
| -L/home/sdague/openhpi/openhpi-1.9.3/_inst/lib
which is wrong. It should contain
| -L/home/sdague/tmp/am-dc-28498//home/sdague/openhpi/openhpi-1.9.3/_inst/lib
Who finds the culprit?
Ralf
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Re: Patch for Portland compiler support
Actually, before I attempt the LT 2.x patch, how does this look for the
1.5 patch? I checked pgcc, pgCC, pgf77, and pgf90, both in the 1.5
test suite (I assuming that configuring LT with CC=pgcc [etc.] and then
"make check" is what is necessary?) and with a small sample automake
package that I made explicitly for testing porpoises. All seems to be
working properly.
Could someone who is Wise in the Ways of Libtool tell me if this patch
looks ok? 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.
I'm also CC'ing the PG support team to see if they have any input.
Here's the revised patch (including some fixes from this morning; based
on tests, not the PG documentation ;-) ):
-
[9:20] hbar:~/libtool-1.5 % 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 17:24:39 -
@@ -3165,6 +3165,15 @@
_LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)='${wl}--export-dynamic'
_LT_AC_TAGVAR(whole_archive_flag_spec,
$1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
;;
+ pgCC)
+# Portland Group C++ compiler (*not* the Pentium gcc compiler,
+ # which looks to be a dead project)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
${wl}$soname -o $lib'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags
${wl}-soname ${wl}$soname ${wl}-retain-symbols-file
${wl}$export_symbols -o $lib'
+
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath
${wl}$libdir'
+ _LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)='${wl}--export-dynamic'
+;;
cxx)
# Compaq C++
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname -o $lib'
@@ -4713,6 +4722,13 @@
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
+ pgCC)
+ # Portland Group C++ compiler (*not* the Pentium gcc
+# compiler, which looks to be a dead project)
+ _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)='-static'
+ ;;
cxx)
# Compaq C++
# Make sure the PIC flag is empty. It appears that all
Alpha
@@ -4952,6 +4968,13 @@
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
+ pgcc | pgf77 | pgf90)
+# Portland Group compilers (*not* the Pentium gcc compiler,
+ # which looks to be a dead project)
+ _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)='-static'
+;;
ccc*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
# All Alpha code is PIC.
@@ -5228,6 +5251,10 @@
linux*)
if $LD --help 2>&1 | grep ': supported targets:.* elf' >
/dev/null; then
tmp_archive_cmds='$CC -shared $libobjs $deplibs
$compiler_flags ${wl}-soname $wl$soname -o $lib'
+ # Portland Group f77 and f90 compilers require an additonal
-fpic
+ if test "$CC" = "pgf77" -o "$CC" = "pgf90"; then
+ tmp_archive_cmds="$tmp_archive_cmds -fpic"
+fi
_LT_AC_TAGVAR(archive_cmds, $1)="$tmp_archive_cmds"
supports_anon_versioning=no
case `$LD -v 2>/dev/null` in
-
Any comments would be appreciated. Thanks!
On Nov 17, 2004, at 9:38 AM, Ralf Wildenhues wrote:
> [snipped]
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).
> [snipped]
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Application is pre approved
Dear Sir or Madam, Would you REFINANCE if you knew you'd SAVE TH0USANDS? We'll get you lnterest as low as 1.92%. Don't believe me? Fill out our small online questionaire and we'll show you how. Get the house/home and/or car you always wanted, it only takes 10 seconds of your time: http://www.your-financial.com/ Best Regards, Andrew Banks No thanks: http://www.your-financial.com/r1/ ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
On Wed, Nov 17, 2004 at 08:58:35AM +0100, Ralf Wildenhues wrote: > * Jacob Meuser wrote on Wed, Nov 17, 2004 at 01:07:20AM CET: > > On Tue, Nov 16, 2004 at 11:00:34PM +, Scott James Remnant wrote: > > > On Tue, 2004-11-16 at 11:15 -0800, Jacob Meuser wrote: > > > > On Tue, Nov 16, 2004 at 03:02:55PM +, Scott James Remnant wrote: > > > > > Actually, I'd say the opposite is true ... the LONGER link line, > > > > > produced by the current Libtool, is what allows people to get away > > > > > with > > > > > this because Libtool puts more stuff into the link line. > > > > > > > > > > A shorter, more concise, link line actually forces people to make sure > > > > > they *do* link anything they require themselves, rather than relying > > > > > on > > > > > Libtool to do the right thing for them. > > > > > > > > but where does the problem show up? on !Linux, because Linux will > > > > "do the right thing". > > > > > > > No, on Linux ... because Linux does the right thing and causes the > > > applications to break; whereas Libtool does the wrong thing and links > > > the application directly with half the libraries on the system. > > > > from my understanding, correct me if I'm wrong, > > Can you also be bothered to read > [EMAIL PROTECTED] again? > For archive users, that is message > http://lists.gnu.org/archive/html/libtool/2004-11/msg00319.html I think understand the problem there. deplibs that shouldn't be specified are picked up from .la files. > > on Linux, to the linker, all library deplibs do not need to be > > specified > > ACK. > > > on other systems, to the linker, all library deplibs do need to be > > specified. > > On some other systems. yes, of course, not all other systems. > > libtool is to handle this transparently, just specify the library, > > and, if needed, libtool will add the deplibs. > > That's what libtool does for every system right now, not only if needed. yes, I understand that. > Scotts keybuk-linux-deplibs.patch would change this behavior on linux. yes, I understand that. > > am I right so far? > > I think so. > > > so when libtool fails to complete the deplibs (I still haven't seen > > any explanation for what happens when one of the deplibs is a > > non-libtool library), where is there breakage? not on Linux, because > > it doesn't need the deplibs anyway. > > No breakage. Developer education: "There exist other systems with > linkers that need dependencies explicitly specified." right, but, as Bob pointed out, there is a new generation of coders who only use Linux. why would they care about other systems? how would they know what does need to be explicitly specified, and what shouldn't be specified? what happens when a deplib that has other deplibs is not a libtool library? for example, on BSD systems, the base libraries are not built with libtool, but on Linux distros, a good part of the base libraries are built with libtool. > This education method is not foolproof, however, thus the proposed > change. the change to not have libtool not expand deplibs on Linux is not what I'm arguing about. telling people to not specify deplibs is the problem. it wouldn't be a problem if all libraries on a system were built with libtool, but that is not the case, especially on !Linux. > > how would linux cause the application to break if there was a deplib > > explicitly specified? > > Read the message above. wouldn't that be a problem on any system? since the proposed change only affects systems that don't need deplibs specified, doesn't the same problem remain on systems that do need proper deplibs specified, since libtool will continue to do what it has always done? so, if this fixes a libtool issue on systems that the libtool developers use, what is the motivation to fix the exact same issue for other systems? is this bug deep in libtool left for users of systems that don't have linker dependency resolution to figure out? > Regards, > Ralf -- <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
ltdl system search path hardcoded at build
Libtool 1.5.10's ltdl.m4 includes the code:
AC_DEFINE_UNQUOTED(LTDL_SYSSEARCHPATH, "$sys_search_path",
[Define to the system default library search path.])
This causes the macro LTDL_SYSSEARCHPATH to hold the value of what was
originally sys_lib_dlsearch_path_spec in libtool.m4.
sys_lib_dlsearch_path_spec is set to "/lib /usr/lib" by default and is
modified by some environment-specific checks. For Linux ELF,
sys_lib_dlsearch_path_spec is reset to "/lib /usr/lib" plus the contents of
/etc/ld.so.conf (see the "libtool-1.5.10.ldsoinclude.patch" thread on
libtool-patches).
The macro LTDL_SYSSEARCHPATH, set based on the contents of /etc/ld.so.conf
at build time, is used by ltdl's try_dlopen routine as a path in which to
search for unpathed files.
Without libtool-1.5.10.ldsoinclude.patch, on systems that use recent glibc's
"include X" form, lt_dlopenext("test") would cause the application to
attempt to
open("/lib/libtest.la")
open("/usr/lib/libtest.la")
open("include/libtest.la")
open("ld.so.conf.d/*.co/libtest.la")
open("/usr/X11R6/lib/libtest.la")
and so on.
However (and unrelated to the ldsoinclude problem), in environments where
the build system is not the same as the host system, as in situations where
a library or executable may be built on a single-purpose mass build system
and then used on many heterogeneous systems, the contents of /etc/ld.so.conf
at build time may not exactly match the contents at run time. In situations
where build=host but a library or executable is built and then
/etc/ld.so.conf is changed (by the installation or removal of another
package, or by manual intervention), the contents at build time again do not
match the contents at run time.
My understanding is that the $sys_lib_dlsearch_path_spec variable is used
for two main purposes: Culling the list of -rpaths to embed in a target; and
seeding the search path used by ltdl.
For the former case, $sys_lib_dlsearch_path_spec must be a subset of the
paths used by ld.so to find libraries. That is, culling a library from the
explicit -rpath list would cause the build to succeed but the running to
fail. (sys_lib_dlsearch_path_spec is used to list the libraries *not* to
explicitly search because the system will search them for us.)
For the latter case, $sys_lib_dlsearch_path_spec must be a supserset of the
paths used by dlopen() to find modules. (sys_lib_dlsearch_path_spec is used
to list the libraries *to* explicitly search because we want to mimick the
system's behavior in finding .so files to find .la files.)
On Linux, at least, it is my understanding that the paths used by ld.so to
find libraries and the paths used by dlopen() to find modules are the same;
hence $sys_lib_dlsearch_path_spec must be a subset and a superset of this
list. The only set that is both a subset and a superset of an original set
is the original set itself; hence $sys_lib_dlsearch_path_spec must be
exactly the correct set in every situation.
1) It may be useful to add a command-line argument to libtoolized
./configure scripts to list an override value for sys_lib_dlsearch_path_spec
for one or both of its uses.
2) My understanding is that there is no plan to introduce a command line
argument to ldconfig to extract the library search path as ld.so will see
it. However, it may be useful to request this if it is deemed necessary. In
addition to a command line argument to ldconfig, it might be useful to
request an accessible glibc function to return the search path at run time
for ltdl's use.
3) Parsing /etc/ld.so.conf within Libtool may be discouraged because the
format of /etc/ld.so.conf is not fixed, and the format is keyed off of the
version of glibc installed. The libtool-1.5.10.ldsoinclude.patch patch does
not exactly mimick glibc-current's ld.so.conf-parsing behavior; it simply
adds enough functionality to Libtool's ld.so.conf parser to work in the
[currently] common case.
It may be useful to change the behavior so that sys_lib_dlsearch_path_spec
reverts to only being "/lib /usr/lib", even on Linux ELF. We would have to
live with "unnecessary" -rpath linkings and the stipulation that lt_dlopen()
users must give an explicit search path during their initialization for
anything not in /lib or /usr/lib (even if it's in /etc/ld.so.conf and even
if dlopen("module.so") works while lt_dlopen("module.la") does not). This
could be more acceptable if one or both of the other options are also
adopted.
(This started as a bug report but it seems more like an RFC now.)
--
Daniel Reed <[EMAIL PROTECTED]> http://people.redhat.com/djr/
http://naim.n.ml.org/
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man. -- George Bernard Shaw
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
