These two features described on OOo DevGuide:
At the moment for LibO don't work as described.
Only the possibility with the added parameters will work; that is,for Java binding you need to use:
java -Dcom.sun.star.lib.loader.unopath=/opt/libreoffice/program -jar SimpleBootstrap_java.jar
and for C++ binding you need to use these two steps:
setenv UNO_PATH /opt/libreoffice/program
whereas the automatic search for an installed LibO installation won't work in both cases, e.g for Java:
java -jar SimpleBootstrap_java.jar
and for C++
Both will connect to OOo instead.
This is true in the case the user uses the helper classes available in LibO SDK.
For details how all this is supposed to work, the same pages of the OOo DevGuide recalled above are explanatory.
The Java and C++ bindings have two functions that use the symlink /usr/bin/soffice in order to reach the actual LibO installation.
So /usr/bin/libreoffice should be symlinked to /opt/libreoffice/program/soffice, or more generally to <install dir>/program/soffice
The soffice and soffice.bin inside ../program must stay named as now, because they can be used as target for autostart of LibO.
There is mail already exchanged on the topic, in which I'm afraid I didn't explain the problem in details:
Some matter may still be open; ATM I don't know the way python and CLI bindings work; I'm not sure they require the same changes.
A quick and easy way to see the behavior described here is to try with testtool in universal LibO:
To reproduce (test carried out with a build from a pull -r done on Oct,20th around 2 pm):
1) install universal LibO, it will show up in /opt/libreoffice.
2) following the steps here: http://wiki.documentfoundation.org/Qa/testing/Using_Testtool
prepare the testtool environment and start the test as instructed
3) Oracle OOo is started instead of LibO.
Solutions to the symlink issue: I see two possible:
1) apply the patches I will attach, so the original behavior is restored;
2) leave the situation as it is, but documenting somewhere in the LibO DevGuide how the features above are working (e.g. the need to always specify
the path on the start line); and if testtool will be needed for testing update testtool code accordingly.
A test case can be built using Java, as an example, there is a Java program here:
I modified and adapted it to check this issue, but I didn't attach it here because I'm not sure of the license issues: the PDL for documentation,
does it fit the guidelines/bylaws here?
Created attachment 39893 [details]
Change symlink in packaging and adapt ../program/soffice start script.
Created attachment 39894 [details]
Change installation path search in Java
Created attachment 39895 [details]
Change installation path search in testtool
Created attachment 39896 [details]
Change installation path search in C/C++
Surely the easiest thing to do is to add a /usr/bin/soffice that points to the right place no ?
That would work, but only if OOo is not installed on the same machine.
In this case the OOo symlink /usr/bin/soffice will 'confuse' LibO tooling, pointing it to OOo environment instead.
For the record, patches applied on master, see:
Added Fridrich to cc, 'cause he's aware of this.
(In reply to comment #7)
> For the record, patches applied on master, see:
was added to correct some build problem introduced by the above commits.
Giuseppe, could we close this bug as fixed or do we need more changes?
(In reply to comment #9)
> Giuseppe, could we close this bug as fixed or do we need more changes?
Petr, you may close it.
This morning I was finally able to test it and appears fixed on master.
I wasn't able to check it before.
Closed it myself, I noted that Petr is not on cc list.
Closing - Sophie
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.