Hmmm - only some of the -devel packages (like glibc and zlib) have 64-bit rpms even on the CDs, which leaves me wondering if the issue is with ppc64 RHEL or with MapServer's configure script not understanding that flavor's structure.
On 2/9/07, Doug B <[EMAIL PROTECTED]> wrote:
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? >
