One of the easiest things to do is if a CPAN install fails, then you go to 
your .cpan directory (which should be $HOME/.cpan, usually /root/.cpan for 
most situation), go to the builds subdirectory. You will find a complete copy 
of the package you were building there in an appropriately named 
subdirectory. Just go into that subdir and recite the magic incantation:

perl Makefile.PL
make
make test
make install

Obviously make test will gripe at you in this case.

If for some reason you don't have or cannot find the package left by CPAN, 
just go to www.perl.org, in the 'Searching' subheading there click on 'CPAN 
modules, distributions, and authors' and search for whatever module you want, 
"AxKit' in this case. A nice page comes up where you can download the 
tarball. Expand it, and do as above.

> Which means I already have libghttp-1.0.9-7 installed as RPM.
> So presumably I don't need to install HTTP::GHTTP...right?

Mmmm, no, you still need it if you are going to use GHTTP because thats the 
perl bindings, libghttp is the C library part of it. Honestly I've had worlds 
of problems getting that module to install properly from RPM on Mandrake. 
RedHat may be different but its not a VITAL module to have, esp for dev/demo 
purposes. AxKit falls back to libwww based functions which though not as 
efficient manage to do the trick fine.

> > using fallback values for LIBS and INC
> > options:
> >   LIBS='-L/usr/local/lib -L/usr/lib -lghttp'
> >   INC='-I/usr/local/include -I/usr/include'
> > If this is wrong, Re-run as:
> >   $ /usr/bin/perl Makefile.PL LIBS='-L/path/to/lib'
> > INC='-I/path/to/include'
>
> How would I go about finding out what paths these should be?
> Maybe irrelevant if I don't actually have to install this anyway.

Well, RPMs on RedHat(ish) systems all go into /usr/include for headers and 
/usr/lib for binary libs. Some have subdirectories, so Apache headers are in 
/usr/include/apache for instance. I've had some instances where installing 
libapreq I had to specify those libs with args to Makefile.PL, but recent 
versions of Mandrake at least seem to have RPMs that fix that problem. 

> TransferLog error is gone (actually TransferLog has been in there since
> Apache was the Netscape httpd I think, back in the days when the result
> of every GET was still referred to as a transfer :-), but now it
> complains

Mmm, Apache was NCSA HTTPD. Nescape HTTPD was its own thing, and good riddance 
too! I had to support it for a couple of clients on IRIX. It was a real 
turkey. In theory it was a very nice web services platform, but the 
implementation was kaka. 

> Gnome? Good grief. Whose bright idea was that?
> Gnome seems to have some problems...certainly in
> gnome-config, which is sitting there in /usr/bin
> since RH9 installed Gnome as well as KDE when I
> didn't ask for it :-)

Well, thats one of the problems with libghttp... Its part of the gnome 
libraries and those things are all intertwined. Its the same way on Mandrake 
9.1, to get libghttp from RPM you basically have to install an entire gnome 
desktop. :(. 

> says:
> > Syntax error on line 812 of /home/httpd/conf/httpd.conf:
>
> (which says PerlModule AxKit)
>
> > Can't load
> > '/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/AxKit/AxKit.
> >so' for module AxKit:
>
> # ls -l
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/AxKit
> total 296
> -r--r--r--    1 root     root            0 Jul 19 01:25 AxKit.bs
> -r-xr-xr-x    1 root     root       296862 Jul 19 01:25 AxKit.so
>
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/AxKit/AxKit.so:
> undefined symbol: libiconv_close at
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi/DynaLoader.pm line 229.
>
> > at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/AxKit.pm
> > line 32
> > BEGIN failed--compilation aborted at
> > /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/AxKit.pm line
> > 32.
> > Compilation failed in require at (eval 4) line 3.

Hmmm, there may be other people that can tell you right off the reason for 
this but it looks like your AxKit binary (AxKit.so) is not managing to 
dynamically link to the libiconv. One place to start is to try:

ldd -d -r AxKit.so

which should list every library and function which it tries to link to. I 
don't see the iconv libs listed in the output for my 1.6.1, so its probably a 
subdependency. My recollection is that that API is accessed via libc, but 
maybe I'm completely in left field on that one... Perhaps its even statically 
linked on my system, I really don't know without some real poking around, but 
ldd is usually the place to start with that.

>
> Back to square one which I originally posted about weeks ago.
> libiconv is obviously too broken in RH9 to be usable.
>
> David, how did you overcome this lot?
>
> ///Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Tod Harter
Giant Electronic Brain
http://www.giantelectronicbrain.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to