On Wednesday, 03 June 1998, at 23:26:03 (-0500),
Michael Jinks <[EMAIL PROTECTED]> wrote:
> I started off doing tarballs because the E sites generally pointed to them as opposed
> to rpm's, but somebody else advised me to stick to rpm's. At any rate, many of the
> libraries have been compiled 'by hand', all have been rpm'ed, therefore some have
> gotten it from both ends, so to speak.
If you have RedHat and all, RPM may be fine. But I actually enjoy compiling
and installing stuff myself, and even hacking around with stuff to make it
work. (Once in awhile, not all the time.)
> This is curious. For example:
>
> [root@fred /root]# file /usr/lib/libtif*
> /usr/lib/libtiff.a: current ar archive
> /usr/lib/libtiff.so: symbolic link to libtiff.so.3.4
> /usr/lib/libtiff.so.3: symbolic link to libtiff.so.3.4
> /usr/lib/libtiff.so.3.4: ELF 32-bit LSB shared object, Intel 80386, version 1, not
> stripped
>
> [root@fred /root]# ldconfig -v | grep tiff
> libtiff.so.3 => libtiff.so.3.4
> libtiff.so.3 => libtiff.so.3.4
>
> >From the above, it seems to me that libtiff should show up as present on my box.
> ldconfig also turns up entries for the gif, jpeg, and png libs, but only the gif lib
> showed up as present in configure.h.
Which means that ./configure wasn't able to detect them for one reason or another.
Read the config.log file it generates to see what the errors were. I usually just
put the options in the Makefile myself, but then again, I'm a programmer. :)
I've also been known to edit config.cache by hand to change the "no" for the
libs it didn't find to "yes", then run ./configure again.
> Does this mean that my libs are in funny places? If so, how do I pass that -D option
> -- edit the makefile? Do I give absolute paths? (for example, gcc -D
> /usr/lib/libpng.so.2.1.0)?
The -D<word>[=<value>] option does the same thing as #define. For example,
"-Dlinux -D__REDHAT__=51" on the command line would be equivalent to:
#define linux
#define __REDHAT__=51
> Yup, caught that one myself, and at some point this afternoon all of the lib packages
> he lists in README _did_ compile and install on my box -- at least as far as I could
> tell. Since then I've run ldconfig several times and rebuilt imlib at least twice.
> Still no joy.
ldconfig isn't your problem. You need to look at config.log to see
what went wrong.
> But at least it does appear that we've got the problem tracked down. Definitely
> something up with imlib, definitely compile problems. . . just no idea what to do.
The reason you're not seeing *any* images isn't a compile problem (or
isn't *just* a compile problem), but if you don't do this, you won't
be able to natively load JPG's, PNG's, TIFF's, etc. (Imlib will still
use ImageMagick's convert program as a fall-back, so it will appear
to work, but it's much slower.)
> Just before I got your last, I went through my config.h file and manually hacked all
> the /* #undef . . . */ lines, uncommented them and replaced #undef with #define.
> Having little or nothing to lose, I'm going to go ahead and try it that way and see
> what disaster befalls.
>
> Apparently, I never learn.
You were half-way there. #define'ing the stuff right is half the battle,
but you also have to add the libraries to the link line so that the
code actually makes it in. :)
Michael
--
"Give a man a fish, you feed him for a day. Teach a man to fish, he
spends all his time in the basement tying flies and neglecting his
personal hygiene." -- NewsRadio
=======================================================================
Michael Jennings http://www.tcserv.com/ <[EMAIL PROTECTED]>
Associate Tech Services Analyst I, Vencor IS http://www.vencor.com/
-
To unsubscribe from this list send mail to: [EMAIL PROTECTED]
with the message contents: unsubscribe e-develop
