is --with-libexpat-prefix broken?

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

On Wed, Feb 27, 2008 at 03:49:11PM -0800, Joel Brobecker
wrote:
> 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.

This is a horribly overcomplicated macro, originally from
(IIRC)
gettext.  I used it because it was there and worked, but
when it goes
wrong I'm at a loss.  I recommend running the configure
script with
sh -x to see what it's doing.

The only thing I noticed in the above was that there was no
-I option,
but the test file obviously compiled.  Could you have
switched
compilers and/or added an expat installation in
/usr/local/include
and /usr/local/lib?  GCC is ornery about searching
/usr/local/include
but not /usr/local/lib in some configurations.

-- 
Daniel Jacobowitz
CodeSourcery

> This is a horribly overcomplicated macro, originally
from (IIRC)
> gettext.

Thank you for making me feel better, misery loves company
.

> I recommend running the configure script with sh -x to
see what
> it's doing.

I was actually in the process of analyzing the output
yesterday
when I had to scoot out. Will continue today.

> The only thing I noticed in the above was that there
was no -I option,
> but the test file obviously compiled.  Could you have
switched
> compilers and/or added an expat installation in
/usr/local/include
> and /usr/local/lib?  GCC is ornery about searching
/usr/local/include
> but not /usr/local/lib in some configurations.

Duh - You're right. I had switch from the slow AIX to a
faster
sparc-solaris machine, but indeed, libexpat is installed in
/usr/local.
It's still interesting to know that with the same compiler
on the same
machine, 6.7.1 builds fine, whereas HEAD doesn't. And the
cause is
double: No -I, and it doesn't try the archive, it requires
the shared
library...

Back on AIX (sigh), the program doesn't compile, and
configure
gives up immediately. So I can start again from there.
Hopefully
more info on this soon.

-- 
Joel

On Thu, Feb 28, 2008 at 10:28:43AM -0800, Joel Brobecker
wrote:
> Duh - You're right. I had switch from the slow AIX to a
faster
> sparc-solaris machine, but indeed, libexpat is
installed in /usr/local.

We get reports of this for ncurses all the time, too
(configure will
enable the TUI and then it will fail at link time).

-- 
Daniel Jacobowitz
CodeSourcery

> 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.

I think I understand what's going on, now. My checkout was,
for some
reason, missing a bunch of files in the root directory, one
of them
being config.rpath.  I do regular "cvs update" on
my sandbox, but
these files don't seem to get restored by this command - I
had to
explicitly request the update of config.rpath to see it
being restored.

So what I did was do a clean checkout of the sources, which
did
contain the missing files - and things went back to normal.
If
someone else has the same problem, I hope this helps...

-- 
Joel