326-gary-remove-stamp-vcl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tested with vendor make on OSF/1 5.1, AIX 5.2, IRIX 6.5, HPUX 10.20
and Solaris 10. Apart from IRIX, VPATH builds also work from a fresh
dist tarball on the other architectures -- to my surprise! I've also
successfully completed a full test run for a VPATH and in-tree build
on Linux, so there are no regressions.
Okay to commit to HEAD?
Index: ChangeLog
from Gary V. Vaughan [EMAIL PROTECTED]
The stamp-vcl file rules caused non-gnu make programs to rerun
parts of the configuration process on each invocation. Instead
of relying on a stamp file, we now compare version numbers of
generated files with the ChangeLog timestamp manually in the
affected make rules to decide whether regenerating is necessary:
* Makefile.am (EXTRA_DIST): Remove stamp-vcl.
(clean-ltmain-sh): Also remove users' obsolescent stamp-vcl.
(rebuild): Keep some common code here for...
(libtool, libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh):
Rewritten to work without reference to intermediate stamp-vcl
file.
* configure.ac (CONFIG_STATUS_DEPENDENCIES): Change from
stamp-vcl to ChangeLog.
Index: Makefile.am
===
RCS file: /sources/libtool/libtool/Makefile.am,v
retrieving revision 1.214
diff -u -u -r1.214 Makefile.am
--- Makefile.am 25 Mar 2007 12:12:42 - 1.214
+++ Makefile.am 26 Mar 2007 16:48:59 -
@@ -47,6 +47,16 @@
# Using `cd' in backquotes may print the directory name, use this instead:
lt__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR) cd
+MKSTAMP = $(SHELL) $(srcdir)/$(auxdir)/mkstamp
+
+timestamp = set dummy `$(MKSTAMP) $(srcdir)/ChangeLog`; shift; \
+ case $(VERSION) in \
+ *[acegikmoqsuwy]) TIMESTAMP= $$1 $$2 $$3 ;; \
+ *) TIMESTAMP= ;; \
+ esac
+
+rebuild = rebuild=:; $(timestamp); correctver=$$1
+
## ##
## Libtool scripts. ##
@@ -76,9 +86,21 @@
rm -f libtoolize.in; \
$(M4SH) -B $(auxdir) libtoolize.m4sh libtoolize.in
-libtool: $(top_builddir)/config.status $(srcdir)/$(auxdir)/ltmain.sh \
- $(srcdir)/stamp-vcl
- cd $(top_builddir) $(SHELL) ./config.status $@
+# We used to do this with a 'stamp-vcl' file, but non-gmake builds
+# would rerun configure on every invocation, so now we manually
+# check the version numbers from the build rule when necessary.
+libtool: clean-ltmain-sh $(top_builddir)/config.status
$(srcdir)/$(auxdir)/ltmain.sh ChangeLog
+ @target=libtool; $(rebuild); \
+ if test -f $$target; then \
+ set dummy `./$$target --version | sed 1q`; actualver=$$5; \
+ test $$actualver = $$correctver rebuild=false; \
+ fi; \
+ if $$rebuild; then \
+ echo $(SHELL) ./config.status $$target; \
+ cd $(top_builddir) $(SHELL) ./config.status $$target; \
+ else \
+ echo \`$$target\' is up to date; \
+ fi
.PHONY: configure-subdirs
configure-subdirs distdir: $(DIST_MAKEFILE_LIST)
@@ -114,15 +136,9 @@
-e 's,@prefix\@,$(prefix),g' \
-e s,@configure_input\@,Generated from $$input; do not edit by hand,g
-timestamp = set dummy `$(MKSTAMP) $(srcdir)/ChangeLog`; shift; \
- case $(VERSION) in \
- *[acegikmoqsuwy]) TIMESTAMP= $$1 $$2 $$3 ;; \
- *) TIMESTAMP= ;; \
- esac
-
sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh
EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \
- $(auxdir)/mkstamp $(sh_files) stamp-vcl \
+ $(auxdir)/mkstamp $(sh_files) \
ChangeLog.1996 ChangeLog.1997 ChangeLog.1998 \
ChangeLog.1999 ChangeLog.2000 ChangeLog.2001 \
ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \
@@ -130,19 +146,6 @@
CLEANFILES += libtool libtoolize libtoolize.tmp \
$(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp
-## We know that $(srcdir)/ChangeLog has been edited if stamp-vcl
-## needs updating, so we assume we have write access to $(srcdir).
-## If we try to maintain ./stamp-vcl to avoid writing to a possibly
-## read-only $(srcdir), then when the two stamp-vcls differ, distcheck
-## will try to update the one in the read-only source tree it makes.
-MKSTAMP = $(SHELL) $(srcdir)/$(auxdir)/mkstamp
-$(srcdir)/stamp-vcl: vcl-tmp clean-ltmain-sh ChangeLog
-vcl-tmp:
- @set dummy `$(MKSTAMP) $(srcdir)/ChangeLog`; shift; \
- echo $$1 vcl.tmp; \
- diff vcl.tmp $(srcdir)/stamp-vcl /dev/null 21 \
- || (echo Updating stamp-vcl; cp vcl.tmp $(srcdir)/stamp-vcl)
- [EMAIL PROTECTED] -f vcl.tmp
## We used to build ltmain.sh in the build tree, but now it is created
## in the source tree by bootstrap. This rule removes stale copies
Re: fix libtool for OpenBSD archs without shared libraries support
Hello Brad, Matthieu, * Brad wrote on Sun, Mar 25, 2007 at 10:32:36PM CEST: The following diffs to fix libtool for OpenBSD archs without shared libraries support is a re-application to the appropriate branches of the 1.5 patch Matthieu commited to the OpenBSD ports tree.. http://marc.info/?l=openbsd-ports-cvsm=117482275009572w=2 This will fix libtool on some of the older archs OpenBSD runs on such as vax and m88k or not so old, but without shared libs support (yet) such as landisk (sh). I don't have a problem with applying this patch, but out of curiosity, is there a similarly easy check that doesn't break down for cross compilation to OpenBSD? (No, I don't know if anybody uses that.) Cheers, and thanks for the heads-up, Ralf [...] +if test -f /usr/libexec/ld.so; then [...]
Re: Support for Interix 5.2 and 6.0?
Hello Peter, Martin, all
* Martin Koeppe wrote on Wed, Mar 21, 2007 at 11:45:22PM CET:
the following problems occured:
- without ./bootstrap, libtool-2.1 doesn't have
config.guess/config.sub files, so I used
./configure --build=i586-pc-interix5.2.
OTOH, libltdl/config has very old config.{sub,guess}, the same
old version is in several tests, which therefore fail for me.
Peter, could we get the daily snapshot to be bootstrapped with Automake
1.10 and Autoconf 2.61? Thanks.
Until then, I guess you, Martin, need to bootstrap before testing.
Alternatively, assuming that you have up to date copies of config.guess
and config.sub in the directory $config_sources, you could do something
like
find libtool-2.1a -name 'config\.*' -exec \
cp $config_sources/config.* \{\} \;
and retest. For 2.1a, there is only one instance of the config.* files
anyway, so you can just replace them manually.
If the failure don't know how to build libltdlc.la persists with the
nightly tarballs, we need to look into that. Which make version is
this?
Sorry, you guessed right. I did accidentally not use GNU make on Interix
5.2. Now I have installed GNU make 3.81 there, too, and building and all
tests done with it. Now for 1.5.23c, there is only 1 failing test, the
hardcode test.
What 'make' did you then use on Interix, and where can I get
documentation for it?
Cheers,
Ralf
Re: 326-gary-remove-stamp-vcl
On 26 Mar 2007, at 19:13, Ralf Wildenhues wrote: Hi Gary, Hallo Ralf, * Gary V. Vaughan wrote on Mon, Mar 26, 2007 at 07:10:21PM CEST: Tested with vendor make on OSF/1 5.1, AIX 5.2, IRIX 6.5, HPUX 10.20 and Solaris 10. Apart from IRIX, VPATH builds also work from a fresh dist tarball on the other architectures -- to my surprise! I've also successfully completed a full test run for a VPATH and in-tree build on Linux, so there are no regressions. Thank you, for all the work on this! My pleasure. Are there any other beta-blockers (ahem!) we need to resolve before putting out a 2.1b tarball? Okay to commit to HEAD? I see one smallish issue and a couple of nits: First, now whenever ChangeLog is touched, the configure recheck will be triggered. This isn't a biggie, and if we don't see a simple way around it, then it should just stay as it is. (I think this was the reason the stamp file was originally invented for anyway.) Yeah, but our users shouldn't see that. The main reason I introduced the stamp-vcl glue was to force config.status to pick up the new TIMESTAMP from ChangeLog after a cvs commit. Depending on ChangeLog alone could trigger the infamous double configure we worked so hard to get rid of. I think the ugly shell code I'm putting in the relevant make rules doesn't have this problem. Second, can we remove the `$target is up to date' output for all thingies? Please also update NEWS to reflect this change. Sure, I'll repost with those changes presently. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
FYI: 326-gary-remove-stamp-vcl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Applied to HEAD, including changes suggested by Ralf.
Index: ChangeLog
from Gary V. Vaughan [EMAIL PROTECTED]
The stamp-vcl file rules caused non-gnu make programs to rerun
parts of the configuration process on each invocation. Instead
of relying on a stamp file, we now compare version numbers of
generated files with the ChangeLog timestamp manually in the
affected make rules to decide whether regenerating is necessary:
* Makefile.am (EXTRA_DIST): Remove stamp-vcl.
(clean-ltmain-sh): Also remove users' obsolescent stamp-vcl.
(rebuild): Keep some common code here for...
(libtool, libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh):
Rewritten to work without reference to intermediate stamp-vcl
file.
* configure.ac (CONFIG_STATUS_DEPENDENCIES): Change from
stamp-vcl to ChangeLog.
* NEWS: Removed entry saying this fix is needed.
Index: Makefile.am
===
RCS file: /sources/libtool/libtool/Makefile.am,v
retrieving revision 1.214
diff -u -u -r1.214 Makefile.am
--- Makefile.am 25 Mar 2007 12:12:42 - 1.214
+++ Makefile.am 26 Mar 2007 20:18:19 -
@@ -47,6 +47,16 @@
# Using `cd' in backquotes may print the directory name, use this instead:
lt__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR) cd
+MKSTAMP = $(SHELL) $(srcdir)/$(auxdir)/mkstamp
+
+timestamp = set dummy `$(MKSTAMP) $(srcdir)/ChangeLog`; shift; \
+ case $(VERSION) in \
+ *[acegikmoqsuwy]) TIMESTAMP= $$1 $$2 $$3 ;; \
+ *) TIMESTAMP= ;; \
+ esac
+
+rebuild = rebuild=:; $(timestamp); correctver=$$1
+
## ##
## Libtool scripts. ##
@@ -76,9 +86,19 @@
rm -f libtoolize.in; \
$(M4SH) -B $(auxdir) libtoolize.m4sh libtoolize.in
-libtool: $(top_builddir)/config.status $(srcdir)/$(auxdir)/ltmain.sh \
- $(srcdir)/stamp-vcl
- cd $(top_builddir) $(SHELL) ./config.status $@
+# We used to do this with a 'stamp-vcl' file, but non-gmake builds
+# would rerun configure on every invocation, so now we manually
+# check the version numbers from the build rule when necessary.
+libtool: clean-ltmain-sh $(top_builddir)/config.status
$(srcdir)/$(auxdir)/ltmain.sh ChangeLog
+ @target=libtool; $(rebuild); \
+ if test -f $$target; then \
+ set dummy `./$$target --version | sed 1q`; actualver=$$5; \
+ test $$actualver = $$correctver rebuild=false; \
+ fi; \
+ if $$rebuild; then \
+ echo $(SHELL) ./config.status $$target; \
+ cd $(top_builddir) $(SHELL) ./config.status $$target; \
+ fi
.PHONY: configure-subdirs
configure-subdirs distdir: $(DIST_MAKEFILE_LIST)
@@ -114,15 +134,9 @@
-e 's,@prefix\@,$(prefix),g' \
-e s,@configure_input\@,Generated from $$input; do not edit by hand,g
-timestamp = set dummy `$(MKSTAMP) $(srcdir)/ChangeLog`; shift; \
- case $(VERSION) in \
- *[acegikmoqsuwy]) TIMESTAMP= $$1 $$2 $$3 ;; \
- *) TIMESTAMP= ;; \
- esac
-
sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh
EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \
- $(auxdir)/mkstamp $(sh_files) stamp-vcl \
+ $(auxdir)/mkstamp $(sh_files) \
ChangeLog.1996 ChangeLog.1997 ChangeLog.1998 \
ChangeLog.1999 ChangeLog.2000 ChangeLog.2001 \
ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \
@@ -130,19 +144,6 @@
CLEANFILES += libtool libtoolize libtoolize.tmp \
$(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp
-## We know that $(srcdir)/ChangeLog has been edited if stamp-vcl
-## needs updating, so we assume we have write access to $(srcdir).
-## If we try to maintain ./stamp-vcl to avoid writing to a possibly
-## read-only $(srcdir), then when the two stamp-vcls differ, distcheck
-## will try to update the one in the read-only source tree it makes.
-MKSTAMP = $(SHELL) $(srcdir)/$(auxdir)/mkstamp
-$(srcdir)/stamp-vcl: vcl-tmp clean-ltmain-sh ChangeLog
-vcl-tmp:
- @set dummy `$(MKSTAMP) $(srcdir)/ChangeLog`; shift; \
- echo $$1 vcl.tmp; \
- diff vcl.tmp $(srcdir)/stamp-vcl /dev/null 21 \
- || (echo Updating stamp-vcl; cp vcl.tmp $(srcdir)/stamp-vcl)
- [EMAIL PROTECTED] -f vcl.tmp
## We used to build ltmain.sh in the build tree, but now it is created
## in the source tree by bootstrap. This rule removes stale copies from
@@ -150,29 +151,45 @@
## source tree version in current builds.
clean-ltmain-sh:
@-test $(srcdir) = $(top_builddir) || \
- rm -f $(top_builddir)/$(auxdir)/ltmain.sh
+ rm -f $(top_builddir)/$(auxdir)/ltmain.sh stamp-vcl
-# We build ltversion.m4
Re: 326-gary-remove-stamp-vcl
Hallo Ralf, On 26 Mar 2007, at 21:07, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Mar 26, 2007 at 09:56:14PM CEST: On 26 Mar 2007, at 19:13, Ralf Wildenhues wrote: Second, can we remove the `$target is up to date' output for all thingies? Please also update NEWS to reflect this change. Sure, I'll repost with those changes presently. Just in case that wasn't clear (and upon rereading I realize that it wasn't), please just go ahead and commit with those changes. Okay, thanks. Done. Now, where is the list of issues that need to be worked on kept nowadays? Is http://wiki.azazil.net relevant anymore? It's been a while since I had time to work on libtool :-( Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
open issues for HEAD (was: 326-gary-remove-stamp-vcl)
* Gary V. Vaughan wrote on Mon, Mar 26, 2007 at 10:25:38PM CEST: Now, where is the list of issues that need to be worked on kept nowadays? Is http://wiki.azazil.net relevant anymore? Yes, mostly. I just marked that GNU make issue as fixed there, and have been going over it some weeks ago to update some other things. NEWS lists the regressions visible to users, and those really should be the only issues we should still look at before a release, if at all. Other than that, the mailing lists of the last few weeks contain some smaller (in estimated amount of work) pending issues, mostly from Charles, and most apply to both branches. Would you like me to post a list? It's been a while since I had time to work on libtool :-( It's good to have you back though. ;-) Cheers, Ralf
Re: open issues for HEAD (was: 326-gary-remove-stamp-vcl)
Hallo Ralf, On 26 Mar 2007, at 22:03, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Mar 26, 2007 at 10:25:38PM CEST: Now, where is the list of issues that need to be worked on kept nowadays? Is http://wiki.azazil.net relevant anymore? Yes, mostly. I just marked that GNU make issue as fixed there, and have been going over it some weeks ago to update some other things. Ah, excellent. I'll start there then. NEWS lists the regressions visible to users, and those really should be the only issues we should still look at before a release, if at all. I spotted those too, but figured they didn't give a complete picture. Other than that, the mailing lists of the last few weeks contain some smaller (in estimated amount of work) pending issues, I've been following closely again since the end of February, and didn't notice anything important go by. Please do point out anything I missed though. mostly from Charles, and most apply to both branches. I don't have (or want) access to a Windows machine, so I can't be of much help with issues in that area. Would you like me to post a list? Only if there are additional things not on wiki.azazil.net or in the NEWS file... or if there is a particularly sticky issue you'd like me to tackle sooner than the others. It's been a while since I had time to work on libtool :-( It's good to have you back though. ;-) Thank you kindly. It's good to be back; a bit like coming home after a long trip :-D Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
Re: open issues for HEAD
* Gary V. Vaughan wrote on Mon, Mar 26, 2007 at 11:20:32PM CEST: On 26 Mar 2007, at 22:03, Ralf Wildenhues wrote: NEWS lists the regressions visible to users, and those really should be the only issues we should still look at before a release, if at all. I spotted those too, but figured they didn't give a complete picture. Not complete. I figured them to be the most important, though. Would you like me to post a list? Only if there are additional things not on wiki.azazil.net or in the NEWS file... or if there is a particularly sticky issue you'd like me to tackle sooner than the others. Any of the ones in NEWS. Note that the inherited_linker_flags one is a bit tricky with options that themselves have arguments. Cheers, Ralf
RE: Support for Interix 5.2 and 6.0?
Ralf Wildenhues wrote:
Hello Peter, Martin, all
* Martin Koeppe wrote on Wed, Mar 21, 2007 at 11:45:22PM CET:
the following problems occured:
- without ./bootstrap, libtool-2.1 doesn't have
config.guess/config.sub files, so I used
./configure --build=i586-pc-interix5.2.
OTOH, libltdl/config has very old config.{sub,guess}, the same
old version is in several tests, which therefore fail for me.
Peter, could we get the daily snapshot to be bootstrapped with
Automake
1.10 and Autoconf 2.61? Thanks.
Until then, I guess you, Martin, need to bootstrap before testing.
Alternatively, assuming that you have up to date copies of
config.guess and config.sub in the directory $config_sources, you
could do something like
find libtool-2.1a -name 'config\.*' -exec \
cp $config_sources/config.* \{\} \;
and retest. For 2.1a, there is only one instance of the config.*
files anyway, so you can just replace them manually.
If the failure don't know how to build libltdlc.la persists with
the nightly tarballs, we need to look into that. Which make
version is this?
Sorry, you guessed right. I did accidentally not use GNU make on
Interix
5.2. Now I have installed GNU make 3.81 there, too, and building and
all tests done with it. Now for 1.5.23c, there is only 1 failing
test, the hardcode test.
What 'make' did you then use on Interix, and where can I get
documentation for it?
It for sure was the native interix make - i'm having big porblems with
it too. When building the wgcc package, it simply doesn't build some
things. The result is that there is only one library, but no executable
and nothing.
- Native make on interix is not usable, only to build GNU make ;o)
Cheers, Markus
Cheers,
Ralf
library versioning problem
Hi to all,
I would like to use libtool to manage versioning of a library called,
say mylib
libtool version is 1.5.6-6 under Linux Debian Sarge 3.1 stable
In the configure.ac at the project root, I have the lines:
mylib_CUR=69
mylib_REV=47
mylib_AGE=38
AC_SUBST(mylib_CUR)
AC_SUBST(mylib_REV)
AC_SUBST(mylib_AGE)
In project sources dir, Makefile.am contains:
mylib_la_CPPFLAGS=-Dmylib_CUR=${mylib_CUR} -Dmylib_REV=${mylib_REV}
-Dmylib_AGE=${mylib_AGE}
mylib_la_LDFLAGS=-version-info ${mylib_CUR}:${mylib_REV}:${mylib_AGE}
I configure the library with:
./configure --prefix=/usr/local/mylib-69.47.38-i18n
So I expected to find mylib.so.69.47.38 in
/usr/local/mylib-69.47.38-i18n/lib, but instead of that, I find
mylib.so.31.38.47
That means:
CURRENT is replaced by CURRENT - AGE (69 - 38 = 31)
REVISION is replaced by AGE
AGE is replaced by REVISION
Surely, I misunderstood something, so an explanation would be very nice
Thanks in advance
Lucien
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libjpeg.la
On 26 Mar 2007, at 05:05, Jeevan Reddy wrote: Hi, I am installing GDAL1.3.2 and 1.4.0 but here I am getting error as follows.. usr/bin/sed: can't read /usr/lib/libjepg.la: No such file or directory ^^^ Here is your problem. You either don't have or have insufficient permission to read the file /usr/lib/libjepg.la (assuming this is a spelling mistake). libtool: link: '/usr/lib/libjpeg.la' is not a valid libtool archive make[1]: *** [libgdal.la] Error 1 make[1]: Leaving directory '/usr/lib/gdal/gdal-cvs-2006.05.18' make: *** [check-lib] Error 2 can you plz help me Please send such questions to the list itself bug-libtool@gnu.org in future where more people will be available to help you. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: library versioning problem
Hi Lucien, On 25 Mar 2007, at 16:50, Lucien GENTIS wrote: That means: CURRENT is replaced by CURRENT - AGE (69 - 38 = 31) REVISION is replaced by AGE AGE is replaced by REVISION http://www.gnu.org/software/libtool/manual.html#Libtool-versioning Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] New library type needed?
Charles Wilson wrote: I completely understand the motivation for the meat of this, speaking in the hypothetical sense, but why would you ever want to build libbfd shared? I did --enable-shared at the top level, and bfd is the first one that failed. I'm really more interested in the runtime libs (libgcc, libsupc++, etc) but I'm pretty sure that almost everything depends on libiberty...so the problem will show up eventually somewhere I care about. Why not solve it up front, with the first failure? Sure, I could have configured using --enable-shared=lib,lib,lib and left libbfd out of the list, but... It is always built static by default even on ELF systems, for the same reason as libiberty - it is not expected to expose anything resembling a stable or maintained ABI. Not entirely true. It is explicitly a part of binutils, and binutils has a version number. Plus, libbfd is already libtoolized and built using -release (*not* -version-info) so you'd end up with cygbfd-2.7.50.dll or somesuch. And its maintainers do not want the burden of having to maintain an ABI given its history of not being designed as such. So it seems like a really bad idea to jump through hoops to make it shared, as you'd end up with the situation you mentioned dozens of cygbfd-long string.dll files to satisfy all the various consumers. See above; the binutils maintainers have already thought of this, which is why they use -release. They can do this becuase bfd is part of bintuils, and not *part of* anything else, even if it may be *used by* something else. libiberty OTOH is shared _at the source_ level between binutils, gcc, newlib, and cygwin projects (more?) -- so (a) no one project owns it (b) it has no version number (c) it is needed to resolve undefined symbols (on windows) within not just applications from those various projects, but also libraries. Maybe I'm wrong; maybe libiberty is only needed by the non-runtimes, and I should just let -shared fail for libbfd and libopcodes, and hope for the best with respect to libgcc and all the runtime libs. But I think I've uncovered an underlying limitation (maybe win32-specific) with the current set of library types managed by libtool -- which is why I mentioned the other major set of software shared between projects at the source level: gnulib. Right now, any shared library that uses gnulib (typically built as a convenience library) will export symbols for (for instance) basename, just because they happen to use that symbol internally. cygMyLibrary.dll and cygYourLibrary.dll shouldn't both supply that symbol, should they? It's an internal implementation detail...but right now, the only way to not export gnulib-supplied stuff is to turn off auto-export in your non-gnulib code by explicitly declspec()ing stuff or using .def files (ugh. back to the bad old days). Or relying on non-portable tricks that lead to command lines with junk like this -Wl,--exclude-libs -Wl,libiberty.a -Wl,libgnulib.a AND -Wl,--whole-archive libiberty.a -Wl,--no-whole-archive -Wl,--whole-archive libgnulib.a -Wl,--no-whole-archive where these are hand-coded to a degree, in that the --exclude-libs garbage is inserted via _LDFLAGS. Ick. Granted, the gnulib folks are fitfully investigating mechanisms to rename symbols (e.g. cygMyLibrary might have MyLibary_basename, while cygYourLibrary would have YouLibrary_basename), which would prevent symbols from *clashing*. But even then, these internal implementation-detail symbols should not be in the export list. (I'm glossing over certain complications with gnulib, like program_name data elements and such, which would become awkward under both symbol-renaming and do-not-export regimes. Leave that aside for now...) -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] New library type needed?
Hello Charles, Here's a review based on the question how such a concept could be expressed portably. I don't see how something like this would be of great help if it could not be made to gracefully decay into something still usable, on at least a useful set of platforms if not all of them. * Charles Wilson wrote on Sun, Mar 25, 2007 at 09:34:47PM CEST: What I really want is a type of convenience library (call it a resolver library?) that (1) is built both PIC and non-PIC, depending of course on the value of enable_shared and enable_static. So far, just like a normal convenience lib. Well, currently a convenience lib is not built in both ways at the same time, but that's only a side issue for the discussion at hand. (2) where the non-PIC resolver library is ignored when building dependent static libraries (and dependent static [dlpreopened] modules). That is, NOT exploded and included within the dependent. However, the non-PIC resolver library should be used like a normal convenience library when building dependent, in-package executables that depend on it directly OK so far. You want a convenience archive without the whole-ness. Should it be possible to install this thing or not? Can it itself have nontrivial (i.e., non-convenience) dependencies? The first of these questions is really a crux of the matter: if libbfd can be shared and installable, then really I don't see any way except - either explicitly forbid any third party to use your library, even though you install it shared, - or have at least some sort of stable interface notion. (worry about PIE here? We don't worry about it at present anywhere that I can see). We have very minimal PIE support only currently in CVS HEAD, in compile mode. (3) where the PIC resolver library is used *like a static library* when building dependent shared libraries -- that is, used to satisfy undefined symbols in the shared library if -no-undefined, but where the objects in the PIC resolver library are not included wholesale via [ not correction included ] --whole-archive/--no-whole-archive -- and better yet, on win32 they should be excluded from auto-export using -Wl,--exclude-lib -Wl,PIC resolver library name. Lots of systems don't allow symbol hiding (or, at least, Libtool currently doesn't support it well on most systems). What should happen for them? More to the point: what if libbfd uses the resolver libiberty release x, while libfoo used release y of libiberty, we're on a system without symbol hiding, and my program links against both libbfd and libfoo? The order of linkage will determine in which library the blow up occurs, be that silent or spectacular, depending on how incompatible x and y are. Also, these static libraries should not trigger the you can't create shared libs with static dependencies filter within libtool. Several systems simply don't allow to mix PIC and non-PIC symbols. On w32 this warning is pathetic, but on others we would have a problem here. (I can see why, on w32, you'd want to kill the warning here.) (Hmm. When -no-undefined is NOT specified, then there's a choice: you could satisfy as many undefined symbols as you could by passing the resolver lib to the linker, or you could simply drop the resolver entirely -- which would match the current build procedure for libbfd friends on non-win32...) I don't think it would be that difficult to add this facility to libtool -- No, it wouldn't. The semantics are the hard part. If we can't get well-defined semantics, the new baby will be useful for binutils (and of course the set of packages that use it) only. But I'd rather not -- especially this close (?) to 2.0final Certainly not. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [cygwin] Analysis for new testsuite failures 33,34.35
Hi Charles, Thanks for the bug report. * Charles Wilson wrote on Fri, Mar 23, 2007 at 07:32:12AM CET: ../../libtool-HEAD/tests/subproject.at:56: $MAKE all $tst_dist + make all dist [...] mkdir: cannot create directory `/usr/src/libtool/cvs/_build/tests/testsuite.dir/33/subproject-demo-2.1a/sub/ltdl': File exists make[2]: *** [distdir] Error 1 AFAICS, this can only happen if libltdl was treated with automake-1.9 and the tests run with automake-1.10 in place, so that the toplevel package (named subproject-demo-2.1a) is treated with 1.10. Hmm. This is kind of a backward incompatibility, unfortunately. It can be helped by using the same Automake version for both bootstrapping and testing, or by using 1.10 for libltdl. [...] Now, I'm not sure how to solve this problem: I don't know what the policy is on the required version of automake for libtool-HEAD, but I'm pretty sure it isn't require 1.10. But I also don't know if automake-1.9.x is still under development, and would accept the above backport for some future automake-1.9.7 release. Alexandre said he did not want to continue 1.9. If there were to be another point release, this patch would certainly be a good candidate IMHO. For reference, below's the patch including ChangeLog entry. Cheers, Ralf 2007-03-26 Charles Wilson ... * lib/am/distdir.am (distdir): Do not fail if $(distdir) already exists, for forward compatibility with Automake 1.10 that overrides the removal due to $(am__remove_distdir). Fixes `make dist' failures in which the toplevel package uses 1.10, but a subpackage 1.9 only. Index: lib/am/distdir.am === RCS file: /cvs/automake/automake/lib/am/distdir.am,v retrieving revision 1.60.2.1 diff -u -r1.60.2.1 distdir.am --- lib/am/distdir.am 14 May 2005 20:29:20 - 1.60.2.1 +++ lib/am/distdir.am 26 Mar 2007 18:36:36 - @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 2001, 2002, 2003, 2004 Free Software Foundation, Inc. +## Copyright (C) 2001, 2002, 2003, 2004, 2007 Free Software Foundation, Inc. ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by @@ -50,7 +50,7 @@ ## if %?TOPDIR_P% $(am__remove_distdir) - mkdir $(distdir) + test -d $(distdir) || mkdir $(distdir) endif %?TOPDIR_P% ## ## ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Support for VC++ toolchain (was Re: Absolute paths generatedbylibtool.)
On 2006-11-28, Duft Markus [EMAIL PROTECTED] wrote: If you could tell me how i can bring outlook to do so, i will gladly ;o) Off-topic, but in the interests of improving the readability of this list (and others!): Outlook: http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook Express: http://home.in.tum.de/~jain/software/oe-quotefix/ Or sign up for a gmail account - it handles lists pretty well. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [cygwin] Analysis for new testsuite failures 33,34.35
On Mon, 26 Mar 2007 20:39:24 +0200, Ralf Wildenhues said: Hi Charles, Thanks for the bug report. * Charles Wilson wrote on Fri, Mar 23, 2007 at 07:32:12AM CET: ../../libtool-HEAD/tests/subproject.at:56: $MAKE all $tst_dist + make all dist [...] mkdir: cannot create directory `/usr/src/libtool/cvs/_build/tests/testsuite.dir/33/subproject-demo-2.1a/sub/ltdl': File exists make[2]: *** [distdir] Error 1 AFAICS, this can only happen if libltdl was treated with automake-1.9 and the tests run with automake-1.10 in place, so that the toplevel package (named subproject-demo-2.1a) is treated with 1.10. I'm not so sure; I believe I first encountered the problem using 1.9.6 exclusively, but I will rebootstrap explicitly with (unpatched) 1.9 and make sure. Alexandre said he did not want to continue 1.9. That's what I thought. If I am right (above), then this is bad, and libtool/libltdl from HEAD/2.0 will require 1.10 (if one cares about the facilities tested by 33,34,35: subproject libltdl). I hope I'm wrong... -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [cygwin] Analysis for new testsuite failures 33,34.35
[EMAIL PROTECTED] wrote: On Mon, 26 Mar 2007 20:39:24 +0200, Ralf Wildenhues said: AFAICS, this can only happen if libltdl was treated with automake-1.9 and the tests run with automake-1.10 in place, so that the toplevel package (named subproject-demo-2.1a) is treated with 1.10. I'm not so sure; I believe I first encountered the problem using 1.9.6 exclusively, but I will rebootstrap explicitly with (unpatched) 1.9 and make sure. ... I hope I'm wrong... Fortunately, I was wrong. This change: http://sources.redhat.com/cgi-bin/cvsweb.cgi/automake/lib/am/distdir.am.diff?r1=1.63r2=1.64cvsroot=automakef=h has two parts; the behavior I observed was because I was getting one part of it, without the other -- exactly as Ralf surmised. After forcibly rebootstrapping[*] with 1.9.6, it worked fine. I don't believe there is any need to worry about patching 1.9.6/7 or requiring 1.10 -- this problem has an easy solution: if using libltdl as a subproject, ensure that you use the same version of automake there as in the project that contains it: 1.9 or 1.10 (earlier? dunno), just be consistent. -- Chuck [*] this is where cygwin's slightly overgrown autotools system works well: we have a gentoo-derived smart wrapper for automake, but ALSO use alternatives, for when you absolutely positively have to use a specific version, and the smart wrapper is acting a little too smart for its own good... automake - status is manual. link currently points to /usr/bin/automake-1.9 /usr/bin/automake-1.10 - priority 60 slave aclocal: /usr/bin/aclocal-1.10 slave automake-info: /usr/share/info/automake1.10.info.gz /usr/share/autotools/am-wrapper.sh - priority 100 slave aclocal: /usr/share/autotools/am-wrapper.sh slave automake-info: NONE /usr/bin/automake-1.4 - priority 10 slave aclocal: /usr/bin/aclocal-1.4 slave automake-info: NONE /usr/bin/automake-1.5 - priority 15 slave aclocal: /usr/bin/aclocal-1.5 slave automake-info: NONE /usr/bin/automake-1.6 - priority 20 slave aclocal: /usr/bin/aclocal-1.6 slave automake-info: NONE /usr/bin/automake-1.7 - priority 30 slave aclocal: /usr/bin/aclocal-1.7 slave automake-info: NONE /usr/bin/automake-1.8 - priority 40 slave aclocal: /usr/bin/aclocal-1.8 slave automake-info: NONE /usr/bin/automake-1.9 - priority 50 slave aclocal: /usr/bin/aclocal-1.9 slave automake-info: /usr/share/info/automake1.9.info.gz Current `best' version is /usr/share/autotools/am-wrapper.sh. ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: Support for VC++ toolchain (was Re: Absolute pathsgeneratedbylibtool.)
Olly Betts wrote: On 2006-11-28, Duft Markus [EMAIL PROTECTED] wrote: If you could tell me how i can bring outlook to do so, i will gladly ;o) Off-topic, but in the interests of improving the readability of this list (and others!): Outlook: http://home.in.tum.de/~jain/software/outlook-quotefix/ I'm using this, since late 2006 (since after this post), but Thanks anyways! Cheers, Markus Outlook Express: http://home.in.tum.de/~jain/software/oe-quotefix/ Or sign up for a gmail account - it handles lists pretty well. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
