I notice that configure is looking for libfreetype.a and
libfreetype.so in both /usr/lib and /usr/lib64, but my rpm install of
libfreetype-devel only put one in /usr/lib. The rpm install of
libfreetype included both /usr/lib and /usr/lib64 content, but the
-devel package seems to only have /usr/lib content.
Any clues as to what's wrong with this and the other lib install based
on that information? libpng-devel is the same way, and I don't see
any specific 64-bit package names to use.
I do realize this isn't specific to MapServer, but I'll take help
anywhere I can get it. Thanks.
Doug
On 2/5/07, Doug B <[EMAIL PROTECTED]> wrote:
Well, now configure isn't finding other installed rpms like freetype and libpng:
configure: checking where FreeType 2.x is installed...
checking for FT_Init_FreeType in -lfreetype... no
freetype-config or libfreetype cannot be found, possibly needed for GD
freetype-config is in /usr/bin (in the path), and libfreetype.so and
.a are in /usr/lib. libfreetype.so.6 in /usr/lib64.
Details from config.log:
configure:4309: checking where FreeType 2.x is installed...
configure:4427: checking for FT_Init_FreeType in
-lfreetypeconfigure:4457: gcc -o conftest -m64 -fPIC conftest.c
-lfreetype -lm -lstdc+
+ >&5
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/ppc64-redhat-linux/3.4.6/../../../libfreetype.so when
searching for -lfreetype
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/ppc64-redhat-linux/3.4.6/../../../libfreetype.a when
searching for -lfreetype
/usr/bin/ld: skipping incompatible /usr/lib/libfreetype.so when
searching for -lfreetype
/usr/bin/ld: skipping incompatible /usr/lib/libfreetype.a when
searching for -lfreetype
/usr/bin/ld: cannot find -lfreetype
collect2: ld returned 1 exit status
LDFLAGS=-L/usr/lib64 doesn't seem to make a difference either.
I apologize for the ignorance I'm displaying here. I just never had
to delve into issues like this on our previous systems, so I'm not
sure where to even begin.
On 2/5/07, Doug B <[EMAIL PROTECTED]> wrote:
> Setting CFLAGS environment variable seems to have worked, FWIW. If
> there's a safer mechanism, I'd be happy to use that too.
>
> On 2/5/07, Doug B <[EMAIL PROTECTED]> wrote:
> > Hmmm - gcc -m64 does not report that error. What's the best way to
> > use that flag in configure?
