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 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: [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
