libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Make compilation of preloaded module glue -Wstrict-prototype


From: Ralf Wildenhues
Subject: Re: [PATCH] Make compilation of preloaded module glue -Wstrict-prototypes clean
Date: Sat, 28 Feb 2009 21:30:44 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Lennart, all,

* Lennart Poettering wrote on Sat, Feb 21, 2009 at 04:10:37AM CET:
> When generating the glue code for preloaded modules libtool produces
> invalid prototypes without argument lists. When compiling with
> slightly fascist compiler options (-Wstrict-prototypes) this has the
> effect of causing gcc to print gazillions of warnings when the final
> libtool call is done -- for each symbol one.
> 
> The fix is trivial. The prototypes should have an argument list of void,
> not empty.

Thanks for the bug report and patch.  My issue here is the following:

AFAIK the "extern int function ();" declares a function with an
unspecified number of parameters, rather than one with no parameters.
Now, I don't know whether this has an effect on the generated code
(on some weird system), since of course the thus-declared functions
do not really have zero parameters.  If somebody knows this better,
please speak up!  (Of course us assigning the pointer to such function
to a pointer to void is another ISO C violation in this area, but
let's not get more ambitious than necessary right now.)

Since the code in typical configure link tests like AC_CHECK_LIB or
AC_CHECK_FUNC uses the same idiom, I'm inclined to leave the code the
way it is, and argue that you should not use -Wstrict-prototypes, at
least not in conjunction with -Werror (as that could also cause bogus
configure results).  What we could do, however, would be to remove
any occurrence of -Wstrict-prototypes from the LTCC libtool variable
to avoid the noise during the build.  In that case, I suppose it would
be prudent to also drop alike flags for other compilers we care about.

Cheers,
Ralf

> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4
> @@ -3308,7 +3308,7 @@ esac
>  # Transform an extracted symbol line into a proper C declaration.
>  # Some systems (esp. on ia64) link data and code symbols differently,
>  # so use this general approach.
> -lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int 
> \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
> +lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int 
> \1(void);/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
>  
>  # Transform an extracted symbol line into symbol name and symbol address
>  lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([[^ ]]*\) $/  
> {\\\"\1\\\", (void *) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  
> {\"\2\", (void *) \&\2},/p'"




reply via email to

[Prev in Thread] Current Thread [Next in Thread]