Yes, the command is pvs:
http://docs.oracle.com/cd/E19253-01/816-5165/pvs-1/

And the output suggests that the versions are OK:

   bautsche@cressida $ pvs solver/unxsogi.pro/bin/idlc
   libm.so.2 (SUNW_1.1);
   libgcc_s.so.1 (GCC_3.0);
   libc.so.1 (SUNWprivate_1.1, SUNW_1.1, SUNW_0.9, SUNW_0.7, SYSVABI_1.3);
   libuno_sal.so.3 (LIBO_UDK_4.1, UDK_3.6, LIBO_UDK_4.0, PRIVATE_1.1, UDK_3
   _0_0);
   bautsche@cressida $ pvs solver/unxsogi.pro/lib/libuno_sal.so.3
   libgcc_s.so.1 (GCC_3.0);
   libsocket.so.1 (SUNW_1.1, SUNW_0.7);
   libnsl.so.1 (SUNW_0.7);
   libm.so.2 (SUNW_1.1);
   libpthread.so.1 (SUNW_1.1, SUNW_1.2, SUNW_0.9);
   libuno_sal.so.3;
   UDK_3_0_0;
   UDK_3.1;
   UDK_3.2;
   UDK_3.3;
   UDK_3.4;
   UDK_3.5;
   UDK_3.6;
   UDK_3.7;
   UDK_3.8;
   UDK_3.9;
   UDK_3.10;
   UDK_3.11;
   LIBO_UDK_3.5;
   LIBO_UDK_3.6;
   LIBO_UDK_4.0;
   LIBO_UDK_4.1;
   PRIVATE_1.0;
   PRIVATE_1.1;
   PRIVATE_1.2;
   PRIVATE_textenc.1;
   PRIVATE_file.1;
   GLIBCXX_3.4;
   bautsche@cressida $



On 01/11/2013 15:22, Stephan Bergmann wrote:
On 11/01/2013 03:48 PM, Eric Bautsch wrote:
Output from LD_DEBUG=all ldd -r solver/unxsogi.pro/bin/idlc >log 2>&1
attached.

Unfortunately doesn't give a clue why the loader refuses to pick the symobls from libuno_sal.so.3.

The last idea I have is that there's something wrong with the symbol versions.

02205: file=libuno_sal.so.3; needed by solver/unxsogi.pro/bin/idlc
02205:
02205: find object=libuno_sal.so.3; searching
02205: search path=$ORIGIN/../../ure-link/lib:/export/home/bautsche/libre-office/libreoffice-4.1.2.3/solver/unxsogi.pro/lib (RUNPATH/RPATH from file solver/unxsogi.pro/bin/idlc) 02205: trying path=/export/home/bautsche/libre-office/libreoffice-4.1.2.3/solver/unxsogi.pro/bin/../../ure-link/lib/libuno_sal.so.3 02205: trying path=/export/home/bautsche/libre-office/libreoffice-4.1.2.3/solver/unxsogi.pro/lib/libuno_sal.so.3 libuno_sal.so.3 => /export/home/bautsche/libre-office/libreoffice-4.1.2.3/solver/unxsogi.pro/lib/libuno_sal.so.3 02205: file=/export/home/bautsche/libre-office/libreoffice-4.1.2.3/solver/unxsogi.pro/lib/libuno_sal.so.3 [ ELF ]; generating link map
02205: addr: 0xfe4e4000 size: 0x4e38c
02205: lmid: BASE lmco: 0x10
02205:
02205: version needed processing: file=solver/unxsogi.pro/bin/idlc
02205: file version
02205: libuno_sal.so.3 LIBO_UDK_4.1
02205: libuno_sal.so.3 UDK_3.6
02205: libuno_sal.so.3 LIBO_UDK_4.0
02205: libuno_sal.so.3 PRIVATE_1.1
02205: libuno_sal.so.3 UDK_3_0_0

indicates that idlc does expect to see versioned symbols from libuno_sal.so.3, but I forgot what the Solaris command is to see what versions the symbols exported/required by an object should have (psv? pvs? something like that), and whether there's an LD_DEBUG argument in addition to "all" on Solaris to make it output information about symbol resolution version mismatch.

Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


--
____
     /          .                           Eric A. Bautsch
    /--   __       ___                ______________________________________
   /     /    /   /                  /
  (_____/____(___(__________________/       email: eric.baut...@pobox.com

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to