Issue 122483 - unoapploader sets wrong LD_LIBRARY_PATH
Summary: unoapploader sets wrong LD_LIBRARY_PATH
Status: CLOSED FIXED
Alias: None
Product: App Dev
Classification: Unclassified
Component: sdk (show other issues)
Version: 4.0.0-dev
Hardware: All Linux, all
: P3 Normal
Target Milestone: ---
Assignee: jsc
QA Contact:
URL:
Keywords: regression
Depends on: 122478
Blocks:
  Show dependency tree
 
Reported: 2013-06-06 02:25 UTC by Ariel Constenla-Haile
Modified: 2017-05-20 09:31 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.0.0_release_blocker+


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Ariel Constenla-Haile 2013-06-06 02:25:21 UTC
Build the SimpleBootstrap example from the SDK
Try to run it from a ternimal where the SDK environment is not set

./SimpleBootstrap_cpp 
./_SimpleBootstrap_cpp: error while loading shared libraries: libuno_cppuhelpergcc3.so.3: cannot open shared object file: No such file or directory

unoapploader is using unoinfo to set the LD_LIBRARY_PATH environment variable

unoinfo prints info pre 3 layer removal:

case $1 in
c++)
    printf '%s' "$sd_prog/../basis-link/ure-link/lib"

unoapploader is putting this environment variable pointing to a 3-layer OO:

198             putenv( envstr );
(gdb) print envstr
$25 = 0x6040f0 "LD_LIBRARY_PATH=/opt/openoffice4/program/../basis-link/ure-link/lib"


Maybe unoinfo can be removed, as finding soffice path is enough now.
Comment 1 jsc 2013-06-06 09:35:13 UTC
the stlport change have to be checked in the SDK env
Comment 2 jsc 2013-06-13 12:15:53 UTC
fixed on trunk

follow up will be to remove unoinfo completely
Comment 3 Stephan Bergmann 2013-08-29 10:17:11 UTC
(In reply to jsc from comment #2)
> follow up will be to remove unoinfo completely

FYI, <http://cgit.freedesktop.org/libreoffice/core/commit/?id=617c5e44e13eb12dd58559289bc83def9f2b77e9> "[API CHANGE] Remove obsolete com.sun.star.comp.helper.UnoInfo":

"It had originally been used in the SDK's 'Simple Bootstrap' for Java, com.sun.star.lib.loader.Loader class, but only left in there for backwards compatibility with pre--three-layer OOo versions (i.e., < OOo 3) when that Loader was switched to use the unoinfo executable with the fix for #i88687# 'C++/Java Simple Bootstrap broken' in e2b7ea631a5e7297346ec826527a019e2baca020 'INTEGRATION: CWS sb87 (1.5.10); FILE MERGED: 2008/05/07 11:34:25 sb 1.5.10.1: #i88687# let Loader call new unoinfo instead of old juh.jar UnoInfo.getJars.'

"Recent work in AOO to undo three-layer caused AOO to now accidentally use the backwards-compatibility code, so AOO ran into a problem that they solved with a change to com.sun.star.comp.helper.UnoInfo that LO erroneously merged in as 95ada2d65f6d999920f2a04599ac132fa632d66d 'Related: #i122483# set correct classpath, include unoil.jar.'

"The better approach is to get rid of that backwards-compatibility code and remove the obsolete UnoInfo class. While this is nominally incompatible, in practice no other client code but the SDK's com.sun.star.lib.loader.Loader should ever have used it (it should have been designed as a private interface for just that one client from the start, anyway). Java applications using 'Simple Bootstrap' and built against old versions of the SDK (post the fix for #i88687# and its introduction of the unoinfo exectuable in OOo 3) will continue to work against new LO versions (as the backwards-compatibility code that would call the removed UnoInfo class will not be triggered anyway; and even if it were, all resulting exceptions would be caught and the new code path using the unoinfo executable be chosen then). Likewise, Java applications using 'Simple Bootstrap' and built against the new SDK will continue to work against old OOo/LO/AOO vesions as far back as the fix for #i88687# and its introduction of the unoinfo exectuable in OOo 3."