[OpenIndiana-discuss] 32-bit libraries disappearing

[Matthew R. Trower]

On 1/6/24 13:01, Marcel Telka wrote:
> On Sat, Jan 06, 2024 at 06:17:58AM -0600, Matthew R. Trower wrote:
>> Having updated my OI workstation after quite some time, I find myself with
>> quite a bit of breakage surrounding missing 32-bit libraries.  For example,
>> libcurl and libcairo (among others) are shipping 64-bit libraries only, and
>> this breaks various third party software.
> For example?

I'm not sure I understand your question. Any software previously 
compiled and linked against the missing 32-bit libraries will cease to 
function in their absence.  Any software attempting to compile and link 
in 32-bit mode against those libraries will fail to do so.

For a concrete example:

===

mtrower at saturn:~$ conky
ld.so.1: conky: fatal: libcurl.so.4: open failed: No such file or directory
Killed
mtrower at saturn:~$ file /bin/conky
/bin/conky:     ELF 32-bit LSB executable 80386 Version 1, dynamically 
linked, not stripped
mtrower at saturn:~$ ldd /bin/conky
         libkstat.so.1 =>         /lib/libkstat.so.1
         libSM.so.6 =>    /usr/lib/libSM.so.6
         libICE.so.6 =>   /usr/lib/libICE.so.6
         libX11.so.4 =>   /usr/lib/libX11.so.4
         libXext.so.0 =>  /usr/lib/libXext.so.0
         libsocket.so.1 =>        /lib/libsocket.so.1
         libnsl.so.1 =>   /lib/libnsl.so.1
         libXdamage.so.1 =>       /usr/lib/libXdamage.so.1
         libXfixes.so.1 =>        /usr/lib/libXfixes.so.1
         libXft.so.2 =>   /usr/lib/libXft.so.2
         liblua5.3.so =>  /usr/lib/liblua5.3.so
         libm.so.2 =>     /lib/libm.so.2
         libImlib2.so.1 =>        /usr/lib/libImlib2.so.1
         libcurl.so.4 =>  (file not found)
         libXinerama.so.1 =>      /usr/lib/libXinerama.so.1
         libstdc++.so.6 =>        (file not found)
         librt.so.1 =>    /lib/librt.so.1
         libgcc_s.so.1 =>         (file not found)
         libc.so.1 =>     /lib/libc.so.1
         libxcb.so.1 =>   /usr/lib/libxcb.so.1
         libmp.so.2 =>    /lib/libmp.so.2
         libmd.so.1 =>    /lib/libmd.so.1
         libfontconfig.so.1 =>    (file not found)
         libfreetype.so.6 =>      (file not found)
         libXrender.so.1 =>       /usr/lib/libXrender.so.1
         libfreetype.so.6 =>      (file not found)
         libdl.so.1 =>    /lib/libdl.so.1
         libXau.so.6 =>   /usr/lib/libXau.so.6
         libXdmcp.so.6 =>         /usr/lib/libXdmcp.so.6
         libXevie.so.1 =>         /usr/lib/libXevie.so.1
         libXss.so.1 =>   /usr/lib/libXss.so.1

===

That one's got all kinds of problems.  In this case, I may be able to 
simply compile it in 64-bit mode. In other cases, I may not be so lucky.

>
>> More critically, libsqlite3 is
>> shipping 64-bit only, and this is breaking certutil(mozilla-nss), which
>> breaks ldapclient(!).
> Could you be more specific please how exactly is certutil broken?
>
>
> Thank you.
>
It is broken because a component library links against the removed 
32-bit libsqlite3.so.0 .

Specifically, libsoftokn is broken, and anything that depends on it:


===

root at saturn:/root# /usr/bin/ldapsearch -v -h ldap.sol.blackshard.net -p 
636 -P /var/ldap -x -Z  -b dc=sol,dc=blackshard,dc=net -s base 
objectclass=*ldapsearch: started Sat Jan  6 18:11:58 2024
ldap_init( ldap.sol.blackshard.net, 636 )
SSL initialization failed: error -5977 (Failure to load dynamic library.)


root at saturn:/root# certutil -L -d /var/ldap
certutil: function failed: PR_LOAD_LIBRARY_ERROR: Failure to load 
dynamic library
         ld.so.1: certutil: fatal: relocation error: file 
/usr/lib/mps/libsoftokn3.so: symbol sqlite3_temp_directory: referenced 
symbol not found

root at saturn:/usr/lib/mps# ldd /usr/lib/mps/libsoftokn3.so
         libsqlite3.so.0 =>       (file not found)
         libnssutil3.so =>        /usr/lib/mps/libnssutil3.so
         libplc4.so =>    /usr/lib/mps/libplc4.so
         libplds4.so =>   /usr/lib/mps/libplds4.so
         libnspr4.so =>   /usr/lib/mps/libnspr4.so
         libc.so.1 =>     /lib/libc.so.1
         libthread.so.1 =>        /lib/libthread.so.1
         libpthread.so.1 =>       /lib/libpthread.so.1
         librt.so.1 =>    /lib/librt.so.1
         libsocket.so.1 =>        /lib/libsocket.so.1
         libnsl.so.1 =>   /lib/libnsl.so.1
         libdl.so.1 =>    /lib/libdl.so.1
         libmp.so.2 =>    /lib/libmp.so.2
         libmd.so.1 =>    /lib/libmd.so.1
         libm.so.2 =>     /lib/libm.so.2

===

Restoring /usr/lib/libsqlite3.so.0 from a previous snapshot restores 
functionality.


-- Matthew R. Trower


PS. I apologize if my formatting is horrible.  I'm still trying to get a 
handle on the Thunderbird revamp.