GNU logs - #35245, boring messages

Message sent to bug-libtool@HIDDEN:

Subject: bug#35245: libltdl.so uses 32-bit search path in 64-bit mode in Solaris 11.4
Resent-From: Vita Batrla <vitezslav.batrla@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Fri, 12 Apr 2019 14:29:02 +0000
Resent-Message-ID: <handler.35245.B.155507932120580 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 35245 <at> debbugs.gnu.org
Date: Fri, 12 Apr 2019 11:04:43 +0200
From: Vita Batrla <vitezslav.batrla@HIDDEN>
Message-ID: <20190412090443.GB1659@ultra>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z"
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>


--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

Hi all,

I noticed that 64-bit version of libtool's libltdl.so shipped in Solaris 11.4
is compiled with 32-bit search path. This mismatch leads causes a failure to
dynamically load a module using lt_dlopen() interface.

Here's an example of a 64-bit executable trying to dynamically load
"libcrypt.so":

$ truss -t open,mmapobj ./ltdldemo
openat(AT_FDCWD, "/var/ld/64/ld.config", O_RDONLY) Err#2 ENOENT
openat(AT_FDCWD, "/usr/lib/64/libltdl.so.7", O_RDONLY) = 3
openat(AT_FDCWD, "/lib/64/libc.so.1", O_RDONLY) = 3
calling lt_dlinit
calling lt_dlopen
openat(AT_FDCWD, "/usr/lib/libcrypt.so", O_RDONLY) = 3

^ found "libcrypt.so" in 32-bit path

mmapobj(3, MMOBJ_INTERPRET, 0x7FFFBF6ED210, 0x7FFFBFFFEA0C, 0x00000000) Err#48 ENOTSUP

^ failed to map it

libcrypt.so: file not found

I assume the failure is obvious. A 64-bit program doesn't like 32-bit
library (/usr/lib/libcrypt.so) and so mmapobj(2) syscall returns ENOTSUP
per its man page:

       ENOTSUP       The current user data model does not match the fd  to  be
                     interpreted.  For example, a 32-bit process that tried to
                     use mmapobj() to interpret a 64-bit object  would  return

The fix is to use 64-bit default search path in 64-bit mode (/lib/64
/usr/lib/64). There are two workarounds:

1. LTDL_LIBRARY_PATH=/lib/64:/usr/lib/64
2. re-compile 64-bit libtool:
     ./configure lt_cv_sys_dlsearch_path="/lib/64 /usr/lib/64"

Perhaps the best solution would be to auto-detect whether to use 32-bit or
64-bit library search paths [1][2][3] on Solaris OS in a configure script.

Please see a suggested fix in an attached patch.

Thanks,

Vita

[1] Search paths per ld(1) man page:
       LIBPATH        For  32-bit  libraries, the default search path is /lib,
                      followed by /usr/lib. For 64-bit libraries, the  default
                      search path is /lib/64, followed by /usr/lib/64.

[2] Search paths per ld.so.1(1) man page:
       The runtime linker uses a  prescribed  search  path  for  locating  the
       dynamic  dependencies  of  an  object. The default search paths are the
       runpath recorded in the object, followed by a series of  defaults.  For
       32-bit  objects, the defaults are /lib followed by /usr/lib. For 64-bit
       objects, the  defaults  are  /lib/64  followed  by  /usr/lib/64.

[3] Search paths per crle(1) man page:
           The  default  search paths for 32-bit ELF objects are /lib followed
           by /usr/lib. For 64-bit ELF objects, the default search  paths  are
           /lib/64 followed by /usr/lib/64.

--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="000-64-bit-sys_dlsearch_path.patch"

Prevent libltdl.so from using 32-bit search path in 64-bit mode in Solaris OS.

--- libtool-2.4.6.orig/m4/libtool.m4	Tue Jan 20 17:15:19 2015
+++ libtool-2.4.6/m4/libtool.m4	Thu Apr 11 19:20:11 2019
@@ -1456,6 +1456,7 @@
   if AC_TRY_EVAL(ac_compile); then
     case `/usr/bin/file conftest.o` in
     *64-bit*)
+      SOLARIS_ISA_BITS=64
       case $lt_cv_prog_gnu_ld in
       yes*)
         case $host in
@@ -1478,6 +1479,9 @@
 	;;
       esac
       ;;
+    *32-bit*)
+      SOLARIS_ISA_BITS=32
+      ;;
     esac
   fi
   rm -rf conftest*
@@ -2995,6 +2999,12 @@
   hardcode_into_libs=yes
   # ldd complains unless libraries are executable
   postinstall_cmds='chmod +x $lib'
+  if test 32 = "$SOLARIS_ISA_BITS"; then
+    sys_lib_search_path_spec="/lib /usr/lib"
+  else
+    sys_lib_search_path_spec="/lib/64 /usr/lib/64"
+  fi
+  sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
   ;;
 
 sunos4*)

--7AUc2qLy4jB3hD7Z--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Vita Batrla <vitezslav.batrla@HIDDEN>
Subject: bug#35245: Acknowledgement (libltdl.so uses 32-bit search path in
 64-bit mode in Solaris 11.4)
Message-ID: <handler.35245.B.155507932120580.ack <at> debbugs.gnu.org>
References: <20190412090443.GB1659@ultra>
X-Gnu-PR-Message: ack 35245
X-Gnu-PR-Package: libtool
Reply-To: 35245 <at> debbugs.gnu.org
Date: Fri, 12 Apr 2019 14:29:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-libtool@HIDDEN

If you wish to submit further information on this problem, please
send it to 35245 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
35245: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D35245
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-libtool@HIDDEN:

Subject: bug#35245: libltdl.so uses 32-bit search path in 64-bit mode in Solaris 11.4
Resent-From: Bob Friesenhahn <bfriesen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Wed, 24 Apr 2019 21:40:01 +0000
Resent-Message-ID: <handler.35245.B35245.15561419795596 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Vita Batrla <vitezslav.batrla@HIDDEN>
Cc: 35245 <at> debbugs.gnu.org
Date: Wed, 24 Apr 2019 16:39:30 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@HIDDEN>
In-Reply-To: <20190412090443.GB1659@ultra>
Message-ID: <alpine.GSO.2.20.1904241631280.29259@HIDDEN>
References: <20190412090443.GB1659@ultra>
User-Agent: Alpine 2.20 (GSO 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Fri, 12 Apr 2019, Vita Batrla wrote:

> Hi all,
>
> I noticed that 64-bit version of libtool's libltdl.so shipped in Solaris 11.4
> is compiled with 32-bit search path. This mismatch leads causes a failure to
> dynamically load a module using lt_dlopen() interface.
>
> Here's an example of a 64-bit executable trying to dynamically load
> "libcrypt.so":

I agree with your problem statement and your patch, but would like to 
point out that loading a bare module name without a specified path is 
somewhat insecure and not a recommended use case.

I do not recall similar problems with failing to find 64-bit modules 
on my Solaris (and Solaris-derived) systems, but my software stores 
modules in a directory with a well defined path (a wise thing to do) 
and opens the ".la" module wrapper file via that path.  The libraries 
listed in the ".la" module are then loaded as expected.

In the mean time, Oracle could fix the libltdl.so shipped in Solaris 
11.4.

Bob
-- 
Bob Friesenhahn
bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Message sent to bug-libtool@HIDDEN:

Subject: bug#35245: libltdl.so uses 32-bit search path in 64-bit mode in Solaris 11.4
Resent-From: Bob Friesenhahn <bfriesen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Wed, 24 Apr 2019 21:42:02 +0000
Resent-Message-ID: <handler.35245.B.15561421065804 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Vita Batrla <vitezslav.batrla@HIDDEN>
Cc: 35245 <at> debbugs.gnu.org
Date: Wed, 24 Apr 2019 16:39:30 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@HIDDEN>
In-Reply-To: <20190412090443.GB1659@ultra>
Message-ID: <alpine.GSO.2.20.1904241631280.29259@HIDDEN>
References: <20190412090443.GB1659@ultra>
User-Agent: Alpine 2.20 (GSO 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Fri, 12 Apr 2019, Vita Batrla wrote:

> Hi all,
>
> I noticed that 64-bit version of libtool's libltdl.so shipped in Solaris 11.4
> is compiled with 32-bit search path. This mismatch leads causes a failure to
> dynamically load a module using lt_dlopen() interface.
>
> Here's an example of a 64-bit executable trying to dynamically load
> "libcrypt.so":

I agree with your problem statement and your patch, but would like to 
point out that loading a bare module name without a specified path is 
somewhat insecure and not a recommended use case.

I do not recall similar problems with failing to find 64-bit modules 
on my Solaris (and Solaris-derived) systems, but my software stores 
modules in a directory with a well defined path (a wise thing to do) 
and opens the ".la" module wrapper file via that path.  The libraries 
listed in the ".la" module are then loaded as expected.

In the mean time, Oracle could fix the libltdl.so shipped in Solaris 
11.4.

Bob
-- 
Bob Friesenhahn
bfriesen@HIDDEN, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.