This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: add strnlen to libiberty (was Re: Assembly output optimisations)
- From: Ian Lance Taylor <iant at google dot com>
- To: Dimitrios Apostolou <jimis at gmx dot net>
- Cc: gcc-patches at gcc dot gnu dot org, Andrey Belevantsev <abel at ispras dot ru>, jason at gcc dot gnu dot org, Hans-Peter Nilsson <hp at bitrange dot com>, Mike Stump <mikestump at comcast dot net>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Mon, 6 Aug 2012 21:56:03 -0700
- Subject: Re: add strnlen to libiberty (was Re: Assembly output optimisations)
- References: <alpine.LNX.2.02.1208070228080.20463@localhost.localdomain> <alpine.LNX.2.02.1208070728170.20463@localhost.localdomain>
On Mon, Aug 6, 2012 at 9:34 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> As an addendum to my previous patch, I made an attempt to properly add
> strnlen() to libiberty, with the code copied from gnulib. Unfortunately it
> seems I've messed it up somewhere since defining HAVE_STRNLEN to 0 doesn't
> seem to build strnlen.o for me. Any ideas?
What do you mean by "defining HAVE_STRNLEN to 0"? The thing that will
control building strnlen.o is having AC_REPLACE_FUNCS in
libiberty/configure.in fail to find strlen. One way you can test this
is by adding this to libiberty/config.cache:
ac_cv_func_strnlen=${ac_cv_func_strnlen=yes}
before invoking configure.
Ian