is --with-libexpat-prefix broken?

[Joel Brobecker <brobecker@adacore.com>]

It looks like it:

I tried configuring GDB on sparc-solaris using:
--with-libexpat-prefix=/nile.build/brobecke/exp/libexpat, where
/nile.build/brobecke/exp/libexpat is the prefix where I have
previously installed libexpat.

With gdb-6.7.1, configuring GDB with this --with-libexpat-prefix
was sufficient. The config.log showed:

> configure:6327: checking for libexpat
> configure:6351: gcc -o conftest -g -I/nile.build/brobecke/exp/libexpat/include  conftest.c -lncurses -lsocket -lnsl -lm  /nile.build/brobecke/exp/libexpat/lib/libexpat.a >&5
> configure:6357: $? = 0

So as you can see, the path to libexpat was automatically provided
to the GCC command. (the command also shows that I only built the
libexpat archive, but that's just a detail)

With the latest sources, I don't see the -I switch anymore, and
I don't see the path to the archive either. All I see is that configure
tries to build using -lexpat without specifying where the includes
or the library might be found:

> configure:7028: checking for libexpat
> configure:7052: gcc -o conftest -g   conftest.c -lncurses -lsocket -lnsl -lm  -lexpat >&5
> ld: fatal: library -lexpat: not found
> ld: fatal: File processing errors. No output written to conftest
> collect2: ld returned 1 exit status

I'm looking into it, but it's really puzzling. It looks like this
part is taken care of by config/lib-link.m4:AC_LIB_HAVE_LINKFLAGS.
And yet, I don't see a change since 6.7.1 that could likely be
responsible for this change of behavior.

Am I the only who sees this? Perhaps it's pilot error on my end,
although I seem to be following the documentation says I need
to do.

Thanks,
-- 
Joel