Re: mdemo ltdl failure
Hi Charles,
* Charles Wilson wrote on Thu, Apr 19, 2007 at 03:02:08AM CEST:
This is because the test is just too ugly for words, not to mention
brittle. Trying to tease out malloc issues outside of a dedicated malloc
testsuite is just plain silly.
I think the biggest problem with the previous patch was that it was
relying so much on undefined behavior, that is not only undefined by any
relevant standard, but also likely to be explicitly treated in very
unpredictable ways by different systems/compilers.
TESTING:
[...]
Re-ran all of these tests under the specified conditions. Same results as
the original patch.
Thanks.
(4) linux (whose system argz is OK)
--detects success, builds using system argz, works.
(5) linux, but with $lt_cv_sys_argz_works=no.
--doesn't run the test, and builds using libltdl argz. works.
(6) mingw, which doesn't have any system argz facility at all
--the test is not run
--builds successfully with libltdl's argz
Did not run these tests. configury and sourcecode paths unchanged from
original path so these should obviously still work. But I'll retest if
desired.
It's a good choice of testing, and should be done again with the final
patch. Plus one test on Solaris with its /bin/sh. (Just noting this,
I can probably do these tests then.)
Some comments to the patch:
--- libltdl/m4/argz.m425 Mar 2006 11:05:02 - 1.3
+++ libltdl/m4/argz.m417 Mar 2007 06:09:50 -
[...]
+os_ver=$(uname -r | $SED -e 's,^\([[0123456789\.]]*\).*,\1,')
+os_major=${os_ver%%\.*}
+os_micro=${os_ver##*\.}
+os_minor=${os_ver%\.*}
+os_minor=${os_minor##*\.}
You can not use the $(cmd) and the ${var%%pattern} constructs, Solaris'
shell will barf when parsing the code (i.e., even if it's inside a
conditional branch that is not executed). Use `cmd` and sed or expr
instead, see the Autoconf manual's chapter on portable shell.
+AS_IF([test $os_major -gt 1],[lt_cv_sys_argz_works=yes],dnl
+ [test $os_minor -gt 5],[lt_cv_sys_argz_works=yes],dnl
+ [test $os_micro -gt 24],[lt_cv_sys_argz_works=yes],dnl
No need for double quoting the literal integers. And if it can happen
that $os_micro is the empty string (which I'll consider quite likely),
then double quoting isn't enough precaution against error output, as
isn't interpreted by test as a number.
BTW, what are all the dnl's here for? If they're necessary in some way,
that would indicate that AS_IF had a bug. Ahh, that reminds me, AS_IF
has only been made n-ary in 2.60, and we intend to support 2.59. Please
use plain `if..else' or nested AS_IF instead, thanks.
Cheers, and thank you for your work,
Ralf
Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source
* Charles Wilson wrote on Thu, Apr 19, 2007 at 06:13:19AM CEST: Test results -- new tests. Unexpected failures: 14: Java convenience archives FAILED (convenience.at:273) 16: Link order of deplibs. FAILED (link-order2.at:129) 49: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:42) are actually not unexpected on cygwin. And certainly have nothing to do with this patch. Actually, I think this is may be the best test conformance I've ever seen on cygwin... I think I saw the new testsuite passing on Cygwin at one point. Could you post tests/testsuite.log (gzipped if it's large)? Thanks, Ralf
Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source
* Charles Wilson wrote on Thu, Apr 19, 2007 at 03:55:20AM CEST: [Added libtool-patches to CC list. Discussion of this patch should probably drop libtool and cygwin] Done. Okay, here's the first bit. It's pretty simple. Testing is in progress (and in conjuction with the new argz fix I just posted to libtool-patches), but looks good so far: the new wrapper scripts are identical to old ones generated without this patch. Thanks. Please resubmit with the new functions moved to right before func_mode_link (or func_mode_install/func_mode_execute, in case you intend to use them from inside them in a followup patch); there's a real performance benefit to doing this for compile mode, as it saves the shell from having to parse the functions in that case. It may be lost in the fork/exec overhead on w32, but on GNU/Linux, libtool compile mode overhead is dominated by shell parsing (see the 2007-02-11 changes for a 30% execution time reduction this way). Also, please use round parentheses as per GCS for referring to functions in the ChangeLog entry. I'll apply the reposted patch then. Cheers, and thanks again, Ralf 2007-04-18 Charles Wilson [EMAIL PROTECTED] * libltdl/config/ltmain.m4sh [func_mode_link]: move wrapper script writing from here... [func_emit_libtool_wrapper_script]: to this new function, and write to stdout [func_mode_link]: move cwrapper source code writing from here... [func_emit_libtool_cwrapperexe_source]: to this new function, and write to stdout [func_mode_link]: call the two new functions and redirect to appropriate file.
Re: mdemo ltdl failure
Ralf Wildenhues wrote:
* Charles Wilson wrote:
This is because the test is just too ugly for words, not to mention
brittle. Trying to tease out malloc issues outside of a dedicated malloc
testsuite is just plain silly.
I think the biggest problem with the previous patch was that it was
relying so much on undefined behavior, that is not only undefined by any
relevant standard, but also likely to be explicitly treated in very
unpredictable ways by different systems/compilers.
Yes, I knew it was, which was why all error conditions in the test
resulted in the test reporting *success*. I was hoping during
discussion that somebody would have a better suggestion than punt and
use version numbers and explicit OS hacks, even tho that is not the
Autoconf Way. But nobody commented on the patch until I raised it in
private correspondence with BobF. Now, I just don't think there IS any
way of actually detecting the error that isn't horrifyingly ugly.
And I felt really dirty after posting the original patch. :-)
(4) linux (whose system argz is OK)
--detects success, builds using system argz, works.
(5) linux, but with $lt_cv_sys_argz_works=no.
--doesn't run the test, and builds using libltdl argz. works.
(6) mingw, which doesn't have any system argz facility at all
--the test is not run
--builds successfully with libltdl's argz
Did not run these tests. configury and sourcecode paths unchanged from
original path so these should obviously still work. But I'll retest if
desired.
It's a good choice of testing, and should be done again with the final
patch. Plus one test on Solaris with its /bin/sh. (Just noting this,
I can probably do these tests then.)
will do for linux mingw, but have no unencumbered access to solaris at
present.
Some comments to the patch:
--- libltdl/m4/argz.m4 25 Mar 2006 11:05:02 - 1.3
+++ libltdl/m4/argz.m4 17 Mar 2007 06:09:50 -
[...]
+os_ver=$(uname -r | $SED -e 's,^\([[0123456789\.]]*\).*,\1,')
+os_major=${os_ver%%\.*}
+os_micro=${os_ver##*\.}
+os_minor=${os_ver%\.*}
+os_minor=${os_minor##*\.}
You can not use the $(cmd) and the ${var%%pattern} constructs,
[EMAIL PROTECTED] and I checked to make sure those were fully supported by Posix
Shell and weren't just convenient bashisms.
Solaris'
shell will barf when parsing the code (i.e., even if it's inside a
conditional branch that is not executed). Use `cmd` and sed or expr
instead, see the Autoconf manual's chapter on portable shell.
Geez, solaris sux. You think they might consider shipping a posix
compliant /bin/sh sometime this century?
+AS_IF([test $os_major -gt 1],[lt_cv_sys_argz_works=yes],dnl
+ [test $os_minor -gt 5],[lt_cv_sys_argz_works=yes],dnl
+ [test $os_micro -gt 24],[lt_cv_sys_argz_works=yes],dnl
No need for double quoting the literal integers. And if it can happen
that $os_micro is the empty string (which I'll consider quite likely),
then double quoting isn't enough precaution against error output, as
isn't interpreted by test as a number.
Okay, but actually, all cygwin releases are guaranteed to have non-empty
major, minor, and micro numbers -- and we're inside a $host_os == cygwin
block, here. If I update the os_* variable assignments with protection
against empty (default to 0?), I'll move it outside the case block so
that if any other bad systems are discovered they can be added more
easily -- although I doubt that there are any.
BTW, what are all the dnl's here for? If they're necessary in some way,
that would indicate that AS_IF had a bug.
Habit. I'll remove 'em all and see what breaks.
Ahh, that reminds me, AS_IF
has only been made n-ary in 2.60, and we intend to support 2.59. Please
use plain `if..else' or nested AS_IF instead, thanks.
That'll teach me to read the manual. I didn't realize it was n-ary until
I did so, and thought: Cool! Never realizing I was reading the 2.61
manual...
--
Chuck
Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source
Ralf Wildenhues wrote: * Charles Wilson wrote: Test results -- new tests. Unexpected failures: 14: Java convenience archives FAILED (convenience.at:273) 16: Link order of deplibs. FAILED (link-order2.at:129) 49: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:42) are actually not unexpected on cygwin. And certainly have nothing to do with this patch. Actually, I think this is may be the best test conformance I've ever seen on cygwin... I think I saw the new testsuite passing on Cygwin at one point. ??? that would surprise me. Could you post tests/testsuite.log (gzipped if it's large)? attached. -- Chuck testsuite.log.gz Description: GNU Zip compressed data
Re: mdemo ltdl failure
* Charles Wilson wrote on Thu, Apr 19, 2007 at 08:08:41PM CEST: Ralf Wildenhues wrote: It's a good choice of testing, and should be done again with the final patch. Plus one test on Solaris with its /bin/sh. (Just noting this, I can probably do these tests then.) will do for linux mingw, but have no unencumbered access to solaris at present. I'll do that then. +AS_IF([test $os_major -gt 1],[lt_cv_sys_argz_works=yes],dnl + [test $os_minor -gt 5],[lt_cv_sys_argz_works=yes],dnl + [test $os_micro -gt 24],[lt_cv_sys_argz_works=yes],dnl No need for double quoting the literal integers. And if it can happen that $os_micro is the empty string (which I'll consider quite likely), then double quoting isn't enough precaution against error output, as isn't interpreted by test as a number. Okay, but actually, all cygwin releases are guaranteed to have non-empty major, minor, and micro numbers -- and we're inside a $host_os == cygwin block, here. Oh, I overlooked this fact in my review. Ignore that comment then. Cheers, Ralf
Re: mdemo ltdl failure
* Charles Wilson wrote on Thu, Apr 19, 2007 at 08:08:41PM CEST:
--- libltdl/m4/argz.m4 25 Mar 2006 11:05:02 - 1.3
+++ libltdl/m4/argz.m4 17 Mar 2007 06:09:50 -
[...]
+os_ver=$(uname -r | $SED -e 's,^\([[0123456789\.]]*\).*,\1,')
+os_major=${os_ver%%\.*}
+os_micro=${os_ver##*\.}
+os_minor=${os_ver%\.*}
+os_minor=${os_minor##*\.}
One more thing: please use variables prefixed with lt_, or with gl_.
Also I think the range [0-9] is portable sed.
Cheers,
Ralf
Re: [cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source
Ralf Wildenhues wrote:
Thanks. Please resubmit with the new functions moved to right before
func_mode_link (or func_mode_install/func_mode_execute, in case you
intend to use them from inside them in a followup patch); there's a real
performance benefit to doing this for compile mode, as it saves the
shell from having to parse the functions in that case. It may be lost
in the fork/exec overhead on w32, but on GNU/Linux, libtool compile mode
overhead is dominated by shell parsing (see the 2007-02-11 changes for a
30% execution time reduction this way).
Done. Testing is still in progress (again, in conjunction with updated
argz.m4 patch). However, mdemo works (on all six test variants
described in the argz.m4 messages), and the entire old test suite
passes on cygwin(broken argz kernel: 1.5.24-2).
Also, please use round parentheses as per GCS for referring to functions
in the ChangeLog entry. I'll apply the reposted patch then.
Done.
--
Chuck
2007-04-19 Charles Wilson [EMAIL PROTECTED]
* libltdl/config/ltmain.m4sh (func_mode_link): move wrapper
script generation from here...
(func_emit_libtool_wrapper_script): to this new function, and
write to stdout
(func_mode_link): move cwrapper source code generation from
here...
(func_emit_libtool_cwrapperexe_source): to this new function,
and write to stdout
(func_mode_link): call the two new functions and redirect
output to appropriate file.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.72
diff -u -r1.72 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 2007-04-19 14:51:24.109375000 -0400
+++ libltdl/config/ltmain.m4sh 2007-04-19 14:51:00.96875 -0400
@@ -2209,6 +2209,555 @@
test $mode = install func_mode_install ${1+$@}
+# func_emit_libtool_wrapper_script
+# emit a libtool wrapper script on stdout
+# don't directly open a file because we may want to
+# incorporate the script contents within a cygwin/mingw
+# wrapper executable. Must ONLY be called from within
+# func_mode_link because it depends on a number of variable
+# set therein.
+func_emit_libtool_wrapper_script ()
+{
+ $ECHO \
+#! $SHELL
+
+# $output - temporary wrapper script for $objdir/$outputname
+# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
+#
+# The $output program cannot be directly executed until all the libtool
+# libraries that it depends on are installed.
+#
+# This wrapper script should never be moved out of the build directory.
+# If it is, it will not operate correctly.
+
+# Sed substitution that helps us do robust quoting. It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='${SED} -e 1s/^X//'
+sed_quote_subst='$sed_quote_subst'
+
+# Be Bourne compatible
+if test -n \\${ZSH_VERSION+set}\ (emulate sh) /dev/null 21; then
+ emulate sh
+ NULLCMD=:
+ # Zsh 3.x and 4.x performs word splitting on \${1+\[EMAIL PROTECTED]},
which
+ # is contrary to our usage. Disable this feature.
+ alias -g '\${1+\[EMAIL PROTECTED]}'='\[EMAIL PROTECTED]'
+ setopt NO_GLOB_SUBST
+else
+ case \`(set -o) 2/dev/null\` in *posix*) set -o posix;; esac
+fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+(unset CDPATH) /dev/null 21 unset CDPATH
+
+relink_command=\$relink_command\
+
+# This environment variable determines our operation mode.
+if test \\$libtool_install_magic\ = \$magic\; then
+ # install mode needs the following variables:
+ generated_by_libtool_version='$macro_version'
+ notinst_deplibs='$notinst_deplibs'
+else
+ # When we are sourced in execute mode, \$file and \$ECHO are already set.
+ if test \\$libtool_execute_magic\ != \$magic\; then
+ECHO=\$qecho\
+file=\\$0\
+# Make sure echo works.
+if test \X\$1\ = X--no-reexec; then
+ # Discard the --no-reexec flag, and continue.
+ shift
+elif test \X\`{ \$ECHO '\t'; } 2/dev/null\`\ = 'X\t'; then
+ # Yippee, \$ECHO works!
+ :
+else
+ # Restart under the correct shell, and then maybe \$ECHO will work.
+ exec $SHELL \\$0\ --no-reexec \${1+\[EMAIL PROTECTED]}
+fi
+ fi\
+
+ $ECHO \
+
+ # Find the directory that this script lives in.
+ thisdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*$%%'\`
+ test \x\$thisdir\ = \x\$file\ thisdir=.
+
+ # Follow symbolic links until we get to the real thisdir.
+ file=\`ls -ld \\$file\ | ${SED} -n 's/.*- //p'\`
+ while test -n \\$file\; do
+destdir=\`\$ECHO \X\$file\ | \$Xsed -e 's%/[^/]*\$%%'\`
+
+# If there was a directory component, then change thisdir.
+if test \x\$destdir\ != \x\$file\; then
+ case \\$destdir\ in
+ [/]* | [A-Za-z]:[/]*) thisdir=\\$destdir\ ;;
+ *)
Re: mdemo ltdl failure
Hopefully the attached patch addresses all comments...Recapping: The argz functions (specifically, argz_insert) supplied by cygwin are buggy, in wierd use-dependent malloc-related ways. I've already submitted a patch to newlib to fix that error which has been accepted http://sourceware.org/ml/newlib/2007/msg00271.html but (a) there's no telling when a new cygwin kernel with that fix will be released, and (b) libtool ought to work with any relatively recent cygwin kernel. Testing for actual broken argz behavior, as I did in my first patch http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html is horrendously ugly, brittle, and all-around bad -- even if that is the recommended Way Of Autoconf. This patch is a refinement of an alternative, first proposed here: http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00035.html where we instead check the platform and OS version for the few (only?) known-bad systems which both declare and provide the desired argz functions, but whose argz implementation is broken. The basic idea of this patch is: (1) if argz is found on the system, check to see if the $host_os and os version are such that the system argz is known bad (2) if not, everything is fine (3) if so (currently: cygwin, 1.5.24 or older), then we need to force use of the libltdl-provided argz (a) define a new symbol SYSTEM_ARGZ_IS_BROKEN (b) set ARGZ_H and AC_LIBOBJ, just as if we didn't find argz on the system (c) use SYSTEM_ARGZ_IS_BROKEN in lt__glibc.h along with HAVE_ARGZ_H to determine whether to #define argz* lt__argz* === One other change: you can now force the use of libltdl's argz on any system, which was not possible before when HAVE_ARGZ_H was true. BUT, doing this with HAVE_ARGZ_H true carries some risk: we've already decided whether to #define error_t ourselves, and/or set __error_t_defined, based on what we detected AFTER #including the system's argz.h -- but by forcing the use of libltdl's argz, we won't use the system's argz.h, so at compile-time we might not see what the error_t test saw. Therefore, libltdl's argz_.h needs to include most of the common places where error_t may have been picked up by the system argz.h. On newlib systems, this is errno.h. On glibc systems, this is also errno.h, but you must #define __need_error_t first (which glibc's argz.h does). So, I've modified libltdl's argz_.h to do that, too. This is really a minor issue IMO. If the system argz is found, it should be used except in rare circumstances (like, it's broken). At present, the only known system where this applies is cygwin, and cygwin doesn't need the extra stuff specified in this section. But, trying to be thorough... I've tested argzfix-3.patch (in conjunction with the functionalize wrapper generation patch) under the following conditions: (NOTES: works means that mdemo-conf/mdemo-make/mdemo-exec passes. Also, I checked every libltdl ahd mdemo/mlib shared library explicitly using objdump or nm to determine whether system argz functions were imported, or whether it exported its own replacement argz functions. In each case, the results track with what should be expected, for each of the six test cases below) (1) broken cygwin kernel (1.5.24-2 used, but any older would do) --reports that system argz is broken, builds successfully using libltdl's argz --resultant libraries and mdemo tests also work after dropping in a fixed cygwin kernel. (2) fixed cygwin kernel (official snapshot from 20070330) --reports that system argz works, builds successfully using system argz --resultant libraries coredump if you drop in a broken cygwin kernel after the fact. This is expected: broken cygwin is broken precisely because its argz facility coredumps on argz_insert(). (3) fixed cygwin kernel, but with 'export $lt_cv_sys_argz_works=no'. --reports that system argz does not work (cached), and builds successfully using libltdl's argz --resultant libraries works fine even after dropping in a broken cygwin kernel. (4) linux (whose system argz is OK) --reports that system argz works, builds successfully using system argz, works. (5) linux, but with 'export $lt_cv_sys_argz_works=no'. --reports that system argz does not work (cached), and builds successfully using libltdl's argz (6) mingw, which doesn't have any system argz facility at all --because the argz functions are not declared, the section of the configure script that reports whether system argz works is not even run, nor is the cache checked. configure has already decided to use the libltdl-supplied argz. --and, in fact, build is completed successfully using libltdl supplied argz, and the result works. Also, under case (1), ran the entire testsuite. All old-style tests pass:
Re: mdemo ltdl failure
Charles Wilson wrote: Under case (1), currently running the new-style testsuite. Will report that later in a follow-up message. I expect the following: 14: Java convenience archives FAILED (convenience.at:273) 16: Link order of deplibs. FAILED (link-order2.at:129) 49: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:42) Confirmed. which IMO are longstanding on cygwin, and certainly have nothing to do with either this patch or the 'functionalize wrapper generation' patch. -- Chuck
Re: Linking automatically with dlopen
On Wed, 18 Apr 2007, Bob Friesenhahn wrote: Years ago, I converted ImageMagick to use loadable modules in order to decouple from optional libraries. This did require a clean codec interface but it turned out fine. There are 95 modules, and libldtl is only used if the package is built to use loadable modules. A module loader was developed to keep track of loadable modules. Each module has load/unload routines and registers itself with the library by invoking a module adding function in the main library. Thanks for the tips. I've had a look at the ImageMagick sources, which presumably (and seemingly) still use your scheme, and the good news (for me) is that it looks like I can do what I want without changing my existing modules (which already have a clean interface). Still, it would be nice if it could be done fully automatically, something like: libtool --mode=link --dlopenlink=foo,bar,baz ... If -lfoo, -lbar or -lbaz appears in the command line, the relevant library is not linked against. Instead, a dummy module will be compiled that contains two functions: one that that attempts to open the library and resolves the relevant symbols, which is called on program startup, and another which returns a value saying whether the given library was successfully opened. [Inessential features: it would be nice if the initialisation functions could be called automatically; if not, they could be called by a libtool initialisation function, which means that the total code impact would be just a few lines: #include ltdl.h ... lt_dlinit(); lt_dlautoopen(); ... which has the advantage that the programmer can choose when to take the (in general potentially large) hit of doing the dlopening. It would also be nice if the program could easily test whether an individual symbol had been resolved by testing whether or not it was NULL.] It seems to me that this could be implemented relatively easily: first, call the linker normally, then find out which libraries (if any) in the dlopenlink link have been pulled in, then scan the object to discover which symbols from each library have been imported; generate and compile the appropriate stub, and then perform the link again, without the relevant libraries, but with the stub. I admit that this buys me very little in my particular case: it seems that I can indeed get away with a little build system hackery and merely change the module that knows about all the CODEC and effect modules in SoX. That's nice to learn, and it's probably what I'll do. I'm interested, though, to know whether the general case is worth solving. Perhaps it's not: maybe if your program is dependent on a particular library in lots of places, then you simply have to link against it. I suspect, however, that the same considerations employed to justify aspect-oriented programming could be used to justify the idea that a library could be used in many places in a program (i.e. hard to isolate in the way that ImageMagick or SoX can isolate transforming functions) and yet happily be present or not without making the program break down. It would have to involve a large number of API calls (or you can just proxy them) as well as a large number of modules from which they are called. -- http://rrt.sc3d.org/ | Psalms 19:12 -- tagline for the guilty ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool dll creation (mingw32 undefined symbols)
Hello Richard, Please keep the libtool list in Cc:, thanks. * richard wrote on Thu, Apr 19, 2007 at 05:45:01PM CEST: Typo: -no-undefined (just one leading hyphen). thanks a lot Ralf, this was the only error. the dll compiles and i get a running .exe in ./libs (tested with wine and winXP). hurray. Actually i thought long parameters are supposed to start with -- or at least there should be an error about a undefined command line switch. Yep, there isn't, I guess there should be. But the way libtool works it's almost impossible to do without lots of noise: link mode only allows very few arguments through to the linker command line unchanged, and of those that it drops/needs to drop, it cannot know whether they would have raised a warning or an error with the system's compiler or linker, respectively. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool dll creation (mingw32 undefined symbols)
(resend, because i forgot to CC the list) Typo: -no-undefined (just one leading hyphen). thanks a lot Ralf, this was the only error. the dll compiles and i get a running .exe in ./libs (tested with wine and winXP). hurray. Actually i thought long parameters are supposed to start with -- or at least there should be an error about a undefined command line switch. Look at the mdemo test sources, that's a test that uses libltdl. Is that a little better? Oh great, I will look into this. AC_C_CONST FWIW, I don't think you need AC_C_CONST nowadays. I think this one got added out of panic and frustration - i will remove it. Thanks again, Richard ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dll names on windows
On Sat, Apr 14, 2007 at 11:23:20PM +0100, Max Bowsher wrote: Bob Rossi wrote: I've recently converted pcre's (http://www.pcre.org/) build system to use the autotools. The previous stable version of libtool, pcre-7.0, used to create dll's on mingw. It would create $ ls .libs/*.dll .libs/pcre.dll .libs/pcreposix.dll Now, the new autotools version creates, $ ls ../../pcre-7.1-RC4/prefix-shared/bin libpcre-0.dll libpcrecpp-0.dll libpcreposix-0.dll pcre-config So, now pcre uses the names directly above, which is the default behavior. However, the pcre project would like to provide a backwards compatible dll the user can use if they enable the configure switch --enable-alt-win-dll (or something like that). Is there any way that I can have libtool simply create a dll with the new 'pcre.dll' instead of 'libpcre-0.dll'? Otherwise, I'll have to code into the Makefile some commands to provide the user with what they want. Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Typo in 1.5.22's info manual
Both macros define the shell variables LIBLTDL, to the link flag that you should use to link with libltdl, and LTDLINCL, to the preprocessor flag that you should use to compile with programs that include `ltdl.h'. It is up to you to use `AC_SUBST' to ensure that this variable will be available in `Makefile's... It looks like there are two variables to deal with here, so in the last sentence, this variable should be these variables. -- http://rrt.sc3d.org/ memoir, n. a lie that flatters the author's ego and the reader's intellect ___ Bug-libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-libtool
