is --with-libexpat-prefix broken?

is --with-libexpat-prefix broken?

[Joel Brobecker]

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

Re: is --with-libexpat-prefix broken?

[Daniel Jacobowitz]

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

Re: is --with-libexpat-prefix broken?

[Joel Brobecker]

> 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

Re: is --with-libexpat-prefix broken?

[Daniel Jacobowitz]

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

Re: is --with-libexpat-prefix broken? NOT!

[Joel Brobecker]

> 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