freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] No support for side-by-side installation of x86-64and i38


From: mpsuzuki
Subject: Re: [ft-devel] No support for side-by-side installation of x86-64and i386
Date: Tue, 27 Dec 2005 10:18:47 +0900

Hi

On Mon, 26 Dec 2005 20:55:34 +0900
address@hidden wrote:
>On Mon, 26 Dec 2005 11:28:30 +0100 (CET)
>Werner LEMBERG <address@hidden> wrote:
>>Additionally I wonder whether there isn't already
>>some stuff in, say, libtool.  Otherwise you could
>>probably contribute your code -- I'm quite sure
>>that the libtool maintainers can give you additional
>>advice.
>
>OK, I'll check libtool and reconsider to reduce the script
>size.

Just I've searched documents in libtool-1.5.22 & 2.1a,
and libtool mail list archive. In the latest CVS snapshot
(2.1a), still multilib support is written as future issue.
>From the mail list archive, the last mention about multilib
issue is 03/Dec/2004:

http://lists.gnu.org/archive/html/libtool/2004-12/msg00020.html

I'm afraid no implementation had been worked.
Interesting is that they mentioned about RedHat multilib
patch for libtool. It just fixes library search path from
/usr/lib to /usr/lib64 on 64bit platforms, as attached.
Of course, the patch was proposed once, but refused by
libtool maintainers.

I guess, libtool maintainers want to support to build multi
libraries by unified single make target (aslike, current
libtool can generate both of static/dynamic libraries by
the single make target for libXXX.la), so the work must be
very very hard. In fact, if we expect "configure && make"
builds multi ABI libraries, config.h must be ABI independent,
as the issue now we have :-).

Anyway, I will ask future plan and advise to libtool list,
but I think my patch is sufficient for urgent fix until
future libtool update.

Regards,
mpsuzuki


--- libtool-1.5.14/libtool.m4.multilib  2005-02-12 12:18:34.000000000 +0000
+++ libtool-1.5.14/libtool.m4   2005-02-15 08:48:42.189498479 +0000
@@ -1456,10 +1456,27 @@
   # before this can be enabled.
   hardcode_into_libs=yes
 
+  # find out which ABI we are using
+  libsuff=
+  case "$host_cpu" in
+  x86_64*|s390x*|powerpc64*)
+    echo '[#]line __oline__ "configure"' > conftest.$ac_ext
+    if AC_TRY_EVAL(ac_compile); then
+      case `/usr/bin/file conftest.$ac_objext` in
+      *64-bit*)
+        libsuff=64
+        sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff} 
/usr/local/lib${libsuff}"
+        ;;
+      esac
+    fi
+    rm -rf conftest*
+    ;;
+  esac
+
   # Append ld.so.conf contents to the search path
   if test -f /etc/ld.so.conf; then
     lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s", \[$]2)); 
skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 
's/#.*//;s/[:,   ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
-    sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
+    sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra"
   fi
 
   # We used to test for /lib/ld.so.1 and disable shared libraries on






reply via email to

[Prev in Thread] Current Thread [Next in Thread]