Re: Avoid compiler warnings
Eric Blake <[EMAIL PROTECTED]> writes:
> I don't know if this is worth fixing upstream in autoconf,
Just barely. I installed this:
2006-08-22 Paul Eggert <[EMAIL PROTECTED]>
* lib/autoconf/c.m4 (AC_C_CONST): Don't used shadowed vars, to
pacify insanely picky compilers. Problem reported by Eric Blake.
--- lib/autoconf/c.m4 15 Aug 2006 16:24:42 - 1.232
+++ lib/autoconf/c.m4 22 Aug 2006 20:08:44 -
@@ -1437,10 +1437,10 @@ AC_DEFUN([AC_C_CONST],
#ifndef __cplusplus
/* Ultrix mips cc rejects this. */
typedef int charset[2];
- const charset x;
+ const charset cs;
/* SunOS 4.1.1 cc rejects this. */
- char const *const *ccp;
- char **p;
+ char const *const *pcpcc;
+ char **ppc;
/* NEC SVR4.0.2 mips cc rejects this. */
struct point {int x, y;};
static struct point const zero = {0,0};
@@ -1449,11 +1449,11 @@ AC_DEFUN([AC_C_CONST],
an arm of an if-expression whose if-part is not a constant
expression */
const char *g = "string";
- ccp = &g + (g ? g-g : 0);
+ pcpcc = &g + (g ? g-g : 0);
/* HPUX 7.0 cc rejects these. */
- ++ccp;
- p = (char**) ccp;
- ccp = (char const *const *) p;
+ ++pcpcc;
+ ppc = (char**) pcpcc;
+ pcpcc = (char const *const *) ppc;
{ /* SCO 3.2v4 cc rejects this. */
char *t;
char const *s = 0 ? (char *) 0 : (char const *) 0;
@@ -1480,7 +1480,7 @@ AC_DEFUN([AC_C_CONST],
const int foo = 10;
if (!foo) return 0;
}
- return !x[0] && !zero.x;
+ return !cs[0] && !zero.x;
#endif
]])],
[ac_cv_c_const=yes],
Re: Avoid compiler warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [cc'ing autoconf for the first issue, on AC_C_CONST] Hi Ralf, According to Ralf Wildenhues on 8/14/2006 10:01 AM: > Hello Eric, > > * Eric Blake wrote on Fri, Aug 11, 2006 at 06:42:47PM CEST: >> I tried configuring m4 with its --enable-debug switch, which enables various >> -W >> warning options, and combined it with -Werror to forcefully see the >> warnings. > > Nice to have would be the exact list of warnings this enabled on your > system, the system, and the GCC version you used. Plus the config.log > excerpts for the errors you encountered. (This isn't necessary.) Sorry for not thinking of that the first time. I'm on cygwin 1.5.21, gcc 3.4.4, and currently testing CVS automake, autoconf, and libtool. > >> The compilation choked when compiling libltdl. The check for AC_C_CONST is >> now >> obsolete, but warned due to -Wshadow, which made it fail and define const to >> the empty string, and led to all sorts of followon fun. $ ./configure CFLAGS='-Wall -Werror -Wconst' ... checking for an ANSI C-conforming const... no ... $ less config.log ... configure:11121: gcc -c -Werror -Wshadow -Wall conftest.c >&5 conftest.c: In function `main': conftest.c:55: warning: declaration of 'x' shadows a previous local conftest.c:30: warning: shadowed declaration is here conftest.c:61: warning: declaration of 'p' shadows a previous local conftest.c:33: warning: shadowed declaration is here I don't know if this is worth fixing upstream in autoconf, since we have documented that it is obsolete, but it would just be a couple of variable renames to ensure that nothing in AC_C_CONST shadows anything else. >> And the check for how >> to use nm was failing due to -Wmissing-prototypes. Yes, it's probably too >> strict of an environment to sanely compile in normally, but it was easy >> enough >> to patch. OK to apply? Should I try backporting it to 1.5.x as well? $ ./configure CFLAGS='-Werror -Wmissing-prototypes' ... $ less config.log ... configure:6190: checking command to parse /usr/bin/nm -B output from gcc object configure:6306: gcc -c -Werror -Wmissing-prototypes conftest.c >&5 conftest.c:5: warning: no previous prototype for 'nm_test_func' > > The changes in the first patch are ok provided they have been tested on > MinGW and Cygwin (MinGW exercises lt__dirent.h, right?); please do not > backport them to branch-1-5, though. Easily tested on cygwin. MinGW was harder, but I think I tested it correctly; however, mingw now provides a working dirent.h, so it did not use the WINDOWS fallback. My understanding is the only oddball system without dirent.h now is MSVC, and I don't have access to that compiler (I'm not about to pay money for a non-compliant and proprietary compiler when better ones are freely available, in both senses of the word free). > > * Eric Blake wrote on Fri, Aug 11, 2006 at 08:04:51PM CEST: >> A followon - using LTDL_SET_PRELOADED_SYMBOLS() choked with >> -Wnested-externs. >> >> 2006-08-11 Eric Blake <[EMAIL PROTECTED]> >> >> * libltdl/ltdl.h (lt_preloaded_symbols): Declare outside of a >> nested scope. > > No, please drop this patch. (Rationale: I'm not convinced this > declaration isn't a problem on some w32 system.) OK, I won't touch that part for now. But it does mean that libtool should probably document that using -Wnested-externs is inadvisable when using preloaded libraries with libltdl. > > Cheers, > Ralf > - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE60MU84KuGfSFAYARAsPzAKCZIsZngZiHco40KHXI5+ahPOtrYACdHB3q sBD1JL9PpL/feTpByyrY4VE= =TDZc -END PGP SIGNATURE-
head: avoid space-tab in libtool.m4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Applying this as obvious, as emacs nearly corrupted this file while I was
editing it by trying to convert space-tab to plain tab.
2006-08-22 Eric Blake <[EMAIL PROTECTED]>
* libltdl/m4/libtool.m4: Avoid space-tab.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE6z8o84KuGfSFAYARAsYGAJ0dVqUu1D9S5hOdz+/JuafHKykcSwCgxg7I
Bu89t6n+Zk7eqXIgu620cc8=
=K/Nj
-END PGP SIGNATURE-
Index: ChangeLog
===
RCS file: /sources/libtool/libtool/ChangeLog,v
retrieving revision 1.2317
diff -u -p -r1.2317 ChangeLog
--- ChangeLog 7 Aug 2006 16:25:08 - 1.2317
+++ ChangeLog 22 Aug 2006 17:28:20 -
@@ -1,3 +1,7 @@
+2006-08-22 Eric Blake <[EMAIL PROTECTED]>
+
+ * libltdl/m4/libtool.m4: Avoid space-tab.
+
2006-08-07 Ralf Wildenhues <[EMAIL PROTECTED]>
* libltdl/config/ltmain.m4sh (func_mode_execute): Also search
Index: libltdl/m4/libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.78
diff -u -p -r1.78 libtool.m4
--- libltdl/m4/libtool.m4 3 Aug 2006 14:06:36 - 1.78
+++ libltdl/m4/libtool.m4 22 Aug 2006 17:28:21 -
@@ -1422,7 +1422,7 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d
sysv5* | sco5v6* | sysv4.2uw2*)
kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
if test -n "$kargmax"; then
- lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ ]]//'`
+ lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[]]//'`
else
lt_cv_sys_max_cmd_len=32768
fi
@@ -1655,7 +1655,7 @@ else
if test "x$lt_cv_dlopen_self" = xyes; then
wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS
$lt_prog_compiler_static\"
AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
- lt_cv_dlopen_self_static, [dnl
+ lt_cv_dlopen_self_static, [dnl
_LT_TRY_DLOPEN_SELF(
lt_cv_dlopen_self_static=yes, lt_cv_dlopen_self_static=yes,
lt_cv_dlopen_self_static=no, lt_cv_dlopen_self_static=cross)
@@ -3211,7 +3211,7 @@ for ac_symprfx in "" "_"; do
" s[1]~prfx {split(s[1],t,\"@\"); print t[1], substr(t[1],length(prfx))}"\
" ' prfx=^$ac_symprfx]"
else
-lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[
]]\($symcode$symcode*\)[[ ]][[
]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
+lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[
]]\($symcode$symcode*\)[[ ]][[
]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
fi
# Check to see that the pipe works correctly.
@@ -4299,10 +4299,10 @@ _LT_EOF
# need to do runtime linking.
case $host_os in aix4.[[23]]|aix4.[[23]].*|aix5*)
for ld_flag in $LDFLAGS; do
- if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl"); then
- aix_use_runtimelinking=yes
- break
- fi
+ if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl"); then
+ aix_use_runtimelinking=yes
+ break
+ fi
done
;;
esac
@@ -4330,19 +4330,19 @@ _LT_EOF
# below for broken collect2 doesn't work under 4.3+
collect2name=`${CC} -print-prog-name=collect2`
if test -f "$collect2name" &&
- strings "$collect2name" | $GREP resolve_lib_name >/dev/null
+ strings "$collect2name" | $GREP resolve_lib_name >/dev/null
then
- # We have reworked collect2
- :
+ # We have reworked collect2
+ :
else
- # We have old collect2
- _LT_TAGVAR(hardcode_direct, $1)=unsupported
- # It fails to find uninstalled libraries when the uninstalled
- # path is not listed in the libpath. Setting hardcode_minus_L
- # to unsupported forces relinking
- _LT_TAGVAR(hardcode_minus_L, $1)=yes
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
- _LT_TAGVAR(hardcode_libdir_separator, $1)=
+ # We have old collect2
+ _LT_TAGVAR(hardcode_direct, $1)=unsupported
+ # It fails to find uninstalled libraries when the uninstalled
+ # path is not listed in the libpath. Setting hardcode_minus_L
+ # to unsupported forces relinking
+ _LT_TAGVAR(hardcode_minus_L, $1)=yes
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+ _LT_TAGVAR(hardcode_libdir_separator, $1)=
fi
;;
esac
@@ -4353,8 +4353,8 @@ _LT_EOF
else
# not using gcc
if test "$host_cpu" = ia64; then
- # VisualAge C++, Version 5.5 for AIX 5L for IA-64, Beta 3 Release
- # ch
Re: Preloading without .la
Another reminder...
Pierre Ossman wrote:
> I guess this issue got lost somewhere. As the issue persists for me and
> I'd rather not use a homebrew build environment, I'd still like this to
> be resolved.
>
> Rgds
> Pierre
>
> Pierre Ossman wrote:
>> Ralf Wildenhues wrote:
>>> [ Let's move this to libtool-patches
>>> Note also the list server may not come back up for a few days. ]
>> Major breakage?
>>
>>> Hi Pierre,
>>>
>>> Sorry for the delay.
>>>
>> No problem.
>>
>>> * Pierre Ossman wrote on Fri, Jan 27, 2006 at 05:30:22PM CET:
I've put together a suggestion (against 1.5 branch, but the
difference shouldn't be that big compared to HEAD) for this.
>>> Many thanks for your effort! I'm not convinced yet that this is the way
>>> to go, on the contrary, I have real doubts, but at least this is a start.
>>>
>> Fair enough. Just as long as we're moving forward in some sense since
>> this is an actual problem for me.
>>
What it does is strip ${libext} from the name and, if we're on a
$need_lib_prefix system, applies a command that should reverse the
effect of $libname_spec. It then appends the '.la' extension.
>>> *snip*
>>>
>>> OK. But the '.la' extension should be necessary for preloading only.
>>>
The effect is that preloading and "normal" loading will work for any
application that uses the platform independent ways of loading:
>>> Yep.
>>>
Any programs that uses lt_dlopen("module.a") will break with this
patch. But I would consider such a call unsupported since they've
been mucking about in libtool internals to figure out that name.
>>> My tests show that also lt_dlopen("module.la") may fail on some systems.
>>>
>> Can you point me to what test you did to break this?
>>
The is another breakage caused by the fact that libtool special cases
the 'lib' prefix. dlpreopening a module called libfoo on a
$need_lib_prefix system with a prefix of 'lib' will not work. The
reason is that the above magic cannot tell the difference between
'libfoo' and 'foo' (which will be transformed to 'libfoo') on such a
system.
>>> I'm still afraid this will cause user breakage. You can neither expect
>>> the user to use the prefix nor to omit it. It's much too useful to be
>>> able to dlopen "regular libraries", this feature is used often.
>>>
>> Hmm... I don't really know how to solve this. The information that the
>> prefix was added automatically will not always be available (we might be
>> linking in a lib without a .la file).
>>
>> It might be possible to be more clever by modifying the loading routines
>> in libltdl. But I wanted to explore the option of just changing the
>> build environment first.
>>
>> What we could do is have libprefix actually be a prefix (not a command
>> which can do all kinds of funky stuff). That prefix could then be built
>> into libltdl so that if will try adding it when looking for the module.
>>
Please review and comment. If it looks good I'll make a patch for
HEAD and try to do some test cases.
>>> The naming is a bit inconsistent: we use `*_cmds' for `~'-separated
>>> lists of commands -- yes, shrext_cmds is a bad counter example, and
>>> should be fixed, too. It should either be libname_rev, since it's
>>> not a command at all, or ltmain should be able to cope with (multiple)
>>> commands in there. (This is documented in libtool.texi, too.)
>>>
>>> Have you tested it? I tested something like the patch below (after the
>>> forward port of your patch). There are several ugly details to be aware
>>> of: Inside the backquotes in libname_rev, you may not use double quotes.
>>> This is because the config.status escaping would then lead to
>>> "`..\"..\"..`"
>>> which is not portable. Also, to use $Xsed, you should add an X,
>>> and an `-e'. ;-)
>>>
>> Fluff ;)
>>
>> The code is still a bit hackish until we have a principle that's correct.
>>
>>> The patch below is missing at least documentation of `libname_rev' in
>>> libtool.texi, and some decent tests, beside the cheap one.
>>>
>>> For me this breaks mdemo-exec.test after mdemo-static.test on GNU/Linux
>>> (without any further modifications). You can simulate need_lib_prefix
>>> by help of the attached patch (which I won't apply ATM because I don't
>>> know whether it's safe). The patch creates a test which itself creates
>>> a new build tree for Libtool, changes need_lib_prefix, configures mdemo,
>>> (mdemo-conf, not mdemo-static), changes need_lib_prefix there, then
>>> builds. Adjust as needed.
>>>
>> I couldn't get your attached test to work, but I did it manually and
>> produced the problem. The issue is that libltdl tries to compensate for
>> the added prefix, and since we now strip that things break.
>>
>> So it seems the smoothest course is to modify the preload routines in
>> ltdl. I see two options here:
>>
>> * Keep the preload name in the new form. Have lt_dlopen(name) try first
>>with name, then with lib_prefix + name.
>>
Re: [Mingw-users] libtool, dlls and -lm
Gary V. Vaughan wrote: > Ralf Wildenhues wrote: >> OK to apply this patch? > > Yes please! > >> * libtool.m4 (AC_DEPLIBS_CHECK_METHOD) [ mingw, pw32 ]: >> If `file' is present, use `func_win32_libid' rather than >> `objdump -f', to facilitate cross-compilation. >> Reported by Pierre Ossman <[EMAIL PROTECTED]>. > > Cheers, > Gary. So, what happened with this patch? -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: OpenPGP digital signature
