libtool ChangeLog HACKING
CVSROOT:/cvsroot/libtool Module name:libtool Branch: Changes by: Ralf Wildenhues [EMAIL PROTECTED] 05/09/26 12:21:53 Modified files: . : ChangeLog HACKING Log message: * HACKING: Only update libltdl version info before release. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/ChangeLog.diff?tr1=1.2094tr2=1.2095r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/HACKING.diff?tr1=1.20tr2=1.21r1=textr2=text ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog configure.ac
CVSROOT:/cvsroot/libtool Module name:libtool Branch: Changes by: Ralf Wildenhues [EMAIL PROTECTED] 05/09/26 12:04:47 Modified files: . : ChangeLog configure.ac Log message: * configure.ac AUTOM4TE: Allow variable override. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/ChangeLog.diff?tr1=1.2093tr2=1.2094r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/configure.ac.diff?tr1=1.72tr2=1.73r1=textr2=text ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
Re: release policy
Oldish thread.. * Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:30:32AM CEST: Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Sat, Sep 17, 2005 at 10:35:32PM CEST: Charles Wilson wrote: Huh? Right now (on cygwin) the shared library built by 1.5.x libtool is cygltdl-3.dll (e.g. current - age == 3). Somebody somewhere already bumped the c:r:a numbers in HEAD because libtool-HEAD on cygwin creates cygltdl-6.dll. So which previous **releases** of libltdl are you trying to distinguish from, here, Ralf? My thoughts too at first, but checking 1.9f current was already 6, and this is an incompatible change with 1.9f. First this, and besides I was referring to this policy in HACKING: | * Double check that libltdl version number updates weren't forgotten | since last release (they should be updated in CVS along with commits | that require it so that users can work with CVS snapshots). which, I believe, stems from the fact that somebody needed post-1.5 stuff but with 2.0 not in sight. Hmmm... good catch, I hadn't spotted that, but... So while we are at it, it might be a good idea to remove the parenthesized part.. Yes, I agree. It seems wrong to churn the numbers so fast. I don't think it is too much to expect people who track CVS to have to deal with regressions and experimental apis that later get fixed to restore backwards compatibility. Can you fix that please? Applied this patch to CVS HEAD. Cheers, Ralf * HACKING: Only update libltdl version info before release. Index: HACKING === RCS file: /cvsroot/libtool/libtool/HACKING,v retrieving revision 1.20 diff -u -r1.20 HACKING --- HACKING 17 Sep 2005 07:29:01 - 1.20 +++ HACKING 25 Sep 2005 10:22:46 - @@ -368,9 +368,8 @@ since last release (they should be updated in CVS along with commits that require it so that users can work with CVS snapshots). -* Double check that libltdl version number updates weren't forgotten since last - release (they should be updated in CVS along with commits that require it so - that users can work with CVS snapshots). +* Update the libltdl VERSION_INFO in Makefile.am for changes since the last + release. * Update the version number in configure.ac. See http://www.gnu.org/software/libtool/contribute.html for details of
FYI: alternate names for autom4te
Hi Tim,
* Tim Rice wrote on Sun, Sep 25, 2005 at 11:02:42PM CEST:
CVS HEAD
Here is a small patch to configure.ac to allow
AUTOM4TE=/opt/bin/autom4te259 /some/path/to/configure .
(solved my 106 of 106 tests failed problem) ;-)
Thank you for this patch. Applied to HEAD with the ChangeLog entry
below.
Cheers,
Ralf
2005-09-26 Tim Rice [EMAIL PROTECTED]
* configure.ac AUTOM4TE: Allow variable override.
--- configure.ac.old 2005-08-29 06:58:07.0 -0700
+++ configure.ac 2005-09-25 13:39:25.645733007 -0700
@@ -37,7 +37,7 @@
## ##
AC_CONFIG_TESTDIR([tests])
-AC_SUBST([AUTOM4TE], [autom4te])
+AC_SUBST([AUTOM4TE], [${AUTOM4TE=autom4te}])
AC_SUBST([AUTOTEST], ['$(AUTOM4TE) --language=autotest'])
Re: branch-1-5 UnixWare fixes
Hi Tim, * Tim Rice wrote on Mon, Sep 26, 2005 at 08:41:21PM CEST: On Mon, 26 Sep 2005, Ralf Wildenhues wrote: : * Tim Rice wrote on Sun, Sep 25, 2005 at 10:05:21PM CEST: : I re-ran the tests using ksh88 and all tests passed. : Must be a ksh bug. : Version M-11/16/88h passes quote test : Version M-12/28/93e-SCO fails quote test : : Please post the failing output of : make check TESTS=quote.test VERBOSE=x : : Thank you. --- begin make check TESTS=quote.test VERBOSE=x [EMAIL PROTECTED] 14% gmake check TESTS=quote.test VERBOSE=x === Running quote.test == compile mode = trying: \\ quoting = failed: mkdir .libs cc -c -DVAR=\\test\\ foo.c -KPIC -DPIC -o .libs/foo.o cc -c -DVAR=\\test\\ foo.c -o foo.o /dev/null 21 = trying: \ quoting = failed: mkdir .libs cc -c -DVAR=\test\ foo.c -KPIC -DPIC -o .libs/foo.o cc -c -DVAR=\test\ foo.c -o foo.o /dev/null 21 = trying: \` quoting = failed: mkdir .libs cc -c -DVAR=\`test\` foo.c -KPIC -DPIC -o .libs/foo.o cc -c -DVAR=\`test\` foo.c -o foo.o /dev/null 21 = trying: \$ quoting = failed: mkdir .libs cc -c -DVAR=\$test\$ foo.c -KPIC -DPIC -o .libs/foo.o cc -c -DVAR=\$test\$ foo.c -o foo.o /dev/null 21 *snip* FAIL: quote.test OK. This is mostly harmless, and we should eventually adjust quote.test. I tried to fix this in CVS HEAD with a patch on 2004-12-28 but had to throw that back out on 2005-06-05 because that broke on other systems' shells. Thanks for posting. : *snip* : : Content-Description: branch-1-5-uw.patch *snip* : : : : -sysv4*uw2* | unixware7*) : : +unixware7*) : : : : Now, this macro doesn't have a match for sysv4*uw2* any more. Is this : : intentional? : : Quite intentional. Look at the case above, it already had sysv4*uw2* so : the one I removed would never have been used anyway. Adding the pc) : case to the $host_vendor part did what the other case was supposed to do. : : Erm, it had sysv4.2uw2* but not sysv4*uw2*. If both should be treated : similarly here, then you should replace the former with the latter (in : the line where sysv4 is also matched) Remind me never to take a proof reading job. I guess my brain was focusing in the uw2 part. All UnixWare 2.x versions (and 1.x) are sysv4.2, so the sysv4*uw2 entry becomes redundant. Well, I _was_ cheating a bit: http://lists.gnu.org/archive/html/bug-libtool/2005-09/msg00013.html http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00036.html (be sure to look through both threads -- I installed a bogus patch first, stumbling over this exact same issue ;-) : It could be cleanded up further by having sysv5* | unixware7*). : (UnixWare 7 is sysv5) : : Hmm, then both of those should be treated similarly, I guess? Yes. OK. Cheers, Ralf
Re: branch-1-5 UnixWare fixes
On Mon, 26 Sep 2005, Ralf Wildenhues wrote: Hi Tim, * Tim Rice wrote on Mon, Sep 26, 2005 at 08:41:21PM CEST: On Mon, 26 Sep 2005, Ralf Wildenhues wrote: : * Tim Rice wrote on Sun, Sep 25, 2005 at 10:05:21PM CEST: [snip] : : Content-Description: branch-1-5-uw.patch *snip* : : : : -sysv4*uw2* | unixware7*) : : +unixware7*) : : : : Now, this macro doesn't have a match for sysv4*uw2* any more. Is this : : intentional? : : Quite intentional. Look at the case above, it already had sysv4*uw2* so : the one I removed would never have been used anyway. Adding the pc) : case to the $host_vendor part did what the other case was supposed to do. : : Erm, it had sysv4.2uw2* but not sysv4*uw2*. If both should be treated : similarly here, then you should replace the former with the latter (in : the line where sysv4 is also matched) Remind me never to take a proof reading job. I guess my brain was focusing in the uw2 part. All UnixWare 2.x versions (and 1.x) are sysv4.2, so the sysv4*uw2 entry becomes redundant. Well, I _was_ cheating a bit: http://lists.gnu.org/archive/html/bug-libtool/2005-09/msg00013.html http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00036.html (be sure to look through both threads -- I installed a bogus patch first, stumbling over this exact same issue ;-) And I made the same mistake (sysv4*uw2/sysv4.2*uw2) in http://lists.gnu.org/archive/html/libtool-patches/2004-10/msg00012.html OK, so we don't need to worry about sysv4*uw2 as all UnixWare 2 are sysv4.2 : It could be cleanded up further by having sysv5* | unixware7*). : (UnixWare 7 is sysv5) : : Hmm, then both of those should be treated similarly, I guess? Yes. OK. Cheers, Ralf -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: branch-1-5 UnixWare fixes
On Mon, 26 Sep 2005, Ralf Wildenhues wrote:
Hi Tim,
* Tim Rice wrote on Mon, Sep 26, 2005 at 10:45:29PM CEST:
On Mon, 26 Sep 2005, Ralf Wildenhues wrote:
* Tim Rice wrote on Mon, Sep 26, 2005 at 08:41:21PM CEST:
All UnixWare 2.x versions (and 1.x) are sysv4.2, so the sysv4*uw2 entry
becomes redundant.
Well, I _was_ cheating a bit:
http://lists.gnu.org/archive/html/bug-libtool/2005-09/msg00013.html
http://lists.gnu.org/archive/html/libtool-patches/2005-09/msg00036.html
(be sure to look through both threads -- I installed a bogus patch first,
stumbling over this exact same issue ;-)
And I made the same mistake (sysv4*uw2/sysv4.2*uw2) in
http://lists.gnu.org/archive/html/libtool-patches/2004-10/msg00012.html
OK, so we don't need to worry about sysv4*uw2 as all UnixWare 2 are
sysv4.2
Good thing we got that sorted out. ;-)
Could you -- in light of this -- repost your patch, so we can apply it?
(Or test CVS HEAD first and then repost; whatever suits you best.)
A ChangeLog entry would be nice, but I'll happily write one for you,
too. :)
Ok, here it is including an attempt at a ChangeLog entry.
Thank you,
Ralf
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- libtool-1.5/ChangeLog.old 2005-09-25 09:00:18.0 -0700
+++ libtool-1.5/ChangeLog 2005-09-26 15:54:26.944777219 -0700
@@ -1,3 +1,12 @@
+2005-09-26 Tim Rice [EMAIL PROTECTED]
+
+ * libtool.m4 (AC_DEPLIBS_CHECK_METHOD, AC_LIBTOOL_SYS_DYNAMIC_LINKER)
+ (AC_LIBTOOL_LANG_CXX_CONFIG, AC_LIBTOOL_PROG_COMPILER_PIC)
+ (AC_LIBTOOL_PROG_LD_SHLIBS):
+ * ltdl.m4 (AC_LTDL_SYS_DLOPEN_DEPLIBS):
+ Get UnixWare 7.1.[34] and OpenServer 6 fully working.
+ Improve other UnixWare versions a little.
+
2005-09-25 Alan W. Irwin [EMAIL PROTECTED],
Ralf Wildenhues [EMAIL PROTECTED]
--- libtool-1.5/libtool.m4.old 2005-09-22 16:59:00.0 -0700
+++ libtool-1.5/libtool.m4 2005-09-26 15:31:57.164617030 -0700
@@ -1655,7 +1655,7 @@
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.2uw2* | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -1688,6 +1688,19 @@
fi
;;
+sysv5*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+ sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+ ;;
+
uts4*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -2314,11 +2327,7 @@
lt_cv_deplibs_check_method=pass_all
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.2uw2* | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB
(shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2339,10 +2348,13 @@
siemens)
lt_cv_deplibs_check_method=pass_all
;;
+ pc)
+lt_cv_deplibs_check_method=pass_all
+;;
esac
;;
-sysv4*uw2* | unixware7*)
+unixware7* | sysv5*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -3559,8 +3571,29 @@
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
-_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+ sysv5OpenUNIX8* | sysv5UnixWare7.[[01]].[[01]]* | sysv5uw[[78]]* |
unixware7*)
+case $cc_basename in
+ CC*)
+ _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+ runpath_var='LD_RUN_PATH'
+ _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ ;;
+esac
+;;
+ sysv5*)
+case $cc_basename in
+ CC*)
+ _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+ runpath_var='LD_RUN_PATH'
+ _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ ;;
+esac
;;
tandem*)
case $cc_basename in
@@ -4949,7 +4982,14 @@
;;
esac
;;
-
autoreconf: Allow variable override
CVS HEAD
Here is a patch to tests/defs.m4sh to fix the hard coded autoreconf.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- ChangeLog.old 2005-09-26 15:22:52.0 -0700
+++ ChangeLog 2005-09-26 16:31:55.389977074 -0700
@@ -1,3 +1,7 @@
+2005-09-26 Tim Rice [EMAIL PROTECTED]
+
+ * tests/defs.m4sh AUTORECONF: Allow variable override.
+
2005-09-26 Ralf Wildenhues [EMAIL PROTECTED]
* HACKING: Only update libltdl version info before release.
--- tests/defs.m4sh.old 2005-08-24 06:39:51.0 -0700
+++ tests/defs.m4sh 2005-09-26 16:27:42.929977009 -0700
@@ -31,6 +31,7 @@
m4_include([general.m4sh])
: ${AUTOCONF=autoconf}
+: ${AUTORECONF=autoreconf}
: ${LIBTOOL=./libtool}
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
@@ -187,7 +188,7 @@
func_msg Configuring in $my_dir
-test -f $my_testdir/configure || autoreconf --force --install $my_testdir
+test -f $my_testdir/configure || ${AUTORECONF} --force --install
$my_testdir
if test -f $my_testdir/configure; then
eval func_msg $SHELL $my_testdir/configure $my_args
Re: autoreconf: Allow variable override
On Mon, 26 Sep 2005, Tim Rice wrote:
CVS HEAD
Here is a patch to tests/defs.m4sh to fix the hard coded autoreconf.
Oops, missed one. tests/testsuite.at needed tuning up too.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
--- ChangeLog.old 2005-09-26 15:22:52.0 -0700
+++ ChangeLog 2005-09-26 18:15:08.945737083 -0700
@@ -1,3 +1,8 @@
+2005-09-26 Tim Rice [EMAIL PROTECTED]
+
+ * tests/defs.m4sh tests/testsuite.at
+ AUTORECONF: Allow variable override.
+
2005-09-26 Ralf Wildenhues [EMAIL PROTECTED]
* HACKING: Only update libltdl version info before release.
--- tests/defs.m4sh.old 2005-08-24 06:39:51.0 -0700
+++ tests/defs.m4sh 2005-09-26 16:27:42.929977009 -0700
@@ -31,6 +31,7 @@
m4_include([general.m4sh])
: ${AUTOCONF=autoconf}
+: ${AUTORECONF=autoreconf}
: ${LIBTOOL=./libtool}
# Sed that helps us avoid accidentally triggering echo(1) options like -n.
@@ -187,7 +188,7 @@
func_msg Configuring in $my_dir
-test -f $my_testdir/configure || autoreconf --force --install $my_testdir
+test -f $my_testdir/configure || ${AUTORECONF} --force --install
$my_testdir
if test -f $my_testdir/configure; then
eval func_msg $SHELL $my_testdir/configure $my_args
--- tests/testsuite.at.old 2005-09-16 01:33:24.0 -0700
+++ tests/testsuite.at 2005-09-26 18:09:16.830697004 -0700
@@ -23,6 +23,7 @@
: ${LIBTOOL=${abs_top_builddir}/libtool}
: ${ACLOCAL=aclocal}
: ${AUTOCONF=autoconf}
+: ${AUTORECONF=autoreconf}
export LIBTOOLIZE LIBTOOL ACLOCAL AUTOCONF
eval `$LIBTOOL --config | grep ^EGREP=`
eval `$LIBTOOL --config | $EGREP '^(host|host_os|build)='`
@@ -48,7 +49,7 @@
m4_define([LT_AT_BOOTSTRAP],
[
test -f ./ltmain.sh || LT_AT_LIBTOOLIZE([--copy])
-test -f ./configure || _lt_pkgdatadir=$abs_top_srcdir autoreconf --force
--verbose --install || exit 1
+test -f ./configure || _lt_pkgdatadir=$abs_top_srcdir ${AUTORECONF} --force
--verbose --install || exit 1
test -f ./configure || exit 1
./configure
])
annoying build environment
CVS HEAD Is there any reason not to have ltmain.in in the source tree at configure time and generate ltmain.sh (from ltmain.in) in the build tree? I have UnixWare, OpenServer, Solaris and Linux (each with multiple versions) here. I prefer to build from a NFS read-only source tree so I can test whatever change I make on multiple platforms while having to maintain only 1 source tree. I'd like to be able to make a change in the source tree, run bootstrap, then cd /some/build/dir, configure, make and not have it try to generate some file in the source tree. We can't do this now. But is this possible with the current design of CVS HEAD? -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: annoying build environment
Hi Tim, * Tim Rice wrote: CVS HEAD Is there any reason not to have ltmain.in in the source tree at configure time and generate ltmain.sh (from ltmain.in) in the build tree? Please try the patch from http://lists.gnu.org/archive/html/bug-libtool/2005-08/msg00039.html I'd like to be able to make a change in the source tree, run bootstrap, then cd /some/build/dir, configure, make and not have it try to generate some file in the source tree. We can't do this now. But is this possible with the current design of CVS HEAD? I'm sorry for the inconvenience. I'll apply that patch very soon if I don't find a way of not having to distribute another almost-identical copy of ltmain. Cheers, and thanks for reporting, Ralf -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-23, Ralf Wildenhues [EMAIL PROTECTED] wrote: [ By the way, I don't think everyone in this discussion has subscribed this list; if in doubt, speak up, or even better, set Mail-Followup-To: next time ] I'm following it on gmane, but an explicit Cc: isn't a problem. * Jacob Meuser wrote on Fri, Sep 23, 2005 at 04:10:36AM CEST: just add -lstdc++ manually. trust me, that works fine. I really don't see why libtool should be adding this automatically. I did wonder about getting my project's configure to always specifying -lstdc++ if the compiler if GCC (with: test $GXX = yes). But I worry that I could end up trying to link in two incompatible versions of libstdc++ on a machine with multiple GCC installations. I don't really want to risk breaking other platforms to get OpenBSD to work, especially as I can document a workaround for OpenBSD users: make LDFLAGS=-lstdc++ I could write configure code to detect OpenBSD and add -lstdc++ for OpenBSD. But such system specific tests are generally the wrong approach - what if an older or newer version of OpenBSD behaves differently? Writing a configure test which builds a C++ module and C client and tries to dlopen the former from the latter would at least fix this more generally, but wouldn't work when cross-compiling, and besides seems a bit ridiculous when libtool is meant to hide shared library portability issues. is it _always_ needed? what about -lsupc++? Ahh, very good question. Here we have an issue: it should be possible to _override_ the decision of libtool to add -lstdc++ on OpenBSD in all cases. But those cases, in my opinion, would be the exception rather than the rule: they are usually the cause when your package makes use of some system-specifics anyway. (Maybe there is even a way to detect whether supc++ is preferable over stdc++; I don't know of one, though, and in this case guessing is probably worse than allowing an override.) Can we agree on this somehow? What other issues, if any, are you experiencing? The obvious override mechanism is probably to see if the user specifies -lsupc++ explicitly and not to add -lstdc++ if they have. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-22, Ralf Wildenhues [EMAIL PROTECTED] wrote: * Olly Betts wrote on Wed, Sep 21, 2005 at 11:00:30PM CEST: The bottom line for me is that if I explicitly add -lstdc++ when linking _xapian.so, it all works. If I don't, it doesn't. So I kind of feel that ideally libtool should be doing that for me... ACK. I hate to break libtool on systems I cannot test, when the maintainers may have had good reasons to do something slightly differently than the default way, though. I've kindly been given temporary access to on an OpenBSD machine by the user who reported this issue to me. If one of the libtool maintainers would find it useful to be able to test fixes, I can ask if he'd be willing to give them temporary access too. Alternatively I can test fixes. Or I can work on a fix myself, if there's consensus on what should be done (I suspect I'll need some help and advice though...) Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-23, Peter O'Gorman [EMAIL PROTECTED] wrote: I have no statistics for how many shared libraries are written in c++ but do not take advantage of the standard c++ library, at a guess I'd say that the majority use some libstdc++ features. It's perhaps worth noting that not linking libstdc++ to a library that requires it means it fails to dlopen() - a fatal error. Whereas linking libstdc++ to a library which only needs libsupc++ just means that it is linked to a shared library containing more than it needs (AIUI, libsupc++ is just a very cut down version of libstdc++). Linking to libstdc++ when you could get away with libsupc++ is essentially irrelevant if you're running any other dynamically linked C++ programs. In fact it's probably slightly better if everything uses libstdc++ than some use libsupc++! To me defaulting to C++ pulling in libstdc++ makes most sense, probably with an ability to override for the minority who don't require it and care. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: annoying build environment
Sorry for the self-followup. * Ralf Wildenhues wrote on Mon, Sep 26, 2005 at 09:02:03AM CEST: * Tim Rice wrote: CVS HEAD Is there any reason not to have ltmain.in in the source tree at configure time and generate ltmain.sh (from ltmain.in) in the build tree? Please try the patch from http://lists.gnu.org/archive/html/bug-libtool/2005-08/msg00039.html I'd like to be able to make a change in the source tree, run bootstrap, then cd /some/build/dir, configure, make and not have it try to generate some file in the source tree. We can't do this now. But is this possible with the current design of CVS HEAD? D'oh. Said patch is not sufficient, because of the `touch' at the end of bootstrap. I'll see if we can get rid of that, it's ugly anyway. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
static vs. dynamic linking
Hi folks, how does libtool decide whether to link against an .la library dynamically vs. statically ? I'm currently working on my own implementation, since libtool doesn't suit my needs (ie. sysroot'ed building), but I didn't find any clear specification for libtool's behaviour. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool generated for tests
branch-1-5 Could someone explain why the libtool generated in the test dirs are different than the one in the build dir? Or more importanbtly, why a software package using ltmain.sh from 1.5.21a would build a libtool that didn't work but copying libtool from my libtool build dir would work. The differences looked similar to the ones below. --- depdemo/libtool 2005-09-26 16:03:23.949817104 -0700 +++ libtool 2005-09-26 15:57:57.144777437 -0700 @@ -1,7 +1,7 @@ #! /bin/ksh # libtoolT - Provide generalized library-building support services. -# Generated automatically by (GNU depdemo 0.1) +# Generated automatically by (GNU libtool 1.5.21a (1.1220.2.300 2005/09/25 07:37:09)) # NOTE: Changes made to this file will be lost: look at ltmain.sh. # # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 @@ -53,7 +53,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -70,7 +70,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -159,10 +159,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown @@ -6896,7 +6896,7 @@ build_libtool_libs=yes # Whether or not to build static libraries. -build_old_libs=no +build_old_libs=yes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=no @@ -6913,7 +6913,7 @@ host_os=sysv5UnixWare7.1.4 # The build system. -build_alias=i686-unknown-sysv5UnixWare7.1.4 +build_alias= build=i686-unknown-sysv5UnixWare7.1.4 build_os=sysv5UnixWare7.1.4 @@ -7002,10 +7002,10 @@ need_version=no # Whether dlopen is supported. -dlopen_support=unknown +dlopen_support=yes # Whether dlopen of programs is supported. -dlopen_self=unknown +dlopen_self=no # Whether dlopen of statically linked programs is supported. dlopen_self_static=unknown -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED] ___ http://lists.gnu.org/mailman/listinfo/libtool
