Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> The only way to do it so that it works with both autoconf 2.13 and
> CVS autoconf, without triggering the warning in CVS autoconf, is
> this (from CVS automake's missing.m4):
>
> am_backtick='`'
> AC_MSG_WARN([${am_backtick}$VAR' ...])
Ok, I see. New (untested) patch attached.
BTW, I noticed something which looks a bit strange to me. Beginning at
approximately line 2180 of libtool.m4 (from the head CVS branch),
there are a lot of shell variables which are set up. But some of them
are just set to their current value, for instance like this:
[...]
# The host system.
host_alias=$host_alias
host=$host
[...]
# A symbol stripping program
STRIP=$STRIP
# Used to examine libraries when file_magic_cmd begins "file"
MAGIC_CMD=$MAGIC_CMD
# Used on cygwin: DLL creation program.
DLLTOOL="$DLLTOOL"
# Used on cygwin: object dumper.
OBJDUMP="$OBJDUMP"
# Used on cygwin: assembler.
AS="$AS"
[...]
..etc, etc. What is the point in doing this?
Regards,
Morten
Index: ChangeLog
===
RCS file: /home/cvs/libtool/ChangeLog,v
retrieving revision 1.809
diff -u -r1.809 ChangeLog
--- ChangeLog 2000/10/02 01:18:16 1.809
+++ ChangeLog 2000/10/11 14:48:12
@@ -1,3 +1,8 @@
+2000-10-12 Morten Eriksen <[EMAIL PROTECTED]>
+
+ * libtool.m4 (_LT_AC_LTCONFIG_HACK): Fix invalid backslash
+ quoting.
+
2000-10-02 Gary V. Vaughan <[EMAIL PROTECTED]>
From Bruce Korb <[EMAIL PROTECTED]>
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.118
diff -u -r1.118 libtool.m4
--- libtool.m4 2000/09/30 05:28:23 1.118
+++ libtool.m4 2000/10/12 10:32:42
@@ -775,10 +775,11 @@
# Check for any special shared library compilation flags.
if test -n "$ac_cv_prog_cc_shlib"; then
- AC_MSG_WARN([\`$CC' requires \`$ac_cv_prog_cc_shlib' to build shared libraries])
+ lt_backtick='`' # workaround for "quoted backtick" warning from Autoconf.
+ AC_MSG_WARN([${lt_backtick}$CC' requires ${lt_backtick}$ac_cv_prog_cc_shlib' to
+build shared libraries])
if echo "$old_CC $old_CFLAGS " | [egrep -e "[]$ac_cv_prog_cc_shlib[ ]"]
>/dev/null; then :
else
- AC_MSG_WARN([add \`$ac_cv_prog_cc_shlib' to the CC or CFLAGS env variable and
reconfigure])
+ AC_MSG_WARN([add ${lt_backtick}$ac_cv_prog_cc_shlib' to the CC or CFLAGS env
+variable and reconfigure])
ac_cv_prog_cc_can_build_shared=no
fi
fi
@@ -886,7 +887,8 @@
ln conftest.a conftest.b 2>/dev/null && hard_links=no
AC_MSG_RESULT([$hard_links])
if test "$hard_links" = no; then
-AC_MSG_WARN([\`$CC' does not support \`-c -o', so \`make -j' may be unsafe])
+lt_backtick='`' # workaround for "quoted backtick" warning from Autoconf.
+AC_MSG_WARN([${lt_backtick}$CC' does not support ${lt_backtick}-c -o', so
+${lt_backtick}make -j' may be unsafe])
need_locks=warn
fi
else
Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf
| On Oct 11, 2000, Morten Eriksen <[EMAIL PROTECTED]> wrote:
| > Autoconf straight out of CVS will complain about "backquotes and
| > doublequotes should not be backslashed" when expanding the macro code
| > of _LT_AC_LTCONFIG_HACK libtool.m4.
|
| The problem is that CVS autoconf changes the way backquotes are
| interpreted, and issues a warning (even though it works correctly) in
| case they're written the way it used to work with autoconf 2.13.
|
| Replacing \` with ' is even worse, because then the shell won't
| expand the variable within `', as we want it.
That's why Morten used ' only :)
| The only way to do it so that it works with both autoconf 2.13 and CVS
| autoconf, without triggering the warning in CVS autoconf, is this
| (from CVS automake's missing.m4):
|
| am_backtick='`'
| AC_MSG_WARN([${am_backtick}$VAR' ...])
This is s heavy :( As I proposed to Pavel, I'm OK with moving this
warning from `syntax' to `obsolete' for 2.50, and move it back to
`syntax' in 2.51 or later. This way, every body is happy. ?
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf
On Oct 12, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> This is s heavy :( As I proposed to Pavel, I'm OK with moving this
> warning from `syntax' to `obsolete' for 2.50, and move it back to
> `syntax' in 2.51 or later.
Probably later :-)
> This way, every body is happy. ?
I'm definitely in favor of this change.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> I'm definitely in favor of this change. OK< I consider this an OK and will apply the change directly. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Patch for QNX support for libtool-1.3.5
Libtoolers,
Here's a fix submitted by our QNX engineer to get our product
(Berkeley DB) to work with QNX dynamic libraries. Without this patch,
libtool conservatively builds only static archives.
Apparently QNX uses GNU ld, so the fix is straightforward.
Thank you for reviewing this and incorporating into the next
libtool release, if possible.
- Don
*** ltconfig.orig Thu Oct 12 11:57:19 2000
--- ltconfigThu Oct 12 11:57:28 2000
***
*** 2145,2150
--- 2145,2163
fi
;;
+ local change for Sleepycat DB:
+ # Add in the QNX support from QNX.
+ nto-qnx)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}.so$versuffix
+${libname}${release}.so$major $libname.so'
+ soname_spec='${libname}${release}.so$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ deplibs_check_method='pass_all'
+ ;;
+
*)
dynamic_linker=no
;;
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Anderson[EMAIL PROTECTED]
Sleepycat Software Inc. +1-978-287-4781
394 E. Riding Dr. http://www.sleepycat.com
Carlisle, MA 0174
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: OK. Here's the prototype ltmain.c....
Alexandre Oliva wrote: > ... > - it makes it harder for someone who finds a problem in ltmain to > attempt to fix it, since they get (in the final package) someone even > farther from the original sources As it stands, they only see the same script they see now. If they propose a fix, I do not think it very hard to determine which of the lt_*.def files contains the original text. The pieces are mostly separated by a " mode$" pattern. :-) In the future, I anticipate abstracting the command line option processing for the various "modes" into a table of sorts. >From that table, I will derive a shell script and a program. At the moment, the table and program are very simple (albeit large). > - in order to compile something to run on the build machine, we need a > BUILD compiler; CC won't do because it may be a cross compiler. We > may need a special `configure' step to (i) find a BUILD compiler, in > case one is available, and (ii) detect properties of that > compiler and build environment A couple of options: 1) Have an installable libtool binary that does *not* ship with libtool client product. Instead, libtool client configury detects its presence and uses it in preference to the bundled script. It may need to be told of alternate config info in the event of a cross build. Version detection may be needed, too. 2) Ship both the script and .c with client products. If a cross build is configured with no findable build machine (non-cross) tools available, then the script is used. Otherwise, build the binary. It *could* be used in conjunction with an installed binary, too. Probably harder to configure and certainly more baggage for client products. 3) Probably other permutations I'm not thinking of. I think I like pure option #1. A package will always have its shell script implementation as fallback, but if a build environment has installed the binary, they get a huge pay back in build times. In any event, the maintenance of the command option handler table will be easier to comprehend than the current billion line script. (Witness the inclhack.def file vs. the fixincludes script.) How about if I add a ``--mode=bug'' to ltmain and cause it to get some information from the user and package up a bug report, replete with attachments and config information? > I don't want to sound like I'd reject any proposal for a compiled > ltmain (or maybe I'm just missing something obvious), but I fail to > see how we could evolve this into something that would work better in > C than as a shell-script. "work better"? Well, I guess that depends on definitions. I assert, "easier to maintain and comprehend". Ultimately, there ought to be some sort of table that says for a given command line option to one of the supported build tools; or for a given build environment state (e.g. shared libs or no shared libs): 1. do something (a scriptlet) before the command runs 2. transform the argument in a well specified way 3. do something after the command runs Each of these would have an implementation in both C and Bourne shell that would produce identical results. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: OK. Here's the prototype ltmain.c....
On Oct 12, 2000, Bruce Korb <[EMAIL PROTECTED]> wrote:
> If they propose a fix, I do not think it very hard to determine
> which of the lt_*.def files contains the original text.
> The pieces are mostly separated by a " mode$" pattern. :-)
It sounds like we have a volunteer :-) :-)
> 2) Ship both the script and .c with client products.
I think that's the only reasonable solution. There could be some
declaration in configure.in that would cause the script to be omitted
(something like AC_NO_CROSS, that would reject any attempt to cross
compilation)
> I think I like pure option #1. A package will always have its shell
> script implementation as fallback, but if a build environment has
> installed the binary, they get a huge pay back in build times.
I doubt it's that much pay back. Also, you have to bear in mind that
default behaviors of libtool change depending on macros called in
configure.in and arguments given to configure. So a pre-compiled
libtool can't be used in general.
> How about if I add a ``--mode=bug'' to ltmain and cause it to
> get some information from the user and package up a bug report,
> replete with attachments and config information?
We seldom get bug reports like that. Much more often, we get requests
for enhancements, new ports, fixes or suggestions.
>> I fail to see how we could evolve this into something that would
>> work better in C than as a shell-script.
> "work better"?
Not a good word choice, indeed. I meant I'm not sure the added
complexity of maintenance would pay off the potential gains in
run-time speed. But then, libtool is barely maintainable as it is, so
any efforts to move it to higher level constructs is welcome.
Unfortunately, that's not what I see in your proposed implementation;
pretty much everything is still there. But, as you say, it's just a
start, maybe it can be worked out, and I'm just being overly
pessimistic. Not that unusual :-) :-)
> there ought to be
> some sort of table that says for a given command line option to one
> of the supported build tools; or for a given build environment state
> (e.g. shared libs or no shared libs):
> 1. do something (a scriptlet) before the command runs
> 2. transform the argument in a well specified way
> 3. do something after the command runs
I fear an explosion of alternatives, that could only be worked out in
an imperative language, as opposed to the declarative nature I see in
autogen.
> Each of these would have an implementation in both C and Bourne shell
> that would produce identical results.
This will be excellent.
But I guess we should start from the multi-language branch of libtool,
aiming at a 1.6 or 2.0 release. Let's not fork off another
development branch from 1.4 (mainline), since this will only cause 1.5
(multi-language) to be delayed, maybe indefinitely. I'd love to see
1.4 out of the door in the very near future, and 1.5 shortly
thereafter.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: OK. Here's the prototype ltmain.c....
Alexandre Oliva wrote: > I doubt it's that much pay back. Also, you have to bear in mind that > default behaviors of libtool change depending on macros called in > configure.in and arguments given to configure. So a pre-compiled > libtool can't be used in general. As I have the hack configured now, it soaks up the configure.in output (grabs variable definitions from the output libtool file) and parses the same command line arguments. So, the behavior *does* depend on the configure.in stuff > Unfortunately, [improved maintenance is] not what I see in your > proposed implementation; pretty much everything is still there. > But, as you say, it's just a start, maybe it can be worked out, > and I'm just being overly pessimistic. Not that unusual :-) :-) I could be overly optimistic. Not that unusual. ;-) But, I *am* pretty confident that the tables I describe are doable. > > there ought to be > > some sort of table that says for a given command line option to one > > of the supported build tools; or for a given build environment state > > (e.g. shared libs or no shared libs): > > > 1. do something (a scriptlet) before the command runs > > 2. transform the argument in a well specified way > > 3. do something after the command runs > > I fear an explosion of alternatives, that could only be worked out in > an imperative language, as opposed to the declarative nature I see in > autogen. There would be an explosion of alternatives only if there were a need. It is true I have an inclination towards the declarative side. I want it to be possible to specify what needs to happen for a particular context (command option or environment) to be as simple as it can be. (Unlike some of my sentences.;) Those simple expressions drive whatever complexity is necessary to create both a script and program: > > Each of these would have an implementation in both C and Bourne shell > > that would produce identical results. > > This will be excellent. > > But I guess we should start from the multi-language branch of libtool, > aiming at a 1.6 or 2.0 release. Let's not fork off another > development branch from 1.4 (mainline), since this will only cause 1.5 > (multi-language) to be delayed, maybe indefinitely. I'd love to see > 1.4 out of the door in the very near future, and 1.5 shortly > thereafter. OK. I grabbed the default branch because it was handy. What branch should I specify? I would like to see the *start* of the implementation immediately because it will have no visible effect on the product but *will* enable my branch to track updates. :-) Cheers, Bruce ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Fix for bootstrapping with latest CVS Autoconf
On Thu, Oct 12, 2000 at 12:38:11PM +0200, Morten Eriksen wrote: > > BTW, I noticed something which looks a bit strange to me. Beginning at > approximately line 2180 of libtool.m4 (from the head CVS branch), > there are a lot of shell variables which are set up. But some of them > are just set to their current value, for instance like this: > > [...] > # The host system. > host_alias=$host_alias > host=$host > [...] > # A symbol stripping program > STRIP=$STRIP > > # Used to examine libraries when file_magic_cmd begins "file" > MAGIC_CMD=$MAGIC_CMD > > # Used on cygwin: DLL creation program. > DLLTOOL="$DLLTOOL" > > # Used on cygwin: object dumper. > OBJDUMP="$OBJDUMP" > > # Used on cygwin: assembler. > AS="$AS" > [...] > > ..etc, etc. What is the point in doing this? It's all part of a big here document that writes the results of the tests run by libtool.m4 to the start of the generated libtool script. For example libtool.m4 contains tests which discover that on the host system, MAGIC_CMD needs to be /usr/bin/file, so it writes the following snippet into the libtool script: # Used to examine libraries when file_magic_cmd begins "file" MAGIC_CMD="/usr/bin/file" And that, in turn is generated by the here document you quoted above. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: OK. Here's the prototype ltmain.c....
On Oct 12, 2000, Bruce Korb <[EMAIL PROTECTED]> wrote:
> What branch should I specify?
multi-language-branch
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: OK. Here's the prototype ltmain.c....
Alexandre Oliva wrote: > > Each of these would have an implementation in both C and Bourne shell > > that would produce identical results. > > This will be excellent. > > But I guess we should start from the multi-language branch of libtool, Done. See: ftp://linuxave.net/pub/ltmain.tgz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
