Hi Peter,
* Peter Rosin wrote on Sat, Oct 02, 2010 at 11:33:02PM CEST:
> Den 2010-10-02 13:53 skrev Ralf Wildenhues:
> > Yes. Well, we might get the odd report about the Cygwin non-binmode
> > mount where the CR NL messes up things, but otherwise, it should work.
>
> If you are on a text mount, it should fixup CR NL issues. If you have
> CR NL files on a binary mount you deserve to suffer. So, a non-issue.
Cool. Thanks.
> I used 250 at the limit in the test as the 79 characters from the string
> splitter in ltmain might be doubled due to C string escapes and then I
> added some extra margin for quotes and the ", f);" trailer. Still below
> 255 which might be an arbitrary limit in some grep implementations.
You can assume close to 2K as minimum limit for grep.
(Hmm, wonder why we didn't ever write down the value in autoconf.texi)
The patch is OK with nits addressed.
> --- a/tests/cwrapper.at
> +++ b/tests/cwrapper.at
> @@ -134,3 +134,53 @@ done
>
> AT_CLEANUP
>
> +
> +AT_SETUP([cwrapper string length])
> +
> +eval "`$LIBTOOL --config | $EGREP '^(objdir)='`"
> +
> +AT_DATA([liba.c],
> +[[int liba_func1 (int arg)
> +{
> + return arg + 1;
> +}
> +]])
> +AT_DATA([usea.c],
> +[[extern int liba_func1 (int arg);
> +int main (void)
> +{
> + int a = 2;
> + int b = liba_func1 (a);
> + if (b == 3) return 0;
> + return 1;
> +}
> +]])
> +
> +AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c liba.c],
> + [], [ignore], [ignore])
> +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -no-undefined ]dnl
> + [-o liba.la -rpath /foo liba.lo],
> + [], [ignore], [ignore])
> +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c usea.c],
> + [], [ignore], [ignore])
> +
> +# make sure PATH is at least 250 chars, should force line breaks in lt-usea.c
> +for i in 25 50 75 100 125 150 175 200 225 250
> +do
> + PATH="$PATH$PATH_SEPARATOR/somewhere-that-eksists-not"
Intended typo 'exists'? ;-)
Does $LIBTOOL or the autotest machinery ever intentionally try to run
commands that won't exist in $PATH within this shell? If so, then we
might get the odd bug report from security-hardened distributions that
complain about read or execute accessses to non-allowed parts of the
file system.
This length doesn't yet trigger the compiler string literal length
limit; not sure whether it should?
Do we have to cater to the case where the environment is very large
already? I'm not sure, we might want to deal with it when crossing
that bridge only, if it's hard to know off-hand.
> +done
> +export PATH
> +
> +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -no-fast-install ]dnl
> + [-o usea$EXEEXT usea.$OBJEXT liba.la],
> + [], [ignore], [ignore])
> +
> +# skip if no cwrapper is generated
> +AT_CHECK([test -f $objdir/lt-usea.c || exit 77])
> +
> +# try to make sure the test is relevant
> +AT_CHECK([grep ' *fputs' $objdir/lt-usea.c > /dev/null])
Rather than redirecting stdout, put [ignore] in the third argument.
> +# check for no overly long fputs
> +AT_CHECK([grep ' *fputs.\{250\}' $objdir/lt-usea.c], [1])
> +
> +AT_CLEANUP
Cheers,
Ralf
