Re: add cegcc support
Hey, Here is a patch to make libtool support the cegcc compiler. The patch is made wrt the latest cvs. Thank you for the patch. Please bootstrap Libtool 2.2.2 with this patch, build it for this system (cross-compile if you have to), and send the output of make -k check I can't, as there are too much differences between cvs and libtool 2.2.2 and the patch can't apply to that version Should I make the diff wrt libtool 2.2.2 ?? That would be strange Vincent Torri
Re: add cegcc support
* Vincent Torri wrote on Mon, Apr 14, 2008 at 08:39:02AM CEST: Here is a patch to make libtool support the cegcc compiler. The patch is made wrt the latest cvs. Thank you for the patch. Please bootstrap Libtool 2.2.2 with this patch, build it for this system (cross-compile if you have to), and send the output of make -k check I can't, as there are too much differences between cvs and libtool 2.2.2 and the patch can't apply to that version Should I make the diff wrt libtool 2.2.2 ?? That would be strange Against CVS HEAD is just fine, sorry for the confusion. The important thing is that we see how the testsuite fares in order to get an idea how well the port works, and can fix simple issues that were overlooked. Cheers, Ralf
Allow bootstrap from git repository
Hi,
* Makefile.am: Expect mkstamp to return only rev date.
* libltdl/config/mkstamp: return a revision and date based on the number
of lines in the input and the topmost date.
Ok?
Peter
--
Peter O'Gorman
http://pogma.com
* Makefile.am: Expect mkstamp to return only rev date.
* libltdl/config/mkstamp: return a revision and date based on the number of lines in the input and the topmost date.
---
ChangeLog |7 +++
Makefile.am|2 +-
libltdl/config/mkstamp | 32 ++--
3 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b4fac02..3eba77e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2008-04-14 Peter O'Gorman [EMAIL PROTECTED]
+
+ Allow bootstrap from git repository.
+ * Makefile.am: Expect mkstamp to return only rev date.
+ * libltdl/config/mkstamp: return a revision and date based on
+ the number of lines in the input and the topmost date.
+
2008-04-11 Eric Blake [EMAIL PROTECTED]
Fix usage of setmode without declaration on cygwin.
diff --git a/Makefile.am b/Makefile.am
index 0168a41..4609cdd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -52,7 +52,7 @@ MKSTAMP = $(SHELL) $(srcdir)/$(auxdir)/mkstamp
timestamp = set dummy `$(MKSTAMP) $(srcdir)/ChangeLog`; shift; \
case $(VERSION) in \
- *[acegikmoqsuwy]) TIMESTAMP= $$1 $$2 $$3 ;; \
+ *[acegikmoqsuwy]) TIMESTAMP= $$1 $$2 ;; \
*) TIMESTAMP= ;; \
esac
diff --git a/libltdl/config/mkstamp b/libltdl/config/mkstamp
index 8d8e7d8..eb3284a 100755
--- a/libltdl/config/mkstamp
+++ b/libltdl/config/mkstamp
@@ -23,15 +23,27 @@
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-# This script expects to find a line containing both Revision and Date
-# tags, and it edits this line so that it looks like ` $rev $date'
+# This script counts the lines in a Changelog and generates a
+# revision date on the output.
-# Command-line arguments are passed down to sed; additional -e cmd
-# arguments are acceptable. Input is from from stdin. The original
-# version of this script accepted input from a named file or stdin.
+# Generate a revision that looks similar to CVS revision by using 1.
+# then the last 2 digits of the year +30 (so that the revision number
+# is greater than the last cvs revision, and the number of lines
+# in the ChangeLog. For those pulling from the savannah git repository
+# it should be possible to go from this revision number to the git
+# revision fairly easily. The number will also always increase,e ven
+# when we rotate ChangeLogs in the new year.
-tr -d \015 | sed -e '
- s%.*\$''Revision: \([^$]*\) \$.*\$''Date: \([^$]*\) \$.*% \1 \2%
- t end
- d
- : end' ${1+$@}
+awk 'BEGIN {
+ dated=0;
+}
+/^20/ {
+ if (dated == 0) {
+ dated=1;
+ datestr=$1;
+ }
+}
+END {
+ yr=substr(datestr,3,2) + 30;
+ print 1. yr NR datestr;
+}'
--
1.5.3.7
Re: Allow bootstrap from git repository
Hi Peter,
* Peter O'Gorman wrote on Tue, Apr 15, 2008 at 05:43:36AM CEST:
* Makefile.am: Expect mkstamp to return only rev date.
* libltdl/config/mkstamp: return a revision and date based on the
number of lines in the input and the topmost date.
Hmm, I was almost saying OK, except the last nit below:
+# Generate a revision that looks similar to CVS revision by using 1.
+# then the last 2 digits of the year +30 (so that the revision number
Two digit will *always* be enough, just like 640K! ;-)
+# is greater than the last cvs revision, and the number of lines
+# in the ChangeLog. For those pulling from the savannah git repository
+# it should be possible to go from this revision number to the git
+# revision fairly easily. The number will also always increase,e ven
s/e ven/ even/
+# when we rotate ChangeLogs in the new year.
But how do you ensure @MACRO_SERIAL@ increases after ChangeLog rotation?
+awk 'BEGIN {
+ dated=0;
+}
+/^20/ {
+ if (dated == 0) {
+ dated=1;
+ datestr=$1;
+ }
+}
+END {
+ yr=substr(datestr,3,2) + 30;
+ print 1. yr NR datestr;
+}'
.gitignore
OK? (No ChangeLog entry.) Cheers, Ralf Ignore generated files. diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..252219d --- /dev/null +++ b/.gitignore @@ -0,0 +1,47 @@ +*.aux +*.cp +*.cps +*.dvi +*.fn +*.ky +*.la +*.lo +*.log +*.o +*.pg +*.toc +*.tp +*.vr ++build ++dest ++inst +.*.prcs_aux +.clcommitrc +.cvslog-tlasync +.deps +.dirstamp +.gdb_history +.libs +.pc +INSTALL +Makefile +Makefile.in +_libs +acinclude.m4 +aclocal.m4 +autom4te.cache +clibtool.cfg +commit +config-h.in +config.* +configure +conftest* +libtool +libtool-*.tar.bz2 +libtool-*.tar.gz +libtool-*.tar.lzma +libtoolize +libtoolize.in +manual.html +patches +stamp-* diff --git a/doc/.gitignore b/doc/.gitignore new file mode 100644 index 000..bc21901 --- /dev/null +++ b/doc/.gitignore @@ -0,0 +1,8 @@ +stamp-vti +version.texi +notes.txt +*.dvi +*.info* +*.html +*.ps +*.pdf diff --git a/libltdl/.gitignore b/libltdl/.gitignore new file mode 100644 index 000..94729d4 --- /dev/null +++ b/libltdl/.gitignore @@ -0,0 +1,2 @@ +Makefile.am +argz.h diff --git a/libltdl/config/.gitignore b/libltdl/config/.gitignore new file mode 100644 index 000..a3959de --- /dev/null +++ b/libltdl/config/.gitignore @@ -0,0 +1,12 @@ +install-sh +ltmain.in +ltmain.sh +mdate-sh +missing +mkinstalldirs +texinfo.tex +depcomp +compile +config.guess +config.sub +mailnotify diff --git a/libltdl/m4/.gitignore b/libltdl/m4/.gitignore new file mode 100644 index 000..0b52c5c --- /dev/null +++ b/libltdl/m4/.gitignore @@ -0,0 +1 @@ +ltversion.m4 diff --git a/tests/.gitignore b/tests/.gitignore new file mode 100644 index 000..d66dec6 --- /dev/null +++ b/tests/.gitignore @@ -0,0 +1,7 @@ +atconfig +defs.in +defs +package.m4 +testsuite +testsuite.dir +testsuite.log diff --git a/tests/cdemo/.gitignore b/tests/cdemo/.gitignore new file mode 100644 index 000..eebd27f --- /dev/null +++ b/tests/cdemo/.gitignore @@ -0,0 +1 @@ +cdemo diff --git a/tests/demo/.gitignore b/tests/demo/.gitignore new file mode 100644 index 000..cee443d --- /dev/null +++ b/tests/demo/.gitignore @@ -0,0 +1,7 @@ +hc-direct +hc-libflag +hc-libpath +hc-minusL +hell +hell_static +helldl diff --git a/tests/depdemo/.gitignore b/tests/depdemo/.gitignore new file mode 100644 index 000..3aa957b --- /dev/null +++ b/tests/depdemo/.gitignore @@ -0,0 +1,2 @@ +depdemo +depdemo_static diff --git a/tests/f77demo/.gitignore b/tests/f77demo/.gitignore new file mode 100644 index 000..a7668b9 --- /dev/null +++ b/tests/f77demo/.gitignore @@ -0,0 +1,2 @@ +cprogram +fprogram diff --git a/tests/fcdemo/.gitignore b/tests/fcdemo/.gitignore new file mode 100644 index 000..a7668b9 --- /dev/null +++ b/tests/fcdemo/.gitignore @@ -0,0 +1,2 @@ +cprogram +fprogram diff --git a/tests/mdemo/.gitignore b/tests/mdemo/.gitignore new file mode 100644 index 000..0b4a56b --- /dev/null +++ b/tests/mdemo/.gitignore @@ -0,0 +1,2 @@ +mdemo +mdemo_static diff --git a/tests/mdemo2/.gitignore b/tests/mdemo2/.gitignore new file mode 100644 index 000..6e24c0b --- /dev/null +++ b/tests/mdemo2/.gitignore @@ -0,0 +1,2 @@ +mdemo2 +mdemo2_static diff --git a/tests/pdemo/.gitignore b/tests/pdemo/.gitignore new file mode 100644 index 000..1cc71be --- /dev/null +++ b/tests/pdemo/.gitignore @@ -0,0 +1,3 @@ +hell +hell_static +helldl diff --git a/tests/tagdemo/.gitignore b/tests/tagdemo/.gitignore new file mode 100644 index 000..a36b095 --- /dev/null +++ b/tests/tagdemo/.gitignore @@ -0,0 +1 @@ +tagdemo
Re: Allow bootstrap from git repository
* Peter O'Gorman wrote on Tue, Apr 15, 2008 at 07:40:54AM CEST: Ralf Wildenhues wrote: But how do you ensure @MACRO_SERIAL@ increases after ChangeLog rotation? Ha! Having never done a ChangeLog rotation or paid it much attention, I figured that the new ChangeLog would have a commit message like usual. 2009-01-01 Ralf Rotate Changelogs. * ChangeLog, ChangeLog.2007: rotated. But they don't :) That would be easy to solve. But even if they did, the macro serial goes from 38763 or so to 3910, not from 1.38763 to 1.3910. Could do a count of ChangeLog* files, and use that as the first digit, I suppose. Not tonight though, need some sleep :) Sounds like a possible plan. Cheers, Ralf
Re: libtool performance...
Ralf Wildenhues wrote:
* Roland Mainz wrote on Fri, Apr 11, 2008 at 04:59:15PM CEST:
Ok... but dolt may been to be adopted to other compilers (like Sun
Workshop/Forte/Studio, icc etc.) and then it will be a bit more than the
10 lines (and adopting it for other POSIX-like shells may be nice, too -
Josh measured against Libtool 1.5.x. Libtool 2.2.2 has a lot less
overhead in compile mode than 1.5.x, see the numbers Ross posted, and
the list archive of libtool-patches for several improvements including
numbers; and we are currently working on improving things a bit more,
targeting improvements that help all shells which support XSI
extensions (and falling back to the slow code for other shells).
What do you mean by XSI extensions ?
BTW: One thing which could be improved in both libtool and dolt
(beyond the stuff listed in
http://www.opensolaris.org/os/project/shell/shellstyle/) would be to get
rid of the echo h*ll - almost every version of Unix/Linux and shell
has it's own version of echo (Solaris even has multiple one:
/usr/bin/echo, /usr/ucb/echo, /usr/gnu/echo and the { bash, Bourne, csh,
ksh88, ksh93, zsh } builtin version of echo - all of them with
slightly different behaviour).
A more portable solution would be to use the printf command (which is
usually a shell builtin (at lest in bash+ksh93's case)) which is part of
the POSIX standard (the POSIX people were aware of the echo h*ll since
a long time and choose to create a new utilty than trying to fight each
and every OS+shell vendor/author... :-) ) and therefore has guranteed
behaviour for quoting, backslashes etc. (and avoids undesired
sideeffects when a variable contains backslashes, e.g. $ foo=\a
chicken ; echo $foo # will result in some OS/shell-specific string
while $ foo=\a chicken ; printf %s\n $foo # will precisely print
\achicken).
While the multi-thousand line script can't get as fast as dolt -- after
all, dolt isn't portable to non-bash,
Well, I can provide patches to make it at least compatible to all POSIX
compatible shells (AFAIK that would only require minor adjustments...).
also there's functionality that
libtool compile mode offers that dolt doesn't -- we expect compile mode
to become fast enough that the overhead shouldn't be a big problem for
practical use, and we expect that to come without the need for users to
change their configure.ac scripts at all.
Meanwhile, updating to 2.2.2 would be a good idea, its link mode has
also become considerably faster than 1.5.x at least for some use cases.
We would appreciate bug reports for particular remaining performance
bottlenecks.
Question for both dolt and libtool developers:
Where should I send bug reports/patches to ?
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, CJAVASunUnix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool performance...
[ since my mails are being dropped for the other lists anyway, I might
as well drop the xorg and gnome-devtools lists ]
* Roland Mainz wrote on Mon, Apr 14, 2008 at 03:26:11PM CEST:
Ralf Wildenhues wrote:
[...] we are currently working on improving things a bit more,
targeting improvements that help all shells which support XSI
extensions (and falling back to the slow code for other shells).
What do you mean by XSI extensions ?
Shells that support Posix and XSI extensions to Posix. Stuff like
${variable%%pattern}
${variable#pattern}
Hmm, they are required by Posix even; I wonder whether they used to be
extensions required by XSI only, or why else we would have chosen that
name. Anyway, that's what I mean.
BTW: One thing which could be improved in both libtool and dolt
(beyond the stuff listed in
http://www.opensolaris.org/os/project/shell/shellstyle/) would be to get
rid of the echo h*ll - almost every version of Unix/Linux and shell
has it's own version of echo
I'm not sure what you're talking about: the configure part of Libtool
looks whether 'echo' doesn't interpret backslashes, and otherwise
searches for a (preferably builtin) command that prints without
expanding. And of course we also try printf, but it's known to be buggy
on some systems. It sets $ECHO to the preferred choice.
If you're experiencing a quoting bug, or a system where we choose a
non-builtin for $ECHO where a builtin would do the job just as well,
then please report a bug.
Also, some of the recommendations in the link you quote are rather
questionable. For example, the code in
http://www.opensolaris.org/os/project/shell/shellstyle/#use_external_filters_only_for_large_datasets
is much more portably (and likely faster, too) replaced by
case $x in *foo*) do_something;; esac
at the expense of using BREs over EREs, of course.
Also, some items explicitly recommend to use nonportable constructs over
portable ones, even without efficiency concerns. This is not a way to
go for Libtool.
Question for both dolt and libtool developers:
Where should I send bug reports/patches to ?
Libtool patches go to [EMAIL PROTECTED] Note that nontrivial
patches require copyright assignment to the FSF.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: don't let libtool infer the tag
* Mike Frysinger wrote on Mon, Apr 14, 2008 at 01:41:32AM CEST: On Sunday 13 April 2008, Ralf Wildenhues wrote: So don't do this, please. Supply --tag=CC if your compiler name doesn't match. i doubt people will care at this point, but ive done a bit of work in Gentoo to make the tag inferring better. ive done this as there are still a few packages out there that insist on using libtool found in $PATH. we've been killing them off over time, but we still havent gotten them all, so this painful patch lives on. http://sources.gentoo.org/sys-devel/libtool/files/1.5.6/libtool-1.5-filter-host-tags.patch Well, this patch is really ugly. Not only is it a further cause of overhead, it also can induce using libtool with a compiler or host system for which it hasn't been configured. Which can cause all kinds of interesting failures. So really please supply --tag to fix these. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: don't let libtool infer the tag
On Monday 14 April 2008, Ralf Wildenhues wrote: * Mike Frysinger wrote on Mon, Apr 14, 2008 at 01:41:32AM CEST: On Sunday 13 April 2008, Ralf Wildenhues wrote: So don't do this, please. Supply --tag=CC if your compiler name doesn't match. i doubt people will care at this point, but ive done a bit of work in Gentoo to make the tag inferring better. ive done this as there are still a few packages out there that insist on using libtool found in $PATH. we've been killing them off over time, but we still havent gotten them all, so this painful patch lives on. http://sources.gentoo.org/sys-devel/libtool/files/1.5.6/libtool-1.5-filte r-host-tags.patch Well, this patch is really ugly. Not only is it a further cause of overhead, it also can induce using libtool with a compiler or host system for which it hasn't been configured. Which can cause all kinds of interesting failures. So really please supply --tag to fix these. the tag inferring is all ugly. i'm not suggesting this patch cleans it up or anything, just that it makes it a little less painful if you dont plan on fixing the package to do things right. i agree completely that explicitly specifying the --tag is the right solution. i dont think the additional overhead to the tag inferring is a real issue -- if you're inferring tags, you're already doing it wrong ;). -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool performance and shells
Since it has been claimed that libtool causes a lot of build overhead, I have been doing a *lot* of testing here with latest development libtool. We already know that libtool 1.5.X is very slow so it is not worth worrying about that and it is more worthwhile to get projects migrated to libtool 2.2.X since it is much faster. Peter O'Gorman came up with a simple useless code parsing benchmark which showed that GNU bash could be the Worlds Slowest Shell (TM) except for a Korn shell clone called 'pdksh' which never completed at all. Other tests also pointed out that bash seemed to be a bit sluggish. DTrace shows that bash spends an awful lot of time in memset() as compared with the other shells. Simple shell benchmarks seemed to indicate that shells derived from the Almquist shell (http://en.wikipedia.org/wiki/Almquist_Shell) were the fastest and smallest. Ksh93 was almost as quick. Bash was slowest at simple contrived benchmarks. However, there is an old saying The proof is in the pudding. I have run overall timings of configure and full builds using various shells on different systems and found that on average, bash was not significantly slower at running the configure script. I also found that bash was not significantly slower for an overall libtool-based build. Bash is never the fastest, but when it is slower there is not a significant impact to overall build time. There are some systems where there is some benefit to using a shell other than bash, but the difference does not seem large enough for Autoconf and libtool to be concerned enough to use a different shell selection algorithm. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool performance... / was: Re: Announcing Dolt, a drop-in Libtool replacement which cuts build timesin half
Attila Kinali wrote: If you care about sane tools, why do you use auto* and libtool in the first place? Because converting X.Org's approximately 300 packages to anything else would be even more painful? (And believe me, I curse libtool regularly, and have had to find more ways to undo it's damage than I can count, so I'm not a fan either.) It's going to have to be a whole lot better than auto* and libtool to be worth the effort to move all of those, and it's going to need people in X.Org who know the new tools, while we've all learned the ones we have already. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ http://lists.gnu.org/mailman/listinfo/libtool
