libtool and FreeBSD.
libtool 1.5.22 fails to link a simple threaded executable under FreeBSD. -pthread is a compiler directive not a library. Note also the FreeBSD porters handbook explicitly recommends against linking in -lpthread or -lc_r directly. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-pthread.html Note: specifying -lpthread on the command line will also allow the linking to complete but should not be required. This change supports specifying both -pthread and -lpthread. Mark Without patch: /bin/sh /home/marka/cvs/bind9-xx/libtool --mode=compile gcc -pthread -I/home/marka/cvs/bind9-xx -I/home/marka/cvs/bind9-xx/lib/dns/include -I../../lib/dns/include -I/home/marka/cvs/bind9-xx/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -I/home/marka/cvs/bind9-xx/lib/isccfg/include -I../../lib/isccfg/include -I/home/marka/cvs/bind9-xx/lib/lwres/include -I../../lib/lwres/unix/include -I../../lib/lwres/include-D_REENTRANT -D_THREAD_SAFE -g -O2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c genrandom.c gcc -pthread -I/home/marka/cvs/bind9-xx -I/home/marka/cvs/bind9-xx/lib/dns/include -I../../lib/dns/include -I/home/marka/cvs/bind9-xx/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -I/home/marka/cvs/bind9-xx/lib/isccfg/include -I../../lib/isccfg/include -I/home/marka/cvs/bind9-xx/lib/lwres/include -I../../lib/lwres/unix/include -I../../lib/lwres/include -D_REENTRANT -D_THREAD_SAFE -g -O2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c genrandom.c -fPIC -DPIC -o .libs/genrandom.o gcc -pthread -I/home/marka/cvs/bind9-xx -I/home/marka/cvs/bind9-xx/lib/dns/include -I../../lib/dns/include -I/home/marka/cvs/bind9-xx/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -I/home/marka/cvs/bind9-xx/lib/isccfg/include -I../../lib/isccfg/include -I/home/marka/cvs/bind9-xx/lib/lwres/include -I../../lib/lwres/unix/include -I../../lib/lwres/include -D_REENTRANT -D_THREAD_SAFE -g -O2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c genrandom.c -o genrandom.o >/dev/null 2>&1 /bin/sh /home/marka/cvs/bind9-xx/libtool --mode=link gcc -pthread -g -O2 -o genrandom genrandom.lo rm -f .libs/genrandom.nm .libs/genrandom.nmS .libs/genrandom.nmT creating .libs/genrandomS.c extracting global C symbols from `.libs/genrandom.o' (cd .libs && gcc -pthread -c -fno-builtin "genrandomS.c") rm -f .libs/genrandomS.c .libs/genrandom.nm .libs/genrandom.nmS .libs/genrandom.nmT gcc -g -O2 -o genrandom .libs/genrandom.o .libs/genrandom.o .libs/genrandom.o(.text+0x0): In function `main': /home/marka/cvs/bind9-xx/bin/tests/genrandom.c:29: multiple definition of `main' .libs/genrandom.o(.text+0x0):/home/marka/cvs/bind9-xx/bin/tests/genrandom.c:29: first defined here rm -f .libs/genrandomS.o *** Error code 1 With patch: /bin/sh /home/marka/cvs/bind9-xx/libtool --mode=compile gcc -pthread -I/home/marka/cvs/bind9-xx -I/home/marka/cvs/bind9-xx/lib/dns/include -I../../lib/dns/include -I/home/marka/cvs/bind9-xx/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -I/home/marka/cvs/bind9-xx/lib/isccfg/include -I../../lib/isccfg/include -I/home/marka/cvs/bind9-xx/lib/lwres/include -I../../lib/lwres/unix/include -I../../lib/lwres/include-D_REENTRANT -D_THREAD_SAFE -g -O2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c genrandom.c gcc -pthread -I/home/marka/cvs/bind9-xx -I/home/marka/cvs/bind9-xx/lib/dns/include -I../../lib/dns/include -I/home/marka/cvs/bind9-xx/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -I/home/marka/cvs/bind9-xx/lib/isccfg/include -I../../lib/isccfg/include -I/home/marka/cvs/bind9-xx/lib/lwres/include -I../../lib/lwres/unix/include -I../../lib/lwres/include -D_REENTRANT -D_THREAD_SAFE -g -O2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c genrandom.c -fPIC -DPIC -o .libs/genrandom.o gcc -pthread -I/home/marka/cvs/bind9-xx -I/home/marka/cvs/bind9-xx/lib/dns/include -I../../lib/dns/include -I/home/marka/cvs/bind9-xx/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -I/home/marka/cvs/bind9-xx/lib/is
Re: Cygwin failure with large number of sources
Hello Christopher, Thanks for the bug report. * Christopher Hulbert wrote on Wed, Jun 14, 2006 at 03:49:06PM CEST: > I don't think this is a libtool bug, but I thought I would not this. We have planned to use response files on w32 at one point, FWIW. > I was compiling a library with 1635 object files into a static > archive. The cygwin command shell fails with: What's the command? `ar cru ...'? How long exactly is the command line, and why did the command line length limit max_cmd_len=8192 setting not trigger a multiple archiver invocation? All these questions may be answered by the output of ./libtool --debug [rest of command line] >log 2>&1 and sending the log file (please bzip2 or gzip). Erm, please also tell us the size of your environment (`env | wc'); I don't remember off-hand whether that was part of the limit on Cygwin. > 5 [main] sh 3668 C:\cygwin\bin\sh.exe: *** fatal error - fork: > can't reserve memory for stack 0x23E660 - 0x24, Win32 error 487 > 6 [main] sh 2896 child_copy: stack write copy failed, > 0x23E660..0x24, done 0, windows pid 2352532, Win32 error 5 > ../libtool: fork: No error > make: *** [libvsip.la] Error 129 Hmm. Is that a typical command line limitation error even? Maybe your system just ran out of virtual memory? (I don't know Cygwin that well off-hand.) > This seems to be correlated with so many object files. I remember > seeing libtool at one point somewhere else trying to do partial > linking. Would there be a way to do something similar when there are > so many object files? Yes, and all that machinery should be in place. > Currently After it fails I just manually go > into the directory and run ar cru .libs/libvsip.a *.o and it seems to > work fine. This is really weird. Is this a recent Cygwin? Which w32 system on? Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [ISC-Bugs #16157]
Hello Bruce,
* [EMAIL PROTECTED] wrote on Wed, Jun 14, 2006 at 05:44:31PM CEST:
> Forwarded message:
> | From: "Mark Andrews via RT" <[EMAIL PROTECTED]>
> | Reply-To: [EMAIL PROTECTED]
> | It looks like printf is still in use in libtool-1.5.22.
> | That being said. libtool is making use of printf to add
> | newlines so just changing to $echo won't work.
>
> This is to report the fact that "printf" command is
> neither a shell builtin nor a user command in SunOS 4.1.x
> (& I suspect other similar OS's as well)
>
> config.guess: "sparc-sun-sunos4.1.4"
> config.guess: "m68k-sun-sunos4.1.1"
Wow. Thanks for this bug report. But before I apply the suggested
patch below, I'd like a reality check first. SunOS 4.1.4 was released
1994 according to the Unix timeline. According to [1], the end of
service life date of Solaris 1.1.2 has been three years ago, that of
4.1.1 six years ago.
Does anybody actually use these systems outside of a museum? Does a
recent Autoconf produce usable configure scripts for these hosts?
Cheers,
Ralf
[1] http://www.sun.com/service/eosl/solaris/solaris_vintage_eol_5.2005.html
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.109.2.47
diff -u -r1.109.2.47 NEWS
--- NEWS15 May 2006 16:41:00 - 1.109.2.47
+++ NEWS14 Jun 2006 17:10:24 -
@@ -12,6 +12,7 @@
* Fix error with -version-info on systems with version_type=none, such
as BeOS.
* Initial support for the Sun compiler suite on GNU/Linux.
+* Drop use of shell printf for SunOS 4.1.
* Bug Fixes.
New in 1.5.22: 2005-12-18; CVS version 1.5.21a, Libtool team:
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.158
diff -u -r1.314.2.158 libtool.m4
--- libtool.m4 12 Jun 2006 05:25:26 - 1.314.2.158
+++ libtool.m4 14 Jun 2006 17:10:26 -
@@ -258,7 +258,7 @@
# the simple compiler test code.
AC_DEFUN([_LT_COMPILER_BOILERPLATE],
[ac_outfile=conftest.$ac_objext
-printf "$lt_simple_compile_test_code" >conftest.$ac_ext
+echo "$lt_simple_compile_test_code" >conftest.$ac_ext
eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_compiler_boilerplate=`cat conftest.err`
$rm conftest*
@@ -271,7 +271,7 @@
# the simple link test code.
AC_DEFUN([_LT_LINKER_BOILERPLATE],
[ac_outfile=conftest.$ac_objext
-printf "$lt_simple_link_test_code" >conftest.$ac_ext
+echo "$lt_simple_link_test_code" >conftest.$ac_ext
eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_linker_boilerplate=`cat conftest.err`
$rm conftest*
@@ -624,7 +624,7 @@
AC_CACHE_CHECK([$1], [$2],
[$2=no
ifelse([$4], , [ac_outfile=conftest.$ac_objext], [ac_outfile=$4])
- printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+ echo "$lt_simple_compile_test_code" > conftest.$ac_ext
lt_compiler_flag="$3"
# Insert the option either (1) after the last *FLAGS variable, or
# (2) before a word containing "conftest.", or (3) at the end.
@@ -669,7 +669,7 @@
[$2=no
save_LDFLAGS="$LDFLAGS"
LDFLAGS="$LDFLAGS $3"
- printf "$lt_simple_link_test_code" > conftest.$ac_ext
+ echo "$lt_simple_link_test_code" > conftest.$ac_ext
if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
# The linker can only warn and ignore the option if not recognized
# So say no if there are warnings
@@ -1035,7 +1035,7 @@
mkdir conftest
cd conftest
mkdir out
- printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+ echo "$lt_simple_compile_test_code" > conftest.$ac_ext
lt_compiler_flag="-o out/conftest2.$ac_objext"
# Insert the option either (1) after the last *FLAGS variable, or
@@ -2675,10 +2675,10 @@
_LT_AC_TAGVAR(objext, $1)=$objext
# Code to be used in simple compile tests
-lt_simple_compile_test_code="int some_variable = 0;\n"
+lt_simple_compile_test_code="int some_variable = 0;"
# Code to be used in simple link tests
-lt_simple_link_test_code='int main(){return(0);}\n'
+lt_simple_link_test_code='int main(){return(0);}'
_LT_AC_SYS_COMPILER
@@ -2784,10 +2784,10 @@
_LT_AC_TAGVAR(objext, $1)=$objext
# Code to be used in simple compile tests
-lt_simple_compile_test_code="int some_variable = 0;\n"
+lt_simple_compile_test_code="int some_variable = 0;"
# Code to be used in simple link tests
-lt_simple_link_test_code='int main(int, char *[[]]) { return(0); }\n'
+lt_simple_link_test_code='int main(int, char *[[]]) { return(0); }'
# ltmain only uses $CC for tagged configurations so make sure $CC is set.
_LT_AC_SYS_COMPILER
@@ -3973,10 +3973,17 @@
_LT_AC_TAGVAR(objext, $1)=$objext
# Code to be used in simple compile tests
-lt_simple_compile_test_code=" subroutine t\n return\n end\n"
+lt_simple_compile_test_code="\
+ subroutine t
+ return
Re: Feature request: setting env vars for binary wrappers
Hi Gary, * Gary V. Vaughan wrote on Wed, Jun 14, 2006 at 01:11:45PM CEST: > Ralf Wildenhues wrote: > > [ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319 > > or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ] > > What do you think? OK for HEAD right now, or do you think this is too > > intrusive now? > > I have no problem with the principle, but as the patch stands there are > idiosyncracies that need ironing out before it is complete. Care to list them, so this can be fixed? Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Cygwin failure with large number of sources
* Christopher Hulbert wrote on Wed, Jun 14, 2006 at 04:37:50PM CEST: > On 6/14/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > >setting not trigger a multiple archiver invocation? > >All these questions may be answered by the output of > > ./libtool --debug [rest of command line] >log 2>&1 > That won't work. It's crashing I guess trying to call libtool with > all those arguments. Ah, there is a fix for this: Create a file with all objects listed in it. Use it as argument to the libtool option -objectlist. If you want to create the file from a Makefile, and have all the object names in a variable, you could do echo $(ALLOBJECTS) | tr ' ' '\n' > libfoo.objectlist but it could possibly fail as well (the shell command being too long, too), leaving you with the need to resort to some other means to create the list, possibly by using make variables which contain only subsets of object names which are short enough for the command line. If that still fails, but now inside libtool, post as decribed above. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Bug in documentation about how to update -version-info?
Looking at the documentation about how to update -version-info: 1. Start with version information of `0:0:0' for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). 4. If any interfaces have been added, removed, or changed since the last update, increment CURRENT, and set REVISION to 0. 5. If any interfaces have been added since the last public release, then increment AGE. 6. If any interfaces have been removed since the last public release, then set AGE to 0. I think there is a potentially misleading issue with the above: If an interface is *changed* that is essentially the same as removing the old interface and adding a new one which just happens to have the same name - therefore, I think point 6 should say "removed or changed", not just "removed". Whilst this documentation is being looked at, a secondary point: The terms "last update" and "last public release" are used interchangeably - I think it would be clearer to use "last public release" exclusively (i.e. in points 3 and 4, change "last update" to "last public release"). Max. signature.asc Description: OpenPGP digital signature ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [ISC-Bugs #16157]
Forwarded message: | From: "Mark Andrews via RT" <[EMAIL PROTECTED]> | Reply-To: [EMAIL PROTECTED] | In-Reply-To: Your message of "Wed, 14 Jun 2006 04:32:41 GMT." <[EMAIL PROTECTED]> | | > why don't i just fix "libtool.m4" ? (& make the Gnu | > libtool ppl aware of the issue?) | | It looks like printf is still in use in libtool-1.5.22. | That being said. libtool is making use of printf to add | newlines so just changing to $echo won't work. This is to report the fact that "printf" command is neither a shell builtin nor a user command in SunOS 4.1.x (& I suspect other similar OS's as well) config.guess: "sparc-sun-sunos4.1.4" config.guess: "m68k-sun-sunos4.1.1" Thanks, Bruce Becker+1 416 410 0879 GTS Network Administration Toronto, Ont. Email: [EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Cygwin failure with large number of sources
On 6/14/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: * Christopher Hulbert wrote on Wed, Jun 14, 2006 at 04:37:50PM CEST: > On 6/14/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > >setting not trigger a multiple archiver invocation? > >All these questions may be answered by the output of > > ./libtool --debug [rest of command line] >log 2>&1 > That won't work. It's crashing I guess trying to call libtool with > all those arguments. Ah, there is a fix for this: Create a file with all objects listed in it. Use it as argument to the libtool option -objectlist. If you want to create the file from a Makefile, and have all the object names in a variable, you could do echo $(ALLOBJECTS) | tr ' ' '\n' > libfoo.objectlist but it could possibly fail as well (the shell command being too long, too), leaving you with the need to resort to some other means to create the list, possibly by using make variables which contain only subsets of object names which are short enough for the command line. If that still fails, but now inside libtool, post as decribed above. Cheers, Ralf Well, this library wont add/rm source files too often, so I'll create the file statically and just add the -objlist flag to the AM_LDFLAGS variable? As a side, I posted to the libtool mailing list about some more PGI conflicts I'm having. It's not necessarily a libtool bug since it assumes msvc support if not using the gcc compiler. It seems to work if I manually set the with_gcc=yes in the libtool script. Can I pass that on the AM_LDFLAGS variable? ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Cygwin failure with large number of sources
On 6/14/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: Hello Christopher, Thanks for the bug report. * Christopher Hulbert wrote on Wed, Jun 14, 2006 at 03:49:06PM CEST: > I don't think this is a libtool bug, but I thought I would not this. We have planned to use response files on w32 at one point, FWIW. > I was compiling a library with 1635 object files into a static > archive. The cygwin command shell fails with: What's the command? `ar cru ...'? How long exactly is the command line, and why did the command line length limit max_cmd_len=8192 /bin/sh ../libtool --tag=CC --mode=link pgcc -I../../../src/vsipl/include - ./../src/vsipl/include/privateC -O0 -Wall -g --exceptions -m32 -Minfor orm -Minfo=all -c9x -D__STDC_VERSION__=199901L -o libvsip.la -rpath C:/cy home/chulbert/ISLtools_v1.2/i686-pc-cygwin-gnu/lib vsip_arg_d.lo [1630+ more .lo files] -lm -lmingwex 5 [main] sh 1644 C:\cygwin\bin\sh.exe: *** fatal error - fork: can't ve memory for stack 0x23E660 - 0x24, Win32 error 487 7 [main] sh 3092 child_copy: stack write copy failed, 0x23E660..0x240 done 0, windows pid 2352532, Win32 error 5 ../libtool: fork: No error make[1]: *** [libvsip.la] Error 129 make[1]: Leaving directory `/cygdrive/c/cygwin/home/chulbert/ISLdevel/build in/vsipl/src' make: *** [all-recursive] Error 1 setting not trigger a multiple archiver invocation? All these questions may be answered by the output of ./libtool --debug [rest of command line] >log 2>&1 That won't work. It's crashing I guess trying to call libtool with all those arguments. and sending the log file (please bzip2 or gzip). Erm, please also tell us the size of your environment (`env | wc'); I don't remember off-hand whether that was part of the limit on Cygwin. bash-3.1$ env | wc 66 1204382 > 5 [main] sh 3668 C:\cygwin\bin\sh.exe: *** fatal error - fork: > can't reserve memory for stack 0x23E660 - 0x24, Win32 error 487 > 6 [main] sh 2896 child_copy: stack write copy failed, > 0x23E660..0x24, done 0, windows pid 2352532, Win32 error 5 > ../libtool: fork: No error > make: *** [libvsip.la] Error 129 Hmm. Is that a typical command line limitation error even? Maybe your system just ran out of virtual memory? (I don't know Cygwin that well off-hand.) It's possible. I've searched through the cygwin archives, but nothing that really works. I've seen this error a few places in the archive. This likely belongs as a bug report against cygwin, I just haven't made it there yet. The gmane news seems to be down. > This seems to be correlated with so many object files. I remember > seeing libtool at one point somewhere else trying to do partial > linking. Would there be a way to do something similar when there are > so many object files? Yes, and all that machinery should be in place. Yeah, I don't know that libtool can avoid this without again keeping all those in a file and avoiding the command line > Currently After it fails I just manually go > into the directory and run ar cru .libs/libvsip.a *.o and it seems to > work fine. This is really weird. Is this a recent Cygwin? Which w32 system on? Somewhat recent. I try not to do too many updgrades. The origin of this was actually on my home PC with a fresh (i.e. recent) cygwin install, but I though it may be due to an old Athlon XP 3000+ with 1.5Gb of RAM. So I deceided to wait and try the work PC Pentium 4 3.2Ghz but only 1 Gb of ram. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Cygwin failure with large number of sources
I don't think this is a libtool bug, but I thought I would not this. I was compiling a library with 1635 object files into a static archive. The cygwin command shell fails with: 5 [main] sh 3668 C:\cygwin\bin\sh.exe: *** fatal error - fork: can't reserve memory for stack 0x23E660 - 0x24, Win32 error 487 6 [main] sh 2896 child_copy: stack write copy failed, 0x23E660..0x24, done 0, windows pid 2352532, Win32 error 5 ../libtool: fork: No error make: *** [libvsip.la] Error 129 This seems to be correlated with so many object files. I remember seeing libtool at one point somewhere else trying to do partial linking. Would there be a way to do something similar when there are so many object files? Currently After it fails I just manually go into the directory and run ar cru .libs/libvsip.a *.o and it seems to work fine. libtool --version ltmain.sh (GNU libtool 1.2309 2006/06/12 17:54:15) 2.1a Written by Gordon Matzigkeit <[EMAIL PROTECTED]>, 1996 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Feature request: setting env vars for binary wrappers
Hallo Ralf, Ralf Wildenhues wrote: > [ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319 > or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ] [[snip]] > What do you think? OK for HEAD right now, or do you think this is too > intrusive now? I have no problem with the principle, but as the patch stands there are idiosyncracies that need ironing out before it is complete. Besides, HEAD is in feature freeze stabilization mode for the ever impending 2.0 release: The patch should wait until after the release. > I think we should not backport this to 1.5.x, it is a new feature. Agreed. > Implement setting environment variables and additional arguments > for shell wrappers to uninstalled programs. Using this forces > all uninstalled programs to have wrappers. > > * libltdl/config/ltmain.m4sh (func_mode_link, shell wrapper): > New variables `wrapper_env', `wrapper_args' for the new link flags > `-wrapper-arg', `-wrapper-env'. Cause a shell wrapper to always > be created for uninstalled programs, put the wrapper_env > variables in the environment before executing the real program, > and add the wrapper_args as its first arguments; both with > suitable quoting for active characters. > (link mode help): Add the new flags. > * doc/libtool.texi (Link mode): Document the new flags. Note > the override of `-no-install'. > (Linking executables): Add cross reference to the wrapper script > discussion. > * tests/wrapper.at: New test. > * NEWS, THANKS, Makefile.am: Update. > Suggested by Behdad Esfahbod. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://blog.azazil.net GNU Hacker / )= http://trac.azazil.net/projects/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
