Re: w32 pending?
Hey,
Now that libtool is released, i reply the questions below
This is the Warning: linker path does not have real file for library
-lole32. problem, right?
libole32.a and friends are all part of the Win32 API, and are installed
by a proper mingw64 native non-multilib toolchain in ${prefix}/lib IIRC
-- and that dir is included in the compiler/linker's search path
automatically.
What would really help is if you could look at your (failing) libtool
script, and see what 'sys_lib_search_path_spec' is set to
# Compile-time system search path for libraries.
sys_lib_search_path_spec=/home/torri/local/opt/mingw64/lib/gcc
/home/torri/local/opt/mingw64/x86_64-w64-mingw32/lib64
-- AND (a)
where libole32.a actually lives in your setup,
/home/torri/local/opt/mingw64/x86_64-w64-mingw32/lib/libole32.a
plus (b) what 'gcc
-print-search-dirs' reports (where, 'gcc' is the actual compiler,
whatever it is called, that you are using).
install: /home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/
programs:
=/home/torri/local/opt/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../libexec/gcc/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/bin/
libraries:
=/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../lib/gcc/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/lib/../lib64/:/buildslaves/mingw-w64/linux-x86-x86_64/build/build/root/mingw/lib/x86_64-w64-mingw32/4.5.2/:/buildslaves/mingw-w64/linux-x86-x86_64/build/build/root/mingw/lib/../lib64/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/lib/:/buildslaves/mingw-w64/linux-x86-x86_64/build/build/root/mingw/lib/
(*) I assume you're using a native non-multilib toolchain (you didn't
specify).
It's native (I use the linux version of the mingw-w64 toolchain). But I
don't know what multilib means :-)
thank you
Vincent Torri
[PATCH v2 01/11] maint: rearrange Makefile.am in preparation for a follow-up patch.
In case of doubt it might be easier to not try to change the actual dependency graph at all, but merely the rules, which should be enough to fix the problem you are targeting. Rather than try to build debians freebsd-buildutils on my mac, I decided to take the route of leaving the dependency graph alone. I also took the liberty of splitting the series up into much smaller pieces for easier review. The original 1/4 is off the table for now, 2/4 has been approved already, but it's still here below for completeness' sake. The original 4/4 is still the last patch in the series, so 3/4 is now spread out over the remainder, with commentary in each as appropriate. * Makefile.am (Libtool scripts.): Move this section below the `Bootstrap.' section... (libtoolize.in): ...except this one which is generated at bootstrap time, and was added into the `Bootstrap.' section. (Libltdl.): Move this section below the `Libtool scripts.' section. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog | 10 Makefile.am | 142 +- 2 files changed, 81 insertions(+), 71 deletions(-) diff --git a/ChangeLog b/ChangeLog index 647c151..818229f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2010-08-31 Gary V. Vaughan g...@gnu.org + + maint: rearrange Makefile.am in preparation for a follow-up patch. + * Makefile.am (Libtool scripts.): Move this section below the + `Bootstrap.' section... + (libtoolize.in): ...except this one which is generated at + bootstrap time, and was added into the `Bootstrap.' section. + (Libltdl.): Move this section below the `Libtool scripts.' + section. + 2010-09-22 Ralf Wildenhues ralf.wildenh...@gmx.de Fix regression in command-line length computation. diff --git a/Makefile.am b/Makefile.am index 6e29a29..dcb6d0d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -60,63 +60,21 @@ timestamp = set dummy `$(MKSTAMP) $(srcdir)`; shift; \ rebuild = rebuild=:; $(timestamp); correctver=$$1 -## ## -## Libtool scripts. ## -## ## - -# The libtool distributor and the standalone libtool script. -bin_SCRIPTS = libtoolize libtool - -libtoolize: $(srcdir)/libtoolize.in $(top_builddir)/config.status - rm -f libtoolize.tmp libtoolize - $(timestamp); \ - $(edit) -e s,@TIMESTAMP\@,$$TIMESTAMP,g \ - -e 's,@aclocal_DATA\@,$(aclocalfiles),g' \ - -e s,@pkgltdl_files\@,$(ltdldatafiles),g \ - -e s,@pkgconfig_files\@,$(auxfiles),g \ - $(srcdir)/libtoolize.in libtoolize.tmp - chmod a+x libtoolize.tmp - chmod a-w libtoolize.tmp - mv -f libtoolize.tmp libtoolize - -# Use `$(srcdir)' for the benefit of non-GNU makes: this is -# how libtoolize.in appears in our dependencies. -EXTRA_DIST += libtoolize.m4sh -$(srcdir)/libtoolize.in: $(sh_files) libtoolize.m4sh Makefile.am - cd $(srcdir); \ - rm -f libtoolize.in; \ - $(M4SH) -B $(auxdir) libtoolize.m4sh libtoolize.in - -# 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: $(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; \ - for prereq in $?; do \ - case $$prereq in *ChangeLog);; *) rebuild=:;; esac; \ - done; \ - 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) -...@dist_makefile_list@: - dir=`echo $@ | sed 's,^[^/]*$$,.,;s,/[^/]*$$,,'`; \ - test -d $$dir || mkdir $$dir || exit 1; \ - abs_srcdir=`$(lt__cd) $(srcdir) pwd`; \ - (cd $$dir $$abs_srcdir/$$dir/configure --with-dist) || exit 1 - - # -- # # Bootstrap. # # -- # +sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh +EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \ + $(auxdir)/mkstamp $(sh_files) \ + ChangeLog.1996 ChangeLog.1997 ChangeLog.1998 \ + ChangeLog.1999 ChangeLog.2000 ChangeLog.2001 \ + ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \ + ChangeLog.2005 ChangeLog.2006 ChangeLog.2007 \ + ChangeLog.2008 ChangeLog.2009 +CLEANFILES += libtool libtoolize libtoolize.tmp \ + $(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp + edit = sed \ -e 's,@EGREP\@,$(EGREP),g' \ -e 's,@FGREP\@,$(FGREP),g' \ @@ -138,17 +96,6 @@ edit = sed \ -e
[PATCH v2 03/11] build: compare `revision' rather than `correctver' in Makefile.am.
Split out of the original 3/4 patch. Not tested separately, but 3/4 passed make distcheck originally, and so does this series as a whole. Okay to push? * Makefile.am (rebuild): Set the shell variable `revision' rather than `correctver' for clarity of purpose. (bootstrap_edit, libltdl/config/ltmain.sh): Adjust. (libltdl/m4/ltversion.m4): Likewise, and alse, instead of munging the serial number comment line with set, extract `macro_version' from this file, and compare it directly with `revision'. (libtool): Likewise for `package_revision'. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog |9 + Makefile.am | 20 +--- 2 files changed, 18 insertions(+), 11 deletions(-) diff --git a/ChangeLog b/ChangeLog index d9f5cbd..a04ef73 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,14 @@ 2010-08-31 Gary V. Vaughan g...@gnu.org + build: compare `revision' rather than `correctver' in Makefile.am. + * Makefile.am (rebuild): Set the shell variable `revision' rather + than `correctver' for clarity of purpose. + (bootstrap_edit, libltdl/config/ltmain.sh): Adjust. + (libltdl/m4/ltversion.m4): Likewise, and alse, instead of munging + the serial number comment line with set, extract `macro_version' + from this file, and compare it directly with `revision'. + (libtool): Likewise for `package_revision'. + maint: don't leak developer GREP, SED etc into distribution file. * Makefile.am: Having rearranged the file, now apply the actual changes to follow-up. diff --git a/Makefile.am b/Makefile.am index 89189f1..abfd208 100644 --- a/Makefile.am +++ b/Makefile.am @@ -57,7 +57,7 @@ timestamp = set dummy `$(MKSTAMP) $(srcdir)`; shift; \ *) TIMESTAMP= ;; \ esac -rebuild = rebuild=:; $(timestamp); correctver=$$1 +rebuild = rebuild=:; $(timestamp); revision=$$1 # -- # @@ -80,13 +80,13 @@ CLEANFILES += libtool libtoolize libtoolize.tmp \ ## changed by configure running on the build machine. bootstrap_edit = sed \ -e 's,@MACRO_VERSION\@,$(VERSION),g' \ - -e s,@MACRO_REVISION\@,$$correctver,g \ + -e s,@MACRO_REVISION\@,$$revision,g \ -e s,@MACRO_SERIAL\@,$$serial,g \ -e 's,@PACKAGE\@,$(PACKAGE),g' \ -e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \ -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \ -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \ - -e s,@package_revision\@,$$correctver,g \ + -e s,@package_revision\@,$$revision,g \ -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \ -e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \ -e 's,@PACKAGE_VERSION\@,$(VERSION),g' \ @@ -107,9 +107,8 @@ EXTRA_DIST += $(m4dir)/ltversion.in $(srcdir)/$(m4dir)/ltversion.m4 $(srcdir)/$(m4dir)/ltversion.m4: $(m4dir)/ltversion.in configure.ac ChangeLog @target='$(srcdir)/$(m4dir)/ltversion.m4'; $(rebuild); \ if test -f $$target; then \ - set dummy `sed -n '/^# serial /p' $$target`; shift; \ - actualver=1.$$3; \ - test $$actualver = $$correctver rebuild=false; \ + eval `sed -n '/^macro_revision=/p' $(srcdir)/$(m4dir)/ltversion.m4`; \ + test $$macro_revision = $$revision rebuild=false; \ fi; \ for prereq in $?; do \ case $$prereq in *ChangeLog | *configure.ac);; *) rebuild=:;; esac; \ @@ -117,7 +116,7 @@ $(srcdir)/$(m4dir)/ltversion.m4: $(m4dir)/ltversion.in configure.ac ChangeLog if $$rebuild; then \ cd $(srcdir); \ rm -f $(m4dir)/ltversion.tmp; \ - serial=`echo $$correctver | sed 's,^1[.],,g'`; \ + serial=`echo $$revision | sed 's,^1[.],,g'`; \ echo $(bootstrap_edit) \ $(srcdir)/$(m4dir)/ltversion.in \ $(srcdir)/$(m4dir)/ltversion.m4; \ $(bootstrap_edit) \ @@ -141,8 +140,7 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files) $(auxdir)/ltmain.m4sh configure.ac Ch @target='$(srcdir)/$(auxdir)/ltmain.sh'; $(rebuild); \ if test -f $$target; then \ eval `sed -n '/^package_revision=/p' $$target`; \ - actualver=$$package_revision; \ - test $$actualver = $$correctver rebuild=false; \ + test $$package_revision = $$revision rebuild=false; \ fi; \ for prereq in $?; do \ case $$prereq in *ChangeLog);; *) rebuild=:;; esac; \ @@ -245,8 +243,8 @@ libtoolize: $(srcdir)/libtoolize.in $(top_builddir)/config.status libtool: $(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; \ + eval `sed -n '/^package_revision=/p' $$target`; \ + test
[PATCH v2 04/11] build: avoid unnecessary directory changes in Makefile rules.
The vast majority of this patch gets thrown away further in the
series. It's only really here to show separately how each of the
affected rules can be run perfectly well from the build tree... IIRC
I only wrote them this way originally as a short hand for retyping
all those long paths... but they are whittled away by the next few
patches anyway.
Okay to push?
* Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.m4sh)
(libtoolize.in, libltdl/Makefile.am, libltdl/config/mkstamp)
(tests/testsuite, tests/defs.in): Avoid unnecessary `cd' commands
by using fully qualified paths to files outside of current
directory.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
ChangeLog |7 +++
Makefile.am | 53 +++--
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a04ef73..20599a6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
2010-08-31 Gary V. Vaughan g...@gnu.org
+ build: avoid unnecessary directory changes in Makefile rules.
+ * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.m4sh)
+ (libtoolize.in, libltdl/Makefile.am, libltdl/config/mkstamp)
+ (tests/testsuite, tests/defs.in): Avoid unnecessary `cd' commands
+ by using fully qualified paths to files outside of current
+ directory.
+
build: compare `revision' rather than `correctver' in Makefile.am.
* Makefile.am (rebuild): Set the shell variable `revision' rather
than `correctver' for clarity of purpose.
diff --git a/Makefile.am b/Makefile.am
index abfd208..64db1b9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -114,15 +114,14 @@ $(srcdir)/$(m4dir)/ltversion.m4: $(m4dir)/ltversion.in
configure.ac ChangeLog
case $$prereq in *ChangeLog | *configure.ac);; *) rebuild=:;; esac; \
done; \
if $$rebuild; then \
- cd $(srcdir); \
- rm -f $(m4dir)/ltversion.tmp; \
+ rm -f $(srcdir)/$(m4dir)/ltversion.tmp; \
serial=`echo $$revision | sed 's,^1[.],,g'`; \
echo $(bootstrap_edit) \
$(srcdir)/$(m4dir)/ltversion.in \ $(srcdir)/$(m4dir)/ltversion.m4;
\
$(bootstrap_edit) \
- $(m4dir)/ltversion.in $(m4dir)/ltversion.tmp; \
- chmod a-w $(m4dir)/ltversion.tmp; \
- mv -f $(m4dir)/ltversion.tmp $(m4dir)/ltversion.m4; \
+ $(srcdir)/$(m4dir)/ltversion.in
$(srcdir)/$(m4dir)/ltversion.tmp; \
+ chmod a-w $(srcdir)/$(m4dir)/ltversion.tmp; \
+ mv -f $(srcdir)/$(m4dir)/ltversion.tmp
$(srcdir)/$(m4dir)/ltversion.m4; \
fi
## And for similar reasons, ltmain.sh can't be built from config.status.
@@ -146,33 +145,30 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files)
$(auxdir)/ltmain.m4sh configure.ac Ch
case $$prereq in *ChangeLog);; *) rebuild=:;; esac; \
done; \
if $$rebuild; then \
- cd $(srcdir); \
- rm -f $(auxdir)/ltmain.in $(auxdir)/ltmain.tmp \
- $(auxdir)/ltmain.sh; \
- echo $(M4SH) -B $(auxdir) $(auxdir)/ltmain.m4sh \
- \ $(auxdir)/ltmain.in; \
- $(M4SH) -B $(auxdir) $(auxdir)/ltmain.m4sh \
-$(auxdir)/ltmain.in; \
+ rm -f $(srcdir)/$(auxdir)/ltmain.in $(srcdir)/$(auxdir)/ltmain.tmp \
+ $(srcdir)/$(auxdir)/ltmain.sh; \
+ echo $(M4SH) -B $(srcdir)/$(auxdir) $(srcdir)/$(auxdir)/ltmain.m4sh \
+ \ $(srcdir)/$(auxdir)/ltmain.in; \
+ $(M4SH) -B $(srcdir)/$(auxdir) $(srcdir)/$(auxdir)/ltmain.m4sh \
+$(srcdir)/$(auxdir)/ltmain.in; \
echo $(bootstrap_edit) \
$(srcdir)/$(auxdir)/ltmain.in $$target; \
$(bootstrap_edit) \
- $(auxdir)/ltmain.in $(auxdir)/ltmain.tmp; \
- rm -f $(auxdir)/ltmain.in; \
- chmod a-w $(auxdir)/ltmain.tmp; \
- mv -f $(auxdir)/ltmain.tmp $(auxdir)/ltmain.sh; \
+ $(srcdir)/$(auxdir)/ltmain.in $(srcdir)/$(auxdir)/ltmain.tmp;
\
+ rm -f $(srcdir)/$(auxdir)/ltmain.in; \
+ chmod a-w $(srcdir)/$(auxdir)/ltmain.tmp; \
+ mv -f $(srcdir)/$(auxdir)/ltmain.tmp $(srcdir)/$(auxdir)/ltmain.sh; \
fi
# Use `$(srcdir)' for the benefit of non-GNU makes: this is
# how libtoolize.in appears in our dependencies.
EXTRA_DIST += libtoolize.m4sh
$(srcdir)/libtoolize.in: $(sh_files) libtoolize.m4sh Makefile.am
- cd $(srcdir); \
- rm -f libtoolize.in; \
- $(M4SH) -B $(auxdir) libtoolize.m4sh libtoolize.in
+ rm -f $(srcdir)/libtoolize.in
+ $(M4SH) -B $(srcdir)/$(auxdir) $(srcdir)/libtoolize.m4sh
$(srcdir)/libtoolize.in
$(srcdir)/libltdl/Makefile.am: $(srcdir)/libltdl/Makefile.inc
- cd $(srcdir); \
- in=libltdl/Makefile.inc; out=libltdl/Makefile.am; \
+ in=$(srcdir)/libltdl/Makefile.inc; out=$(srcdir)/libltdl/Makefile.am; \
rm -f $$out; \
( $(SED) -n '1,/^.. DO NOT REMOVE THIS LINE -- /p' $$in; \
{ echo
[PATCH v2 06/11] build: name temporary files in `Makefile.am' consistently.
This is another silly patch that ends up being mostly edited away by the next couple of patches in the series... but I think it's useful to split it out so that you can see what I'm thinking at each stage. It was also a good exercise because after splitting, I realised that the original 3/4 didn't apply this concept in all the places it could have. Okay to push? * Makefile.am (libltdl/m4/ltversion.m4): Rename temporary file to `ltversion.m4T'. (libltdl/config/ltmain.sh): Rename temporary file to `ltmain.shT'. (libtoolize): Rename temporary file to `libtoolizeT'. (tests/defs): Rename temporary file to `defsT' (tests/testsuite): Rename temporary file to `testsuiteT'. (CLEANFILES): Adjust and add `tests/defsT' and `tests/testsuiteT'. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog |9 + Makefile.am | 41 + 2 files changed, 30 insertions(+), 20 deletions(-) diff --git a/ChangeLog b/ChangeLog index f812d1d..f26e65b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,14 @@ 2010-08-31 Gary V. Vaughan g...@gnu.org + build: name temporary files in `Makefile.am' consistently. + * Makefile.am (libltdl/m4/ltversion.m4): Rename temporary file + to `ltversion.m4T'. + (libltdl/config/ltmain.sh): Rename temporary file to `ltmain.shT'. + (libtoolize): Rename temporary file to `libtoolizeT'. + (tests/defs): Rename temporary file to `defsT' + (tests/testsuite): Rename temporary file to `testsuiteT'. + (CLEANFILES): Adjust and add `tests/defsT' and `tests/testsuiteT'. + build: factor Makefile.am `m4sh' invocations to LT_M4SH. * Makefile.am (LT_M4SH): Now that all directories are listed as fully qualified paths, the search path argument to M4SH is always diff --git a/Makefile.am b/Makefile.am index 0f5cd52..9143350 100644 --- a/Makefile.am +++ b/Makefile.am @@ -74,8 +74,9 @@ EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \ ChangeLog.2002 ChangeLog.2003 ChangeLog.2004 \ ChangeLog.2005 ChangeLog.2006 ChangeLog.2007 \ ChangeLog.2008 ChangeLog.2009 -CLEANFILES += libtool libtoolize libtoolize.tmp \ - $(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp +CLEANFILES += libtool libtoolize libtoolizeT \ + tests/defsT tests/testsuitT \ + $(auxdir)/ltmain.shT $(m4dir)/ltversion.m4T ## These are the replacements that need to be made at bootstrap time, ## because they must be static in distributed files, and not accidentally @@ -116,14 +117,14 @@ $(srcdir)/$(m4dir)/ltversion.m4: $(m4dir)/ltversion.in configure.ac ChangeLog case $$prereq in *ChangeLog | *configure.ac);; *) rebuild=:;; esac; \ done; \ if $$rebuild; then \ - rm -f $(srcdir)/$(m4dir)/ltversion.tmp; \ + rm -f $(srcdir)/$(m4dir)/ltversion.m4T; \ serial=`echo $$revision | sed 's,^1[.],,g'`; \ echo $(bootstrap_edit) \ $(srcdir)/$(m4dir)/ltversion.in \ $(srcdir)/$(m4dir)/ltversion.m4; \ $(bootstrap_edit) \ - $(srcdir)/$(m4dir)/ltversion.in $(srcdir)/$(m4dir)/ltversion.tmp; \ - chmod a-w $(srcdir)/$(m4dir)/ltversion.tmp; \ - mv -f $(srcdir)/$(m4dir)/ltversion.tmp $(srcdir)/$(m4dir)/ltversion.m4; \ + $(srcdir)/$(m4dir)/ltversion.in $(srcdir)/$(m4dir)/ltversion.m4T; \ + chmod a-w $(srcdir)/$(m4dir)/ltversion.m4T; \ + mv -f $(srcdir)/$(m4dir)/ltversion.m4T $(srcdir)/$(m4dir)/ltversion.m4; \ fi ## And for similar reasons, ltmain.sh can't be built from config.status. @@ -147,7 +148,7 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files) $(auxdir)/ltmain.m4sh configure.ac Ch case $$prereq in *ChangeLog);; *) rebuild=:;; esac; \ done; \ if $$rebuild; then \ - rm -f $(srcdir)/$(auxdir)/ltmain.in $(srcdir)/$(auxdir)/ltmain.tmp \ + rm -f $(srcdir)/$(auxdir)/ltmain.in $(srcdir)/$(auxdir)/ltmain.shT \ $(srcdir)/$(auxdir)/ltmain.sh; \ echo $(LT_M4SH) $(srcdir)/$(auxdir)/ltmain.m4sh \ \ $(srcdir)/$(auxdir)/ltmain.in; \ @@ -156,10 +157,10 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files) $(auxdir)/ltmain.m4sh configure.ac Ch echo $(bootstrap_edit) \ $(srcdir)/$(auxdir)/ltmain.in $$target; \ $(bootstrap_edit) \ - $(srcdir)/$(auxdir)/ltmain.in $(srcdir)/$(auxdir)/ltmain.tmp; \ + $(srcdir)/$(auxdir)/ltmain.in $(srcdir)/$(auxdir)/ltmain.shT; \ rm -f $(srcdir)/$(auxdir)/ltmain.in; \ - chmod a-w $(srcdir)/$(auxdir)/ltmain.tmp; \ - mv -f $(srcdir)/$(auxdir)/ltmain.tmp $(srcdir)/$(auxdir)/ltmain.sh; \ + chmod a-w $(srcdir)/$(auxdir)/ltmain.shT; \ + mv -f $(srcdir)/$(auxdir)/ltmain.shT $(srcdir)/$(auxdir)/ltmain.sh; \ fi # Use `$(srcdir)' for the benefit of non-GNU makes: this is @@
[PATCH v2 11/11] maint: simplify and improve safety of bootstrap process.
This is the original 4/4 patch, unchanged from last time. It still passes `make distcheck' from a clean checkout and build on my mac. Assuming strongly that this patch depends upon the semantics of 3/4 applied, I will review this patch after 3/4 is fixed I haven't actually tried it separately, but I expect it will still work even with the current master Makefile.am. Even so, I'd rather push these in the order I've tested them. Okay to push? * Makefile.am (bootstrap_files): List files that need to be generated at bootstrap time before `./configure make' can work. It turns out that this is considerably fewer files than we had thought necessary previously. (bootstrap-deps-prep): Ensure minimum set of required substitution variables are non-empty. (bootstrap-deps): Depend on `bootstrap' files. * bootstrap (Generate bootstrap dependencies): Now that `Makefile.am' is entirely responsible for rebuilding files at bootstrap time, we need only specify the new `bootstrap-deps' target, and supply values for the substitutions checked by `bootstrap-deps-prep'. * configure.ac (AC_CONFIG_SRCDIR): `libtoolize.in' is not here yet right after running `bootstrap'. So rely on the presence of `libltdl/config/libtoolize.m4sh', which is always there. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog| 19 +++ Makefile.am | 41 + bootstrap| 17 - configure.ac |2 +- 4 files changed, 65 insertions(+), 14 deletions(-) diff --git a/ChangeLog b/ChangeLog index e478899..de9d2c0 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,22 @@ +2010-08-30 Gary V. Vaughan g...@gnu.org + + maint: simplify and improve safety of bootstrap process. + * Makefile.am (bootstrap_files): List files that need to be + generated at bootstrap time before `./configure make' can + work. It turns out that this is considerably fewer files than we + had thought necessary previously. + (bootstrap-deps-prep): Ensure minimum set of required substitution + variables are non-empty. + (bootstrap-deps): Depend on `bootstrap' files. + * bootstrap (Generate bootstrap dependencies): Now that + `Makefile.am' is entirely responsible for rebuilding files at + bootstrap time, we need only specify the new `bootstrap-deps' + target, and supply values for the substitutions checked by + `bootstrap-deps-prep'. + * configure.ac (AC_CONFIG_SRCDIR): `libtoolize.in' is not here yet + right after running `bootstrap'. So rely on the presence of + `libtoolize.m4sh', which is always there. + 2010-08-31 Gary V. Vaughan g...@gnu.org build: eliminate superfluous temporary files from `Makefile.am'. diff --git a/Makefile.am b/Makefile.am index 5d84b2c..54d5674 100644 --- a/Makefile.am +++ b/Makefile.am @@ -182,6 +182,47 @@ $(srcdir)/libltdl/Makefile.am: $(srcdir)/libltdl/Makefile.inc -e '1s,^\(.. Makefile.\)inc.*,\1am -- Process this file with automake to produce Makefile.in,' $@ chmod a-w $@ +## Document the make macros that are needed to build bootstrap-deps +## dependencies when called from `bootstrap' (developer's machine), +## where the Makefile.am is fed to make in its raw format before +## `configure' has found the correct values (on the build machine). +bootstrap_files = \ +$(auxdir)/ltmain.sh \ +$(m4dir)/ltversion.m4 \ +libltdl/Makefile.am + +.PHONY: bootstrap-deps bootstrap-deps-prep +bootstrap-deps: bootstrap-deps-prep $(bootstrap_files) +bootstrap-deps-prep: +## The following variables are substituted by `bootstrap-dep-preps' + @exit_cmd=:; \ + test -z $(srcdir) \ +echo ERROR: don't call $(MAKE) with srcdir unset. \ +exit_cmd=exit; \ + test -z $(M4SH) \ +echo ERROR: don't call $(MAKE) with M4SH unset. \ +exit_cmd=exit; \ + test -z $(PACKAGE) \ +echo ERROR: don't call $(MAKE) with PACKAGE unset. \ +exit_cmd=exit; \ + test -z $(PACKAGE_BUGREPORT) \ +echo ERROR: don't call $(MAKE) with PACKAGE_BUGREPORT unset. \ +exit_cmd=exit; \ + test -z $(PACKAGE_NAME) \ +echo ERROR: don't call $(MAKE) with PACKAGE_NAME unset. \ +exit_cmd=exit; \ + test -z $(PACKAGE_URL) \ +echo ERROR: don't call $(MAKE) with PACKAGE_URL unset. \ +exit_cmd=exit; \ + test -z $(SED) \ +echo ERROR: don't call $(MAKE) with SED unset. \ +exit_cmd=exit; \ + test -z $(VERSION) \ +echo ERROR: don't call $(MAKE) with VERSION unset. \ +exit_cmd=exit; \ + $$exit_cmd 1 + rm -f $(bootstrap_files) + ## Unfortunately, all this bogeyness means that we have to manually ## keep the generated files in libltdl up to date. diff --git a/bootstrap b/bootstrap index 78b4d30..e66b151 100755 --- a/bootstrap +++ b/bootstrap
[PATCH v2 05/11] build: factor Makefile.am `m4sh' invocations to LT_M4SH.
Another patch factored from the original 3/4. This is the first
readability improvement to the rules that got lengthier in the
last patch... now that the groundwork is done.
I did run a build and minimal testing (as I described earlier in
this series) from a clean tree without problems at this stage.
Okay to push?
* Makefile.am (LT_M4SH): Now that all directories are listed as
fully qualified paths, the search path argument to M4SH is always
the same, so factor it out into a variable. Adjust all callers.
Signed-off-by: Gary V. Vaughan g...@gnu.org
---
ChangeLog |5 +
Makefile.am | 10 ++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 20599a6..f812d1d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2010-08-31 Gary V. Vaughan g...@gnu.org
+ build: factor Makefile.am `m4sh' invocations to LT_M4SH.
+ * Makefile.am (LT_M4SH): Now that all directories are listed as
+ fully qualified paths, the search path argument to M4SH is always
+ the same, so factor it out into a variable. Adjust all callers.
+
build: avoid unnecessary directory changes in Makefile rules.
* Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.m4sh)
(libtoolize.in, libltdl/Makefile.am, libltdl/config/mkstamp)
diff --git a/Makefile.am b/Makefile.am
index 64db1b9..0f5cd52 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -46,6 +46,8 @@ EXTRA_LTLIBRARIES =
auxdir = libltdl/config
m4dir = libltdl/m4
+LT_M4SH= $(M4SH) -B $(srcdir)/$(auxdir)
+
# Using `cd' in backquotes may print the directory name, use this instead:
lt__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR) cd
@@ -147,9 +149,9 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files)
$(auxdir)/ltmain.m4sh configure.ac Ch
if $$rebuild; then \
rm -f $(srcdir)/$(auxdir)/ltmain.in $(srcdir)/$(auxdir)/ltmain.tmp \
$(srcdir)/$(auxdir)/ltmain.sh; \
- echo $(M4SH) -B $(srcdir)/$(auxdir) $(srcdir)/$(auxdir)/ltmain.m4sh \
+ echo $(LT_M4SH) $(srcdir)/$(auxdir)/ltmain.m4sh \
\ $(srcdir)/$(auxdir)/ltmain.in; \
- $(M4SH) -B $(srcdir)/$(auxdir) $(srcdir)/$(auxdir)/ltmain.m4sh \
+ $(LT_M4SH) $(srcdir)/$(auxdir)/ltmain.m4sh \
$(srcdir)/$(auxdir)/ltmain.in; \
echo $(bootstrap_edit) \
$(srcdir)/$(auxdir)/ltmain.in $$target; \
@@ -165,7 +167,7 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files)
$(auxdir)/ltmain.m4sh configure.ac Ch
EXTRA_DIST += libtoolize.m4sh
$(srcdir)/libtoolize.in: $(sh_files) libtoolize.m4sh Makefile.am
rm -f $(srcdir)/libtoolize.in
- $(M4SH) -B $(srcdir)/$(auxdir) $(srcdir)/libtoolize.m4sh
$(srcdir)/libtoolize.in
+ $(LT_M4SH) $(srcdir)/libtoolize.m4sh $(srcdir)/libtoolize.in
$(srcdir)/libltdl/Makefile.am: $(srcdir)/libltdl/Makefile.inc
in=$(srcdir)/libltdl/Makefile.inc; out=$(srcdir)/libltdl/Makefile.am; \
@@ -900,7 +902,7 @@ tests/defs: $(srcdir)/tests/defs.in
# how defs.in appears in our dependencies.
$(srcdir)/tests/defs.in: $(auxdir)/general.m4sh tests/defs.m4sh Makefile.am
rm -f $(srcdir)/tests/defs.in; \
- $(M4SH) -B $(srcdir)/$(auxdir) $(srcdir)/tests/defs.m4sh
$(srcdir)/tests/defs.in
+ $(LT_M4SH) $(srcdir)/tests/defs.m4sh $(srcdir)/tests/defs.in
# We need to remove any files that the above tests created.
clean-local-legacy:
--
1.7.3
[PATCH v2 08/11] build: don't hardcode repeated long paths in Makefile rules.
The few remaining cases where I would have liked to use $, instead of writing it out long-hand relative to the build tree more than once, I've stored it in a shell variable and referenced that. There are another couple of instances that don't show in this patch where there was only a single $ required, in which case I just typed the path out longhand as you suggested. Okay to push? * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh): Use sed to calculate input file names from $@. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog |4 Makefile.am | 21 +++-- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/ChangeLog b/ChangeLog index 85ac802..d923588 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2010-08-31 Gary V. Vaughan g...@gnu.org + build: don't hardcode repeated long paths in Makefile rules. + * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh): + Use sed to calculate input file names from $@. + build: make better use of automatic variables in `Makefile.am'. * Makefile.am (libtoolize, libtoolize.in, libltdl/Makefile.am) (libltdl/config/mkstamp, libltdl/config/ltmain.m4sh) diff --git a/Makefile.am b/Makefile.am index 32b192c..90cd671 100644 --- a/Makefile.am +++ b/Makefile.am @@ -118,9 +118,10 @@ $(srcdir)/$(m4dir)/ltversion.m4: $(m4dir)/ltversion.in configure.ac ChangeLog done; \ if $$rebuild; then \ rm -f $...@t; \ + in=`echo $@ | sed 's:\.m4$$:.in:'`; \ serial=`echo $$revision | sed 's,^1[.],,g'`; \ - echo $(bootstrap_edit) $(srcdir)/$(m4dir)/ltversion.in $@; \ - $(bootstrap_edit) $(srcdir)/$(m4dir)/ltversion.in $...@t; \ + echo $(bootstrap_edit) $$in $@; \ + $(bootstrap_edit) $$in $...@t; \ chmod a-w $...@t; \ mv -f $...@t $@; \ fi @@ -146,14 +147,14 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files) $(auxdir)/ltmain.m4sh configure.ac Ch case $$prereq in *ChangeLog);; *) rebuild=:;; esac; \ done; \ if $$rebuild; then \ - rm -f $(srcdir)/$(auxdir)/ltmain.in $...@t $@; \ - echo $(LT_M4SH) $(srcdir)/$(auxdir)/ltmain.m4sh \ - \ $(srcdir)/$(auxdir)/ltmain.in; \ - $(LT_M4SH) $(srcdir)/$(auxdir)/ltmain.m4sh \ -$(srcdir)/$(auxdir)/ltmain.in; \ - echo $(bootstrap_edit) $(srcdir)/$(auxdir)/ltmain.in $@; \ - $(bootstrap_edit) $(srcdir)/$(auxdir)/ltmain.in $...@t; \ - rm -f $(srcdir)/$(auxdir)/ltmain.in; \ + in=`echo $@ | sed 's:\.sh$$:.m4sh:'`; \ + intermediate=`echo $@ | sed 's:\.sh$$:.in'`; \ + rm -f $$intermediate $...@t $@; \ + echo $(LT_M4SH) $$in $$intermediate; \ + $(LT_M4SH) $$in $$intermediate; \ + echo $(bootstrap_edit) $$intermediate $@; \ + $(bootstrap_edit) $$intermediate $...@t; \ + rm -f $$intermediate; \ chmod a-w $...@t; \ mv -f $...@t $@; \ fi -- 1.7.3
[PATCH v2 09/11] build: eliminate `ltmain.in' intermediate file.
Factored out of the origin 3/4 patch. Okay to push? * Makefile.am (libltdl/config/ltmain.sh): Pipe the output of `$(LT_M4SH)' directly into `$(bootstrap_edit)' to avoid use of superfluous intermediate file. Signed-off-by: Gary V. Vaughan g...@gnu.org --- ChangeLog |5 + Makefile.am | 12 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/ChangeLog b/ChangeLog index d923588..ba2c3a5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2010-08-31 Gary V. Vaughan g...@gnu.org + build: eliminate `ltmain.in' intermediate file. + * Makefile.am (libltdl/config/ltmain.sh): Pipe the output of + `$(LT_M4SH)' directly into `$(bootstrap_edit)' to avoid use + of superfluous intermediate file. + build: don't hardcode repeated long paths in Makefile rules. * Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh): Use sed to calculate input file names from $@. diff --git a/Makefile.am b/Makefile.am index 90cd671..16e1a69 100644 --- a/Makefile.am +++ b/Makefile.am @@ -131,7 +131,7 @@ $(srcdir)/$(m4dir)/ltversion.m4: $(m4dir)/ltversion.in configure.ac ChangeLog ## would rerun configure on every invocation, so now we manually ## check the version numbers from the build rule when necessary. ## !WARNING! If you edit this rule to change the contents of ltmain.sh, -## you must `touch $(srcdir)/$(auxdir)/ltmain.in' from the +## you must `touch $(srcdir)/$(auxdir)/ltmain.m4sh' from the ## shell if you need ltmain.sh to be regenerated. Ideally, we ## should make this rule depend on Makefile but that will break ## distcheck (at least) by rebuilding ltmain.sh in the source @@ -148,13 +148,9 @@ $(srcdir)/$(auxdir)/ltmain.sh: $(sh_files) $(auxdir)/ltmain.m4sh configure.ac Ch done; \ if $$rebuild; then \ in=`echo $@ | sed 's:\.sh$$:.m4sh:'`; \ - intermediate=`echo $@ | sed 's:\.sh$$:.in'`; \ - rm -f $$intermediate $...@t $@; \ - echo $(LT_M4SH) $$in $$intermediate; \ - $(LT_M4SH) $$in $$intermediate; \ - echo $(bootstrap_edit) $$intermediate $@; \ - $(bootstrap_edit) $$intermediate $...@t; \ - rm -f $$intermediate; \ + rm -f $...@t $@; \ + echo $(LT_M4SH) $$in | $(bootstrap_edit) $@; \ + $(LT_M4SH) $$in | $(bootstrap_edit) $...@t; \ chmod a-w $...@t; \ mv -f $...@t $@; \ fi -- 1.7.3
Re: [PATCH v2 02/11] maint: don't leak developer GREP, SED etc into distribution file.
typu ahead... On 23 Sep 2010, at 22:21, Gary V. Vaughan wrote: I'm torn between running our own minimal substitution to fill the values in from libtool.m4, or having the make rule for libtool just edit them out. Thoughts? Of course, I mean the rule for ltmain.sh could edit them out as it generates ltmain.sh. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH v2 02/11] maint: don't leak developer GREP, SED etc into distribution file.
Hello Gary,
* Gary V. Vaughan wrote on Thu, Sep 23, 2010 at 05:21:19PM CEST:
I've pared this down to the absolute minimum necessary to fix the
bug it is targetting. I did run this through `make distcheck' (and
it passed), but most of the others following only got a cursory
`git clean -x -d -f ./bootstrap ./configure ./make all
check TESTS=tests/sh.test TESTSUITEFLAGS=1' unless noted otherwise.
Did you look at the output of the cursory check? Like, after this
patch, I get this in the output:
## ##
## @PACKAGE_STRING@ test suite. ##
## ##
See below for an explanation.
With this patch applied, the generated libtool script still contains
the following lines:
: ${EGREP=@EGREP@}
: ${FGREP=@FGREP@}
: ${GREP=@GREP@}
: ${LN_S=@LN_S@}
[...]
: ${SED=@SED@}
Now, the lines are all ineffective, because the tag variables (which
will be expanded before these lines) will set all of these variables.
Kind of ugly, but alright if you prefer to clean that up later.
Oh! I'd forgotten that AC_INIT_COMMANDS don't get run through the
AC_SUBST machinery :(
Unfortunately, I cannot parse this statement. What does
AC_INIT_COMMANDS have to do with these lines which come from
general.m4sh originally?
I'd like to tackle that separately. Unfortunately those settings
come from general.m4sh boilerplate and are required by libtoolize, so
it's not entirely straight forward.
Agreed.
I'm torn between running our
own minimal substitution to fill the values in from libtool.m4, or
having the make rule for libtool just edit them out. Thoughts?
Editing them out is fine. Again, fixing this later is fine with me,
too.
Okay to push this one now?
It is still not quite correct. See below.
* Makefile.am: Having rearranged the file, now apply the actual
changes to follow-up.
(edit): Split into two parts...
(bootstrap_edit): ...substitutions that should happen at bootstrap
time...
(configure_edit): ...and substitutions that should not happen until
configure time.
* Makefile.am (libltdl/m4/ltversion.m4, libltdl/config/ltmain.sh)
(libtoolize.in): Use bootstrap_edit.
This log line is not reflected in the patch contents. And in fact, with
the patch applied, the generated libtoolize script still has
untransformed strings:
$ head libtoolize | sed 's/^/| '
| #! /bin/sh
| # Generated from libtoolize.m4sh by GNU Autoconf 2.68.
|
| # libtoolize (GNU @PACKAGE@@TIMESTAMP@) @VERSION@
[...]
(libtoolize, tests/package.m4): Use configure_edit.
For tests/package.m4, this is the wrong thing to do; see below.
* HACKING (Release Procedure): Remove the note to workaround the
bug fixed by this changeset.
* NEWS (Bug fixes): Mention that this bug is now fixed.
Reported by Joerg Sonnenberger.
--- a/Makefile.am
+++ b/Makefile.am
@@ -75,26 +75,23 @@ EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in
$(auxdir)/ltmain.m4sh \
CLEANFILES += libtool libtoolize libtoolize.tmp \
$(auxdir)/ltmain.tmp $(m4dir)/ltversion.tmp
-edit = sed \
- -e 's,@EGREP\@,$(EGREP),g' \
- -e 's,@FGREP\@,$(FGREP),g' \
- -e 's,@GREP\@,$(GREP),g' \
- -e 's,@LN_S\@,$(LN_S),g' \
- -e 's,@MACRO_VERSION\@,$(VERSION),g' \
- -e 's,@PACKAGE\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \
- -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \
- -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \
- -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \
- -e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \
- -e 's,@PACKAGE_VERSION\@,$(VERSION),g' \
- -e 's,@SED\@,$(SED),g' \
- -e 's,@VERSION\@,$(VERSION),g' \
- -e 's,@aclocaldir\@,$(aclocaldir),g' \
- -e 's,@datadir\@,$(datadir),g' \
- -e 's,@pkgdatadir\@,$(pkgdatadir),g' \
- -e 's,@host_triplet\@,$(host_triplet),g' \
- -e 's,@prefix\@,$(prefix),g'
+## These are the replacements that need to be made at bootstrap time,
+## because they must be static in distributed files, and not accidentally
+## changed by configure running on the build machine.
+bootstrap_edit = sed \
+ -e 's,@MACRO_VERSION\@,$(VERSION),g' \
+ -e s,@MACRO_REVISION\@,$$correctver,g \
+ -e s,@MACRO_SERIAL\@,$$serial,g \
+ -e 's,@PACKAGE\@,$(PACKAGE),g' \
+ -e 's,@PACKAGE_BUGREPORT\@,$(PACKAGE_BUGREPORT),g' \
+ -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \
+ -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \
+ -e s,@package_revision\@,$$correctver,g \
+ -e 's,@PACKAGE_STRING\@,$(PACKAGE_NAME) $(VERSION),g' \
+ -e 's,@PACKAGE_TARNAME\@,$(PACKAGE),g' \
+ -e 's,@PACKAGE_VERSION\@,$(VERSION),g' \
+ -e s,@TIMESTAMP\@,$$TIMESTAMP,g \
+ -e 's,@VERSION\@,$(VERSION),g'
## We build ltversion.m4 here, instead of from config.status,
## because config.status
Re: [PATCH v2 07/11] build: make better use of automatic variables in `Makefile.am'.
Hi Gary, this isn't a review, I'm just adding a couple of hints that come to mind at first glance. * Gary V. Vaughan wrote on Thu, Sep 23, 2010 at 05:21:24PM CEST: Rules are getting shorter and more readable again now. I'm assuming there are no portability problems with $@ and $^ in regular rules? $@ is portable. $^ is not portable. These things are all documented. Here's the Posix page for make: http://www.opengroup.org/onlinepubs/9699919799/utilities/make.html here are the Autoconf manual sections about portable make: http://www.gnu.org/software/autoconf/manual/html_node/Portable-Make.html If there are, at least keeping this change in a separate patch makes it easy enough to omit or amend. Thanks. Please amend and resubmit, I will review then. Now that these rules are all executing from the build tree, there's no need to manually check all the paths match the current directory, or keep long hand-typed duplicate paths scattered around. We can use $@ (and $^ in some places) knowing that they're still correct when we've stayed in the same directory they were calculated for. Okay to push? * Makefile.am (libtoolize, libtoolize.in, libltdl/Makefile.am) (libltdl/config/mkstamp, libltdl/config/ltmain.m4sh) (libltdl/m4/ltversion.m4, tests/testsuite,.tests/defs.in): Make better use of automatic variables. Cheers, Ralf
[PATCH] tests: import variables for MSVC.
Hi! This is a repost of an old patch. Ralf said a long time ago that I should drop the fixes for the old testsuite, but since I'm short of problems in the new testsuite and the old one isn't going away, I'm revisiting this. This was first posted here as part of a much bigger patch: http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00033.html Ralf didn't like it here: http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00069.html Some words from me on the subject: http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00076.html I don't know how to set up the defines so that EXTERN becomes 1. extern when you use a static library 2. extern when you build a static library 3. extern declspec(dllimport) when you use a shared library 4. extern declspec(dllexport) when you build a shared library I could fix 2 and 4, but separating 1 and 3 is not possible. Since extern declspec(dllimport) works everywhere with MSVC I'm taking the easy option with this patch. Or should I add -DBUILDING_FOO to Makefile.am and variations of the below to the code? #ifdef _MSC_VER # ifdef BUILDING_FOO # ifdef DLL_EXPORT # define EXTERN extern declspec(dllexport) # endif # else # define EXTERN extern declspec(dllimport) # endif #endif #ifndef EXTERN # define EXTERN extern #endif Cheers, Peter From 044c0e8de4c98da753e7b17d87f03c8eebe2bcbe Mon Sep 17 00:00:00 2001 From: Peter Rosin p...@lysator.liu.se Date: Thu, 23 Sep 2010 22:55:04 +0200 Subject: [PATCH] tests: import variables for MSVC. * tests/depdemo/sysdep.h (EXTERN): New define, saying how to declare variables that might need to be imported. * tests/depdemo/l1/l1.h, tests/depdemo/l2/l2.h, tests/depdemo/l3/l3.h, tests/depdemo/l4/l4.h: Use it. * tests/demo/foo.h (EXTERN): New define, saying how to declare variables that might need to be imported. Use it. * tests/pdemo/foo.h (EXTERN) [MSVC]: Make MSVC import variables if needed. Signed-off-by: Peter Rosin p...@lysator.liu.se --- ChangeLog | 12 tests/demo/foo.h |8 +++- tests/depdemo/l1/l1.h |2 +- tests/depdemo/l2/l2.h |2 +- tests/depdemo/l3/l3.h |2 +- tests/depdemo/l4/l4.h |2 +- tests/depdemo/sysdep.h |6 ++ tests/pdemo/foo.h |2 ++ 8 files changed, 31 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index 647c151..af99b0c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2010-09-23 Peter Rosin p...@lysator.liu.se + + tests: import variables for MSVC. + * tests/depdemo/sysdep.h (EXTERN): New define, saying how to + declare variables that might need to be imported. + * tests/depdemo/l1/l1.h, tests/depdemo/l2/l2.h, + tests/depdemo/l3/l3.h, tests/depdemo/l4/l4.h: Use it. + * tests/demo/foo.h (EXTERN): New define, saying how to declare + variables that might need to be imported. Use it. + * tests/pdemo/foo.h (EXTERN) [MSVC]: Make MSVC import variables + if needed. + 2010-09-22 Ralf Wildenhues ralf.wildenh...@gmx.de Fix regression in command-line length computation. diff --git a/tests/demo/foo.h b/tests/demo/foo.h index 167096a..b0a1a47 100644 --- a/tests/demo/foo.h +++ b/tests/demo/foo.h @@ -37,6 +37,12 @@ or obtained by writing to the Free Software Foundation, Inc., # endif #endif +#ifdef _MSC_VER +# define EXTERN extern __declspec(dllimport) +#else +# define EXTERN extern +#endif + /* __BEGIN_DECLS should be used at the beginning of your declarations, so that C++ compilers don't mangle their names. Use __END_DECLS at the end of C declarations. */ @@ -83,7 +89,7 @@ or obtained by writing to the Free Software Foundation, Inc., __BEGIN_DECLS int foo LT_PARAMS((void)); int hello LT_PARAMS((void)); -extern int nothing; +EXTERN int nothing; __END_DECLS #endif /* !_FOO_H_ */ diff --git a/tests/depdemo/l1/l1.h b/tests/depdemo/l1/l1.h index 8e773ca..47f7be0 100644 --- a/tests/depdemo/l1/l1.h +++ b/tests/depdemo/l1/l1.h @@ -30,7 +30,7 @@ or obtained by writing to the Free Software Foundation, Inc., #include sysdep.h __BEGIN_DECLS -extern int var_l1; +EXTERN int var_l1; intfunc_l1 __P((int)); __END_DECLS diff --git a/tests/depdemo/l2/l2.h b/tests/depdemo/l2/l2.h index 728b1df..500049d 100644 --- a/tests/depdemo/l2/l2.h +++ b/tests/depdemo/l2/l2.h @@ -30,7 +30,7 @@ or obtained by writing to the Free Software Foundation, Inc., #include sysdep.h __BEGIN_DECLS -extern int var_l2; +EXTERN int var_l2; intfunc_l2 __P((int)); __END_DECLS diff --git a/tests/depdemo/l3/l3.h b/tests/depdemo/l3/l3.h index 6f0b446..59eff6d 100644 --- a/tests/depdemo/l3/l3.h +++ b/tests/depdemo/l3/l3.h @@ -30,7 +30,7 @@ or obtained by writing to the Free Software Foundation, Inc., #include sysdep.h __BEGIN_DECLS -extern int var_l3; +EXTERN int var_l3; intfunc_l3 __P((int)); __END_DECLS diff --git a/tests/depdemo/l4/l4.h b/tests/depdemo/l4/l4.h index bdf21d0..a78be74 100644 --- a/tests/depdemo/l4/l4.h
Re: [PATCH] tests: import variables for MSVC.
On Fri, 24 Sep 2010, Peter Rosin wrote: Hi! I don't know how to set up the defines so that EXTERN becomes 1. extern when you use a static library 2. extern when you build a static library 3. extern declspec(dllimport) when you use a shared library 4. extern declspec(dllexport) when you build a shared library I could fix 2 and 4, but separating 1 and 3 is not possible. Since extern declspec(dllimport) works everywhere with MSVC I'm taking the easy option with this patch. Or should I add -DBUILDING_FOO to Makefile.am and variations of the below to the code? #ifdef _MSC_VER # ifdef BUILDING_FOO # ifdef DLL_EXPORT # define EXTERN extern declspec(dllexport) # endif # else # define EXTERN extern declspec(dllimport) # endif #endif #ifndef EXTERN # define EXTERN extern #endif here is what I use: http://trac.enlightenment.org/e/browser/trunk/PROTO/evil/src/lib/Evil.h#L7 It's what you do, with just an additional else in DLL_EXPORT case, without your #ifndef. works fine with gcc (mingw, mingw-w64, mingw32ce) and vc++ hth Vincent Torri
[PATCH] msvc: don't try to export import descriptors.
Hi!
With the patch posted with subject: [PATCH] tests: import variables for MSVC.
I found that libtool tries to put some bad symbols in the generated
symbol lookup table leading to errors such as this:
libtool: link: (cd .libs /home/peda/automake/lib/compile cl -MD -Zi -EHsc -c
helldl.exeS.c)
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
helldl.exeS.c
helldl.exeS.c(25) : error C2143: syntax error : missing '{' before '-'
helldl.exeS.c(25) : error C2059: syntax error : '-'
helldl.exeS.c(39) : error C2065: '_IMPORT_DESCRIPTOR_hello' : undeclared
identifier
helldl.exeS.c(39) : error C2036: 'void *' : unknown size
make: *** [helldl.exe] Error 2
This patch fixes those problems. No regressions otherwise.
Ok to push?
Cheers,
Peter
From b36c46a667443d4bacd99281f23f44fff1add44e Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Thu, 23 Sep 2010 23:02:42 +0200
Subject: [PATCH] msvc: don't try to export import descriptors.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw]
[pw32, cegcc] cl*, exclude_expsyms: Don't export symbols in
import libraries related to describing what dll(s) the import
library is importing. Fixes problem in tests/demo-make.test
and some other tests.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
ChangeLog |9 +
libltdl/m4/libtool.m4 |5 -
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 647c151..b5f183d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-23 Peter Rosin p...@lysator.liu.se
+
+ msvc: don't try to export import descriptors.
+ * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw]
+ [pw32, cegcc] cl*, exclude_expsyms: Don't export symbols in
+ import libraries related to describing what dll(s) the import
+ library is importing. Fixes problem in tests/demo-make.test
+ and some other tests.
+
2010-09-22 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix regression in command-line length computation.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 6aebb63..ce33bfe 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4492,7 +4492,9 @@ m4_if([$1], [CXX], [
;;
cygwin* | mingw* | cegcc*)
case $cc_basename in
-cl*) ;;
+cl*)
+ _LT_TAGVAR(exclude_expsyms,
$1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_NULL_IMPORT_DESCRIPTOR|_IMPORT_DESCRIPTOR_.*']
+ ;;
*)
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1
DATA/;s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[
]]/s/.* //'\'' | sort | uniq $export_symbols'
_LT_TAGVAR(exclude_expsyms,
$1)=['[_]+GLOBAL_OFFSET_TABLE_|[_]+GLOBAL__[FID]_.*|[_]+head_[A-Za-z0-9_]+_dll|[A-Za-z0-9_]+_dll_iname']
@@ -5064,6 +5066,7 @@ _LT_EOF
# The linker will not automatically build a static lib if we build a
DLL.
# _LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
+ _LT_TAGVAR(exclude_expsyms,
$1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_NULL_IMPORT_DESCRIPTOR|_IMPORT_DESCRIPTOR_.*']
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience |
$global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^
]]*\)/\1,DATA/'\'' | $SED -e '\''/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq
$export_symbols'
# Don't use ranlib
_LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib'
--
1.7.1
Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.
Hello Peter, * Peter Rosin wrote on Fri, Sep 17, 2010 at 08:44:43AM CEST: need_lib_prefix.at currently fails with MSVC. I think the test is there to ensure that weird systems continue to work even if the testsuite is running on a normal system. weird in this case are systems with need_lib_prefix set to unknown and normal are those with it set to no. However, there are even weirder systems where need_lib_prefix should perhaps be set to never (i.e. MSVC) but that currently simply sets it to no. never would perhaps be more appropriate since preopen doesn't work right if libs have a lib prefix. I think OS/2 is affected in the same way as MSVC, but I have no means to test that. The below patch makes the need_lib_prefix.at test skip for the even weirder systems, i.e. those where libname_spec does not prefix library names with lib. Ok to push? You may want to compare this patch with thread http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00174.html which instead makes the test pass for the even weirder systems, but I don't think that is really desired. Why should the code be changed to accommodate a contrived test case? Because this would never happen in the wild, right? The part about this patch which I'm unsure about is this: Does the testsuite otherwise cover well enough the fact that users may name their modules with or without leading 'lib' prefix (and with .la or .dll or .so suffix or so)? IOW, I'd like to be sure we're not hiding anything here. And yes, I think (part of) the log entry from the initial test addition probably deserves to be a comment in the test, so we don't have to look it up again. Subject: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries. * tests/need_lib_prefix.at [MSVC, OS/2]: Skip this test on systems that do not have libraries prefixed with lib. Thanks, Ralf
Re: [PATCH] msvc: don't try to export import descriptors.
Hi Peter, * Peter Rosin wrote on Fri, Sep 24, 2010 at 12:39:13AM CEST: With the patch posted with subject: [PATCH] tests: import variables for MSVC. I found that libtool tries to put some bad symbols in the generated symbol lookup table leading to errors such as this: Ok to push? Yes, with nit below addressed. Subject: [PATCH] msvc: don't try to export import descriptors. * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw] [pw32, cegcc] cl*, exclude_expsyms: Don't export symbols in import libraries related to describing what dll(s) the import library is importing. Fixes problem in tests/demo-make.test and some other tests. --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4492,7 +4492,9 @@ m4_if([$1], [CXX], [ ;; cygwin* | mingw* | cegcc*) case $cc_basename in -cl*) ;; +cl*) + _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_NULL_IMPORT_DESCRIPTOR|_IMPORT_DESCRIPTOR_.*'] Does cl generate _GLOBAL_OFFSET_TABLE_ symbols, or _GLOBAL__F* ones? If yes, is the leading underscore for the former optional? I'm guessing no for both of these, which means you can omit them here. I'm also guessing that GCC won't generate them either on w32, but really not so sure about that; and the MSVC case is easier because we don't risk regressions in leaving them out for now. Same below, of course. + ;; *) _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/;s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[ ]]/s/.* //'\'' | sort | uniq $export_symbols' _LT_TAGVAR(exclude_expsyms, $1)=['[_]+GLOBAL_OFFSET_TABLE_|[_]+GLOBAL__[FID]_.*|[_]+head_[A-Za-z0-9_]+_dll|[A-Za-z0-9_]+_dll_iname'] @@ -5064,6 +5066,7 @@ _LT_EOF # The linker will not automatically build a static lib if we build a DLL. # _LT_TAGVAR(old_archive_from_new_cmds, $1)='true' _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes + _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_NULL_IMPORT_DESCRIPTOR|_IMPORT_DESCRIPTOR_.*'] _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1,DATA/'\'' | $SED -e '\''/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq $export_symbols' # Don't use ranlib _LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib' Thanks, Ralf
Re: [PATCH] tests: import variables for MSVC.
Hi Peter, * Peter Rosin wrote on Fri, Sep 24, 2010 at 12:25:14AM CEST: Subject: [PATCH] tests: import variables for MSVC. * tests/depdemo/sysdep.h (EXTERN): New define, saying how to declare variables that might need to be imported. * tests/depdemo/l1/l1.h, tests/depdemo/l2/l2.h, tests/depdemo/l3/l3.h, tests/depdemo/l4/l4.h: Use it. * tests/demo/foo.h (EXTERN): New define, saying how to declare variables that might need to be imported. Use it. * tests/pdemo/foo.h (EXTERN) [MSVC]: Make MSVC import variables if needed. Patch is ok with me if it keeps GCC working, and Chuck is ok with it. You meant to use __declspec everywhere not declspec, even in your text part of the mail, right? A documentation addition describing the most general case of annotations (multiple libraries, mixed static/shared, full MSVC + everything else support) plus simplifications for common cases, - no MSVC, - no shared/static mixing, - rely on auto-import, - ... would be good to have. Something from which I can deduce that your patch must be correct. Of course, if libtool can somehow help with this any more, so much the better. But I'm less optimistic on this than I was those five years ago. :-/ Also, may I remind you that you promised a number of testsuite additions before the release. Thanks, Ralf
Re: 2.4 Release in 24hrs
Hi Ralf, Den 2010-09-20 19:41 skrev Ralf Wildenhues: I'd really appreciate if you guys could send build logs to the autobuild server as I've been doing lately, much more than just posting non-verbose results on the list here. You don't need to have autobuild installed. When Eric installs autobuild.m4 you don't need to do anything else. Here's what I use, more or less, to create the logs: ( ../libtool/configure [OPTIONS] \ make \ make -k check cat test-suite.log tests/testsuite.log if tail tests/testsuite.log | grep '^| ' /dev/null; then :; else sed 's/^/| /' config.log fi ) logfile $sanitize logfile mail libtool_autobuild.josefsson.org logfile with the underscore replaced by @. For now, OPTIONS includes autobuild_mode=bla if there is anything special about the build. If I do post there, will a human (you?) or a robot process the mail? Is the Subject: important? I have plans to soon mail output from the v2.4 tag with OPTIONS as below on MSYS: autobuild_mode=msvc \ CC=/c/cygwin/home/peda/automake/lib/compile cl \ CFLAGS=-MD -Zi -EHsc \ CXX=/c/cygwin/home/peda/automake/lib/compile cl \ CXXFLAGS=-MD -Zi -EHsc \ LD=link \ NM=dumpbin -symbols \ STRIP=: \ AR=/c/cygwin/home/peda/automake/lib/ar-lib lib \ RANLIB=: \ F77=no \ FC=no \ GCJ=no \ --enable-dependency-tracking and as below on Cygwin: autobuild_mode=msvc \ CC=/home/peda/automake/lib/compile cl \ CFLAGS=-MD -Zi -EHsc \ CXX=/home/peda/automake/lib/compile cl \ CXXFLAGS=-MD -Zi -EHsc \ LD=link \ NM=dumpbin -symbols \ STRIP=: \ AR=/home/peda/automake/lib/ar-lib lib \ RANLIB=: \ F77=no \ FC=no \ GCJ=no \ --enable-dependency-tracking \ lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32 \ lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 \ Should I have set autobuild_mode to something else? I'll fiddle the already generated output if so... Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Multi lib 32 bits support
Hello: The new released libtool 2.4 fixed my compilation problem while linking a dll with code compiled with -flto. Now I have new problem with 32-bit. I think libtool 2.4 breaks multi-lib 32-bit. For 64-bit it was ok. Also I didn't notice this error while using older libtool came with the o/s. ltmain.sh (GNU libtool) 2.2.6b At link time it used gcc to link a *.c object file but failed to pick the right path to the correct library. It picked up lib/gcc/x86_64-w64-mingw32/4.5.2/libstdc++.a instead of picking up lib/gcc/x86_64-w64-mingw32/4.5.2/32/libstdc++.a Is this a know issue? Regards. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
On 22/09/2010 09:49, Marco Atzeri wrote: Dear developers, is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all I see this warning re: libintl when I build libgcj. In that case, it happens because for some reason (I haven't established yet whether this is down to libtool or the libgcj makefile) something goes wrong with directory search paths, and /lib appears in the list ahead of /usr/lib. As a consequence, libtool finds the .la file via Cygwin's /lib mountpoint rather than the real /usr/lib path, all the relative paths are wrong and it looks like the control script has been moved. This shows up in the warning it issues: libtool: link: warning: `/lib/libiconv.la' seems to be moved I wonder if your problem has a similar cause underlying in some way? cheers, DaveK ___ http://lists.gnu.org/mailman/listinfo/libtool
autobuild results (was: 2.4 Release in 24hrs)
Hi Peter, * Peter Rosin wrote on Thu, Sep 23, 2010 at 08:54:43AM CEST: Den 2010-09-20 19:41 skrev Ralf Wildenhues: I'd really appreciate if you guys could send build logs to the autobuild server as I've been doing lately, much more than just posting non-verbose results on the list here. [...] Here's what I use, more or less, to create the logs: mail libtool_autobuild.josefsson.org logfile with the underscore replaced by @. For now, OPTIONS includes autobuild_mode=bla if there is anything special about the build. If I do post there, will a human (you?) or a robot process the mail? A robot will periodically (once an hour?) process mails, deleting anything not carrying the autobuild signature, and creating the overview web page that links to all logs from the rest. Details at http://autobuild.josefsson.org/README.html. I'm mostly interested in collecting a large number of samples in order to be able to pinpoint regressions more easily at a later stage. For this reason, and because Simon garbage-collects logs older than 24 days, I'm probably going to start mirroring all posted logs to my hard drive eventually. Hopefully this can be improved somehow at a later stage, when the service has moved to savannah. Is the Subject: important? No. I have plans to soon mail output from the v2.4 tag with OPTIONS as below on MSYS: *snip* That looks all fine to me. Thanks! Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO
Hello t7, * t66...@gmail.com wrote on Thu, Sep 23, 2010 at 03:01:31AM CEST: I don't know if my problem suites this description. No, it doesn't. Currently installed libtool on this system is, ltmain.sh (GNU libtool) 2.2.6b I recently tested the LTO feature of GCC (targeting windows) and I found it was unable to link due to the presence of duplicating lines of *crt* without compiling with -flto there were not such issues. It seems that libtool is emitting dllcrt2, crtbegin, crtend all over again after the first crtend. In the following line. g++ lib64/dllcrt2.o lib64/crtbegin.o ... _alot_of_other_link_arguments_ ... lib64/crtend.o lib64/dllcrt2.o lib64/crtbegin.o lib64/crtend.o These last three duplicating .o arguments are causing errors. lib64/dllcrt2.o:crtdll.c:(.text+0x50): multiple definition of `_CRT_INIT' lib64/dllcrt2.o:crtdll.c:(.text+0x50): first defined here Is this a know issue? You may have found a bug, or not, I cannot tell from the sparse description you've given. Please write to the bug-libtool at gnu.org mailing list (no subscription required) with full details about which GCC and Libtool versions you are using, after updating Libtool to 2.4 if you are trying to use LTO with it, write how you configured the software that fails to link, and please post the complete 'libtool --mode=link' command that fails, including all of its output. Then we will see further. On the odd chance of turning up a new GCC bug, we'll report back to the GCC bugzilla then. But until then there is no need to cross-post this to the GCC development mailing list. Thank you. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Multi lib 32 bits support
Hello t7, please consider using the bug-libtool list for bug reports and a real name for posting, that is considered friendly. Thanks. * t66...@gmail.com wrote on Thu, Sep 23, 2010 at 11:11:34AM CEST: The new released libtool 2.4 fixed my compilation problem while linking a dll with code compiled with -flto. Ah ok. Good. Now I have new problem with 32-bit. I think libtool 2.4 breaks multi-lib 32-bit. For 64-bit it was ok. Also I didn't notice this error while using older libtool came with the o/s. ltmain.sh (GNU libtool) 2.2.6b At link time it used gcc to link a *.c object file but failed to pick the right path to the correct library. It picked up lib/gcc/x86_64-w64-mingw32/4.5.2/libstdc++.a instead of picking up lib/gcc/x86_64-w64-mingw32/4.5.2/32/libstdc++.a Please post the output of './libtool --tag=CXX --config'. Thanks. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autobuild results
Den 2010-09-23 20:05 skrev Ralf Wildenhues: I have plans to soon mail output from the v2.4 tag with OPTIONS as below on MSYS: *snip* That looks all fine to me. Thanks! Hi Ralf, Ok, done, and they appeared just fine on the site too. Since you said you were going to collect them, would you want a bcc for future dumps? Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
--- Gio 23/9/10, Dave Korn ha scritto: On 22/09/2010 09:49, Marco Atzeri wrote: Dear developers, is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all I see this warning re: libintl when I build libgcj. In that case, it happens because for some reason (I haven't established yet whether this is down to libtool or the libgcj makefile) something goes wrong with directory search paths, and /lib appears in the list ahead of /usr/lib. As a consequence, libtool finds the .la file via Cygwin's /lib mountpoint rather than the real /usr/lib path, all the relative paths are wrong and it looks like the control script has been moved. This shows up in the warning it issues: libtool: link: warning: `/lib/libiconv.la' seems to be moved I wonder if your problem has a similar cause underlying in some way? cheers, DaveK from what I can see the bogus warning is caused by test $absdir != $libdir \ func_warning \`$deplib' seems to be moved changing the warning in test $absdir != $libdir \ func_warning \`$absdir' \`$libdir' \`$deplib' seems to be moved I found: libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../..' `/usr/lib' `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfftw3.la' seems to be moved so it seems that absdir is not a real absolute directory. and this case block seems the culprit # We need an absolute path. case $dir in [\\/]* | [A-Za-z]:[\\/]*) absdir=$dir ;; *) absdir=`cd $dir pwd` if test -z $absdir; then func_warning cannot determine absolute directory name of \`$dir' absdir=$dir fi ;; esac This assignement would be correct, but it is not applied absdir=`cd $dir pwd` Marco ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
Just FYI... I don't think the following scenario applies to either of you, but I ran into the warning in the case described below -- and the warning is valid (e.g. we shouldn't try to fix MY case). I was using a cross compiler with sysroot support (cygwin-mingw) to build cygwin's setup.exe. I was linking against some pre-built libraries (compression, gpg) built using that cross compiler, but using an older, pre-sysroot-support version of libtool. (E.g. these libs are NOT the mingw-libfoo packages currently available from cygwin.com). Anyway, so what I had was: /usr/i686-pc-mingw32/sys-root/mingw/lib/liblzma.la etc, but -- because the lib was built using a non-sysroot libtool, the .la file specifies libdir='/mingw/lib' NOT libdir='=/mingw/lib' So, when building setup.exe using a libtool that supports --with-sysroot, it (quite rightly) complains that liblzma.la appears to be moved -- because it (a) is NOT in /mingw/lib, and (b) doesn't have the magic '=' sysroot marker. This is as designed. The fix is for me to rebuild liblzma et al using a sysroot-capable libtool. Just wanted to point out this scenario, which has similar symptoms as those reported by Marco and Dave, but is NOT an error. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: autobuild results
Good morning Peter, * Peter Rosin wrote on Thu, Sep 23, 2010 at 10:40:48PM CEST: Den 2010-09-23 20:05 skrev Ralf Wildenhues: I have plans to soon mail output from the v2.4 tag with OPTIONS as below on MSYS: *snip* That looks all fine to me. Thanks! Ok, done, and they appeared just fine on the site too. Since you said you were going to collect them, would you want a bcc for future dumps? As long as I know there are logs to collect, that's not necessary. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
Hello Marco, thanks for the bug report. * Marco Atzeri wrote on Wed, Sep 22, 2010 at 10:49:56AM CEST: is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all $ libtool --version libtool (GNU libtool 1.3260 2010-09-02) 2.2.11a on cygwin-1.7.x I agree that it is likely that the warning is bogus in your specific case. All other messages in this thread so far have been about slightly different cases; ignore them. To be sure however, please send the full 'libtool --mode=link' command that caused the above warnings, plus all of its output. I'll put fixing this on my TODO list then. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
On 9/24/2010 12:45 AM, Marco Atzeri wrote: I am not sure to follow your explanation. on cygwin $cd /usr/lib I'm cross building, using $build_os=cygwin, but $host_os=mingw32, and a cross compiler. I am *not* building natively. In this situation, and with the new sysroot support in libtool, .la files will have a magic marker like this: -L=/some/path, or libdir='=/some/path'. The extra '=' symbol is interpreted by (new) libtool, WHEN it too is told that sysroots are active, to mean: pretend /some/path is prefixed by whatever the sysroot of the current compiler is; e.g. 'i686-pc-mingw32-gcc -print-sysroot' might report: /usr/i686-pc-mingw32/sys-root So, if the .la file in /usr/i686-pc-mingw32/sys-root/mingw/lib/foo.la claims that its libdir should be =/mingw/lib, libtool will magically prepend the compiler's sysroot, and interpret the libdir specification AS IF it said libdir='/usr/i686-pc-mingw32/sys-root/mingw/lib' and not libdir='=/mingw/lib' Since that IS where the .la file is located, all is well and no warning is printed. However, WITHOUT sysroot support in libtool (or if the .la file doesn't have the magic '=' marker) none of this occurs, and libtool will print the warning. But...that's what it is supposed to do in this case. Now, I'm talking ONLY about a cross build situation. See (latest 2.4 libtool) info. There's a whole section about it. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
--- Ven 24/9/10, Marco Atzeri ha scritto:
--- Ven 24/9/10, Charles Wilson
ha scritto:
Just FYI...
I don't think the following scenario applies to either
of
you, but I ran
into the warning in the case described below -- and
the
warning is valid
(e.g. we shouldn't try to fix MY case).
I was using a cross compiler with sysroot support
(cygwin-mingw) to
build cygwin's setup.exe. I was linking against
some
pre-built
libraries (compression, gpg) built using that cross
compiler, but using
an older, pre-sysroot-support version of libtool.
(E.g. these libs are
NOT the mingw-libfoo packages currently available
from
cygwin.com).
Anyway, so what I had was:
/usr/i686-pc-mingw32/sys-root/mingw/lib/liblzma.la
etc, but -- because the lib was built using a
non-sysroot
libtool, the
.la file specifies
libdir='/mingw/lib'
NOT
libdir='=/mingw/lib'
So, when building setup.exe using a libtool that
supports
--with-sysroot, it (quite rightly) complains that
liblzma.la appears to
be moved -- because it (a) is NOT in /mingw/lib, and
(b)
doesn't have
the magic '=' sysroot marker.
This is as designed. The fix is for me to rebuild
liblzma et al using
a sysroot-capable libtool.
Just wanted to point out this scenario, which has
similar
symptoms as
those reported by Marco and Dave, but is NOT an
error.
--
Chuck
Charles,
I am not sure to follow your explanation.
on cygwin
$cd /usr/lib
$ grep libdir *.la
libFLAC++.la:libdir='/usr/lib'
libFLAC.la:libdir='/usr/lib'
libGraphicsMagick++.la:libdir='/usr/lib'
libGraphicsMagick.la:libdir='/usr/lib'
libGraphicsMagickWand.la:libdir='/usr/lib'
libICE.la:libdir='/usr/lib'
libMagick++.la:libdir='/usr/lib'
libMagickCore.la:libdir='/usr/lib'
libMagickWand.la:libdir='/usr/lib'
libMrm.la:libdir='/usr/lib'
libSM.la:libdir='/usr/lib'
libUil.la:libdir='/usr/lib'
libX11.la:libdir='/usr/lib'
libXau.la:libdir='/usr/lib'
libXaw7.la:libdir='/usr/lib'
and so on.
and nothing different
there is no libdir='=/...
and on my build
$ find . -name *.la -exec grep libdir \{\} \;
libdir='/usr/local/lib/octave-3.3.52+'
libdir=''
libdir='/usr/local/lib/octave-3.3.52+'
On my humble understanding
libdir is a variable with the name of the directory,
I never saw and not found in libtool documentation
libdir='=/...
could you point me to some documentation about it ?
Marco
___
http://lists.gnu.org/mailman/listinfo/libtool
