[Pan-users] Re: Trouble configuring Pan 0.11.4

[Geek]

Hi Duncan!

Thank you so much - got it!

Problem lies within Debian - I noticed lines 9091, 9092 and 9093 of configure
look for "xml-config". In Debian, the file is named "xml2-config" and for some
reson, "xml-config" was stripped from the Debian package of libxml1 (the source
version contains it).

I made a symlink "xml-config" and pointed it to "xml2-config" and Pan's
configure found and OK'd 2.4.19

Now to compile and test ;-)

Sorry if this message ends up out of sequence, I am not getting the mail list
emails - I have to read them from the web :-(

-- 
Gregg "t3h g33k"
http://geek.scorpiorising.ca



Geek posted
<address@hidden>, excerpted
below,  on Sun, 06 Feb 2005 23:56:41 -0800:

> [Current PAN 0.11.2 on Debian woody. libc6 and glibc prevent > 0.11.x. I
> know how to build and install from source on the platform.]

Ouch!  0.11 is old enough few regulars here run it any more.  Hopefully we
can still help you work thru the problem, however.  

Note that I personally don't have any Debian experience, altho as a Gentoo
amd64 user, I'm used to compiling from source and occasionally having to
tweak things to work due to the 64-bit stuff, so I'll attempt to help.

> 0.11.3 or 0.11.4 (I need yEnc!) [give me the following configure error]
> 
> error: libxml 1.8.11 or higher is needed.
> 
> I currently have libxml 1.8.17 [and] 2.4.19.
> 
> I tried the option ./configure --with-gnome-libs=/usr/lib to no avail.

OK, that's the first option I was going to suggest, checking the available
configure command line options for something like that and trying it.  It
seems you've done that...

> It's finding it, it's just not reading the version correctly.
> 
> I have symlinked libxml.so, libxml.so.0 and libxml.so.1 to libxml-1.8.17
> 
> What am I doing wrong here?

I'm not sure it IS finding it.  Are you sure "libxml" is what it would
consider a "gnome lib"?

Anyway... Next step is to check configure.log from the working dir.  It
should have a bunch of stuff that worked... and then this test, with the
error, and a bit more detail, including the line numbers in configure
where the test is.  Following that there will be a generally
surprisingly (for one who hasn't seen it before) loonnnggg dump of all the
various environmental variables at that point, along with all the stuff it
had already tested for either successfully or could work around.

The trick is to go to go to the area of the mentioned line numbers in the
configure script and figure out exactly what it's doing.  You may use the
info from the environment dump to see what the various vars were at that
point, or, since that is often quite large, simply insert a few choice
echo $var debugging statements in the configure script, and rerun it to
see what the vars are at that point, if necessary.

>From there, you should either be able to figure out why it's missing the
lib, and point it at it with the appropriate configure params, or hard
code the path it's looking in, or hard code the results of the test.  Note
that if it's missing the path here, either your results will need to
contain the path, or you'll need to point it at the right place in such a
way that it puts that info in the make files it creates, so the compile
will be able to find the library when it gets to that point, as well. 
Or... once you figure out where it is looking, take a shortcut and put
symlinks there that point to the right place.  <g>

You might not have this problem so frequently on x86, but on amd64, the
problem can often be that the configure is trying to compile some small
test file, but making the wrong assumptions about suitable CFLAGS or some
such for it's test compile.  Thus, it's failing not because it can't find
the library, but because the test compile used the wrong assumptions for
the arch, and correcting its compile assumptions allows it to complete the
test and continue with the configure and then the real compile.

Of course, another frequent problem on amd64 is that it's looking in a
lib dir instead of lib64, for shared objects and the like, or in lib64
instead of lib, for other files (like headers) typically found in lib. 
However, again, that's not likely to be an issue on x86.

At least if you have decent bash scripting knowledge, and it sounds like
you are a veteran enough on Linux that's hopefully likely, the log pointer
to the appropriate lines in the configure script should at least start you
toward a fix.  Good luck!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html