This is the mail archive of the
mailing list for the GDB project.
is --with-libexpat-prefix broken?
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb at sourceware dot org
- Date: Wed, 27 Feb 2008 15:49:11 -0800
- Subject: is --with-libexpat-prefix broken?
It looks like it:
I tried configuring GDB on sparc-solaris using:
/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