#11 Compiling on CentOS 5.4 64-Bit ld: skipping incompatible

1.2.2
closed-out-of-date
nobody
opendkim (95)
5
2015-02-23
2010-02-04
James Marcus
No

I am running Cent OS 5.4 64-Bit on VMWARE vSphere 4.0. I have the following relevant software installed (I won't display duplicates of 32 & 64-bit RPMs)

openssl-0.9.8e-12.el5_4.1
openssl-devel-0.9.8e-12.el5_4.1
compat-gcc-34-3.4.6-4
gcc-4.1.2-46.el5_4.1
compat-gcc-34-c++-3.4.6-4
libgcc-4.1.2-46.el5_4.1
postfix-2.3.3-2.1.el5_2
sendmail-8.13.8-2.el5
sendmail-devel-8.13.8-2.el5

./configure worked after I installed the sendmail-devel package which gave me libmilter, I did NOT use any configure switches.
ran make and at the end I get this message:
libtool: link: gcc -std=gnu99 -pthread -I/usr/kerberos/include -g -O2 -pthread -o .libs/opendkim opendkim-opendkim.o opendkim-opendkim-ar.o opendkim-opendkim-arf.o opendkim-opendkim-crypto.o opendkim-opendkim-db.o opendkim-config.o opendkim-stats.o opendkim-test.o opendkim-util.o -L/usr/lib ../libopendkim/.libs/libopendkim.so -L/usr/kerberos/lib64 -lresolv -lmilter -lssl -lcrypto -ldl -lz -pthread -Wl,-rpath -Wl,/usr/local/lib
/usr/bin/ld: skipping incompatible /usr/lib/libresolv.so when searching for -lresolv
/usr/bin/ld: skipping incompatible /usr/lib/libresolv.a when searching for -lresolv
/usr/bin/ld: skipping incompatible /usr/lib/libssl.so when searching for -lssl
/usr/bin/ld: skipping incompatible /usr/lib/libssl.a when searching for -lssl
/usr/bin/ld: skipping incompatible /usr/lib/libcrypto.so when searching for -lcrypto
/usr/bin/ld: skipping incompatible /usr/lib/libcrypto.a when searching for -lcrypto
/usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl
/usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

Please let me know if I need to post any environment variables or output of any commands.

Discussion

  • James Marcus
    James Marcus
    2010-02-04

    Output from configure and make (after a make clean)

     
    Attachments
    • milestone: --> 1.2.2
     
    • assigned_to: nobody --> grooverdan
     
  • Daniel Black
    Daniel Black
    2010-02-05

    as SM indicated on list this is probably a 32/64 bit lib issue.

    I was having trouble replicating this. I got the same 'skipping incompatible' error for libmitler though when I had the sendmail-devel.i386 installed.

    Unfortunately my virtual centos box died. I'll try again when I recover it.

     
  • Daniel Black
    Daniel Black
    2010-02-07

    ok had a look. seems as though we could go with an approach of searching /usr/lib64 before /usr/lib. This will generate the same warning for people installing 32 bit applications where 64bit libs are available. Hopefully thats better. A factorising of all the configure.ac library searching code into its own m4 code is needed as its getting a bit ugly.

     
  • Todd A. Lyons
    Todd A. Lyons
    2010-12-01

    The following builds cleanly on both my 64 bit and 32 bit CentOS 5.x boxen:

    From 3deb872f69c51919471019d0cde17e226da41675 Mon Sep 17 00:00:00 2001
    From: Todd Lyons <tlyons@ivenue.com>
    Date: Wed, 1 Dec 2010 11:53:12 -0800
    Subject: [PATCH] Add lib64 path before lib in configure.ac

    ---
    configure.ac | 2 +-
    1 files changed, 1 insertions(+), 1 deletions(-)

    diff --git a/configure.ac b/configure.ac
    index acf8583..054ee01 100644
    --- a/configure.ac
    +++ b/configure.ac
    @@ -618,7 +618,7 @@ then
    LDFLAGS="$PTHREAD_CFLAGS $saved_LDFLAGS"

    breakloop="no"
    - for d in lib lib/libmilter
    + for d in lib64 lib lib64/libmilter lib/libmilter
    do
    unset ac_cv_search_smfi_register
    LDFLAGS="$PTHREAD_CFLAGS -L$milterpath/$d $saved_LDFLAGS"

    As I said above, this builds with no errors or warnings on both my i386 and x86_64 machines, however, there is an issue, what I would call an unintended artifact.

    [root@smtp2 opendkim-2.2.2]# uname -i; grep LIBMILTER_LIBDIRS Makefile
    i386
    LIBMILTER_LIBDIRS = -L/usr/lib64

    [root@smtp4 opendkim-2.2.2]# uname -i; grep LIBMILTER_LIBDIRS Makefile
    x86_64
    LIBMILTER_LIBDIRS = -L/usr/lib64

    So while the above builds the opendkim with no errors on both i386 and x86_64 CentOS 5.x boxes, it does set the milter libdirs incorrectly. My assumption is that CentOS/RedHat ld implicitly include /usr/lib and /usr/lib64 when run, so the AC_SEARCH_LIBS will always succeed on the first try (the line after the LDFLAGS setting in the patch above). I do not have other linux distros avilable to test on.

    I'm no autoconf guru, but the solution that the git project uses is pretty efficient:
    dnl GIT_CHECK_FUNC(FUNCTION, IFTRUE, IFFALSE)
    dnl -----------------------------------------
    dnl Similar to AC_CHECK_FUNC, but on systems that do not generate
    dnl warnings for missing prototypes (e.g. FreeBSD when compiling without
    dnl -Wall), it does not work. By looking for function definition in
    dnl libraries, this problem can be worked around.
    AC_DEFUN([GIT_CHECK_FUNC],[AC_CHECK_FUNC([$1],[
    AC_SEARCH_LIBS([$1],,
    [$2],[$3])
    ],[$3])])

    Then it's used:
    # Define NO_MKSTEMPS if you don't have mkstemps in the C library.
    GIT_CHECK_FUNC(mkstemps,
    [NO_MKSTEMPS=],
    [NO_MKSTEMPS=YesPlease])
    AC_SUBST(NO_MKSTEMPS)

    Maybe not all that elegant for our needs though.

     
  • Target for next release.

     
    • priority: 5 --> 6
     
    • priority: 6 --> 5
     
  • Unassigning; Daniel is no longer available.

     
    • assigned_to: grooverdan --> nobody
     
  • Abandoned.

     
    • status: open --> closed-out-of-date