Apache OpenOffice (AOO) Bugzilla – Issue 101883
setsdkenv* still has ln -s for symlinks and doesn't pass -L to find the ones present
Last modified: 2013-02-24 21:07:42 UTC
in 3.1 we/you readded the .so symlinks in the real filesystem (thanks!). But we didn't remove the ln -s commands in setsdkenv* which became obsolete, which still will break if $HOME is not existant or not writable (which has its reasons - no build of a package should rely on $HOME contents and some Debian buildds enforce this), as can be seen at https://buildd.debian.org/fetch.cgi?pkg=openoffice.org-voikko;ver=3.1-1;arch=amd64;stamp=1242212883 in the build of the voikko extension.
and somehow we still didn't get the file: > /usr/bin/ld: cannot find -luno_sal
IMHO worthy and needed for 3.1.1
the links will be create in the OO_SDK_OUT directory only. So they will be created for a user only when the users configured an SDK. They are necessary for linking C++ examples. Whatever you do, you should reconsider your workflow. A user of the SDK can always write in the directory where he wants to generate the output.
> the links will be create in the OO_SDK_OUT directory only. So they will be > created for a user only when the users configured an SDK. Yes, but that was not my point of my last issue. They simply should just work without those manual lns. > They are necessary for linking C++ examples. Umm, no, that also can be fullfilled by "normal" links > Whatever you do, you should reconsider your workflow. A user of the SDK can > always write in the directory where he wants to generate the output. That's not *my* workflow. Besides that, the output is generated in the voikko build dir. Of course the build has access there. So you want to say that it's a bug in voikko that it doesn't set OO_SDK_OUT themselves? Because I of course cannot set it globally so that it matches eveyones need....
The original issue was issue 97041 fwiw
i checked the linux/solaris SDK installation and of course here the links are generated by default in .../sdk/lib. That was the orginal fix. You are right In this case the links in the output dir are not necessary. But for example on MacOS the SDK cannot be installed in the OpenOffice base layer. And here we need the links in the output dir when a user configure a SDK env. The solution is to ifdef the appropriate section in the setsdkenv scripts with -> ifeq "$(OS)" "MACOSX" But for me it is no showstopper for 3.1.1. If you think so please nominate it as 3.1.1 fix and fix it. Otherwise i will fix it for 3.2.
some more changes in the sdk/settings/settings.mk would be also necessary to ensure that C++ examples can be build without the links in the ouput dir.
> i checked the linux/solaris SDK installation and of course here the links are > generated by default in .../sdk/lib. That was the orginal fix. And I have them, too: sh-3.2$ dpkg -L openoffice.org-dev | grep "sal.*so$" /usr/lib/openoffice/basis3.1/sdk/lib/libuno_sal.so /usr/lib/openoffice/basis3.1/sdk/lib/libuno_salhelpergcc3.so sh-3.2$ dpkg -L openoffice.org-dev | grep "cppu.*so$" /usr/lib/openoffice/basis3.1/sdk/lib/libuno_cppu.so /usr/lib/openoffice/basis3.1/sdk/lib/libuno_cppuhelpergcc3.so But as the buildlog (https://buildd.debian.org/fetch.cgi?pkg=openoffice.org-voikko;ver=3.1-1;arch=amd64;stamp=1242212883) shows voikko doesn't find the lib anyway. Or would you argue it's a voikko bug to not specify -L/usr/lib/openoffice/basis-link/sdk/lib itself? > You are right In this case the links in the output dir are not necessary. Good :-) > The solution is to ifdef the appropriate section in the setsdkenv scripts with > -> ifeq "$(OS)" "MACOSX" OK > But for me it is no showstopper for 3.1.1. If you think so please nominate it > as 3.1.1 fix and fix it. Otherwise i will fix it for 3.2. Well, not fifing that soon will mean I need to carry a patch for longer (or even debian/rules snippet for adding them so /usr/lib/ure/lib which I did for 3.0.1 before issue 97041 went into 3.1 and /usr/lib/ure/lib (ure-link) is in the default -Ls anyway) to fix that in my packages so that other packages build on the buildds. So I am interested to have this fixed as soon as possible :)
g++ -shared '-Wl,-rpath,$ORIGIN' -Wl,--version-script,/usr/lib/openoffice/basis3.1/sdk/settings/component.uno.map -O2 -Wl,--no-undefined -L/home/buildd/openoffice.org3.1_sdk/LINUXexample.out/lib -L/home/buildd/openoffice.org3.1_sdk/linux/lib -L"/usr/lib/openoffice/basis3.1/ure-link/lib" -luno_sal -luno_cppu -luno_cppuhelpergcc3 -lvoikko -o build/oxt/voikko.so build/src/registry.o build/src/common.o build/src/PropertyManager.o build/src/spellchecker/SpellAlternatives.o build/src/spellchecker/SpellChecker.o build/src/hyphenator/Hyphenator.o build/src/hyphenator/HyphenatedWord.o build/src/hyphenator/PossibleHyphens.o build/src/grammar/GrammarChecker.o build/src/settings/SettingsEventHandler.o is voikkos lionk line. note the two -Ls on nonexistant dirs, but e.g.: * SDK = /usr/lib/openoffice/basis3.1/sdk * Office = /usr/lib/openoffice * Office Base = /usr/lib/openoffice/basis3.1 * URE = /usr/lib/openoffice/basis3.1/ure-link IMHO we should add -L $OO_SDK_HOME/lib to -Ls given by setsdkenv
I have understand the problem, please don't bloat the issue with cmd line output. The problem is not the -L option on not existing dirs, it's the more the missing -L$(OO_SDK_HOME)/lib. Correct is to change -L$(OO_SDK_OUT)/$(PLATFORM)/lib -> -L"$(OO_SDK_HOME)/lib" for Linux, Solaris, BSD, all Unix except MacOSX in the settings.mk I have no problems to fix it for 3.1.1. Nominate it and we will see.
approved by RSM today (I already added it to issue 101565)
fixed on cws sdk311
jsc -> rene: please verify on cws sdk311 changed files odk/settings/settings.mk odk/setsdkenv_unix.sh.in odk/setsdkenv_unix.csh.in
As said in EIS: ---------- Comment from rene Thu May 28 17:44:21 +0200 2009 ---------- looks good
This issue is closed automatically. It is in state 'verified/fixed' since 2 releases (OOo 3.1.1 and OOo 3.2). The policy [1] indicates that such older issues should be closed. If this issue still occur in a current build (OOo 3.2.1 or >DEV300m80) please reopen the issue and set the target accordingly. [1] : http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues