Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 215369 - app-office/openoffice-2.4.0 build searches libjawt.so in wrong place
Summary: app-office/openoffice-2.4.0 build searches libjawt.so in wrong place
Status: RESOLVED DUPLICATE of bug 193998
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: PPC Linux
: High normal
Assignee: Gentoo Office Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-29 20:56 UTC by Laurent G.
Modified: 2008-10-16 20:22 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent G. 2008-03-29 20:56:54 UTC
I have ibm-jdk-bin 1.4.2.9, 1.5.0.6-r1 and 1.6.0.0 installed. Which ever is selected via java-config, the OOo build wants to use 1.6 to produce 1.4 :
--with-jdk-home=/opt/ibm-jdk-bin-1.6.0.0 
ending up in 
powerpc-unknown-linux-gnu-g++ -Wl,-rpath,'$ORIGIN:$ORIGIN/../ure-link/lib' -shared -L../../unxlngppc.pro/lib -L../lib -L/var/tmp/portage/app-office/openoffice-2.4.0/work/ooo/build/OOH680_m12/solenv/unxlngppc/lib -L/var/tmp/portage/app-office/openoffice-2.4.0/work/ooo/build/OOH680_m12/solver/680/unxlngppc.pro/lib -L/var/tmp/portage/app-office/openoffice-2.4.0/work/ooo/build/OOH680_m12/solenv/unxlngppc/lib -L/opt/ibm-jdk-bin-1.6.0.0/lib -L/opt/ibm-jdk-bin-1.6.0.0/jre/bin -L/opt/ibm-jdk-bin-1.6.0.0/jre/bin/classic -L/opt/ibm-jdk-bin-1.6.0.0/jre/bin -L/usr/lib -L/usr/lib/mozilla-firefox ../../unxlngppc.pro/slo/officebean_version.o -o ../../unxlngppc.pro/lib/libofficebean.so ../../unxlngppc.pro/slo/com_sun_star_comp_beans_LocalOfficeWindow.o ../../unxlngppc.pro/slo/com_sun_star_beans_LocalOfficeWindow.o -ljawt -lstdc++ -ldl -lpthread -lm
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.2.3/../../../../powerpc-unknown-linux-gnu/bin/ld: cannot find -ljawt

where the searched library is not in jre/lib but in jre/lib/ppc as it is in ibm-jdk 1.6 (in 1.4 and 1.5 it was in jre/lib)


Reproducible: Always
Comment 1 Andreas Proschofsky (RETIRED) gentoo-dev 2008-03-29 21:04:46 UTC
I guess that's another problem with ibm-jdk-bin, adding ppc- and java-herds for input
Comment 2 Laurent G. 2008-03-31 20:01:41 UTC
Just as a workaround, I soft linked the .so from jre/lib/ppc and jre/lib/ppc/xawt in jre/bin. The emerge went well.

cd /opt/ibm-jdk-bin-1.6.0.0/jre/bin
find ../lib/ppc -maxdepth 1 -name '*.so' | while read -r fic; do ln -s $fic; done
find ../lib/ppc/xawt/ -maxdepth 1 -name '*.so' | while read -r fic; do ln -s $fic; done

Hth.
Comment 3 Andreas Thalhammer 2008-05-12 09:37:04 UTC
I have the same issue here. (arch=ppc 32-bit)

# java-config -L
The following VMs are available for generation-2:
1)      IBM JDK 1.4.2.10 [ibm-jdk-bin-1.4]
2)      IBM JDK 1.5.0.7 [ibm-jdk-bin-1.5]
*)      IBM JDK 1.6.0.1 [ibm-jdk-bin-1.6]

The strange thing: when I set
# java-config -S 2
Now using ibm-jdk-bin-1.5 as your generation-2 system JVM
# java-config -L
1)      IBM JDK 1.4.2.10 [ibm-jdk-bin-1.4]
*)      IBM JDK 1.5.0.7 [ibm-jdk-bin-1.5]
3)      IBM JDK 1.6.0.1 [ibm-jdk-bin-1.6]

Now check the path that the openoffice-2.4.0.ebuild uses:
# env-update && source /etc/profile
>>> Regenerating /etc/ld.so.cache...
# java-config --jdk-home
/opt/ibm-jdk-bin-1.5.0.7


Nevertheless, openoffice-2.4.0.ebuild finds the 1.6 version of JDK.

Maybe it has to do with sandboxing and running as portage user (features=sandbox userpriv usersandbox)... I'll check without these portage features and report back...
Comment 4 Andreas Thalhammer 2008-05-12 09:52:31 UTC
# FEATURES="-userpriv -usersandbox -sandbox" emerge -1v app-office/openoffice
...
 * Using: ibm-jdk-bin-1.6

Then I removed the features from my /etc/make.conf with the same result.
The openoffice-ebuild keeps useing JDK 1.6 regardless what I set with java-config.

I'll next try to hard-code the line --with-jdk-home=/opt/ibm-jdk-bin/1.5.0.7 into the ebuild...
Comment 5 Andreas Thalhammer 2008-05-12 15:51:50 UTC
Okay, in the ebuild, in function src_unpack(), I replaced the line
if use java ; then
  echo "--with-jdk-home=$(java-config...

with
  echo "--with-jdk-home=/opt/ibm-jdk-bin/1.5.0.7" >> ${CONFFILE}

It still prints out:
 * Using: ibm-jdk-bin-1.6

but it uses JDK 1.5 anyway. It's still compiling, I'll report back if everything worked fine or not.

CONCLUSION:
The seems to be a bug in the way ebuilds and java-config interact. It's definitely a portage issue, not an openoffice-2.4.0.ebuild issue.

It would still be a good idea to let the ebuild use 1.4 or 1.5 JDK if run on a ppc machine.
Comment 6 Andreas Thalhammer 2008-05-13 18:22:02 UTC
Finished!

Compiled without errors and as far as I can see no errors when running OO Writer and OO Calc. So I guess it is all fine.

--- openoffice-2.4.0.ebuild     2008-05-09 16:05:33.000000000 +0200
+++ openoffice-2.4.0_jre-hardcoded.ebuild       2008-05-13 17:27:47.710057814 +0200
@@ -228,7 +228,7 @@
        #Use flag checks
        if use java ; then
                echo "--with-ant-home=${ANT_HOME}" >> ${CONFFILE}
-               echo "--with-jdk-home=$(java-config --jdk-home 2>/dev/null)" >> ${CONFFILE}
+               echo "--with-jdk-home=/opt/ibm-jdk-bin-1.5.0.7" >> ${CONFFILE}
                echo "--with-java-target-version=$(java-pkg_get-target)" >> ${CONFFILE}
                echo "--with-system-beanshell" >> ${CONFFILE}
                echo "--with-system-xalan" >> ${CONFFILE}

This doesn't fix the problem with "java-config --jdk-home" reporting the wrong path inside the ebuild.

Can anyone investigate this issue?
Comment 7 Andreas Proschofsky (RETIRED) gentoo-dev 2008-05-29 22:33:02 UTC
Guess this bug could need some input from the java-devs...
Comment 8 Andreas Thalhammer 2008-06-15 06:48:30 UTC
Works with openoffice-2.4.1 as well, I again replaced:
  --with-jdk-home=$(java-config --jdk-home 2>/dev/null)
with
  --with-jdk-home=/opt/ibm-jdk-bin-1.5.0.7
in the ebuild to force the use of Java 1.5.

BTW, Java has been masked for ppc, see bug #225723.
Comment 9 emerald 2008-08-12 10:46:02 UTC
The ibm jdk is a pain, it seems to change the location of the libraries from version to version, it's a different place in 1.5 and 1.6.
And, to make it worse, both are different places from sun jdk, so even openjdk (icedtea), which i managed to compile on ppc (and works very well, compared to the ibm jdk), the libjawt.so is not found since it's in the same (relative) location as in sun jdk (${JAVA_HOME}/jre/lib/<arch>/).
And the openoffice build seems to be customized to find the ibm jdk 1.5 libs so 1.6 and openjdk both don't work without manual interaction.
Up till openoffice 2.4.0 i hardly had problems compiling openoffice, as long as i hindered openoffice to use ibm-jdk 1.6 (e.g. uninstall it), but now the 2.4.1 is really stubborn, looks for the libs in the worst places.

==============
Making: ../../unxlngppc.pro/lib/libofficebean.so
powerpc-unknown-linux-gnu-g++ -Wl,-rpath,'$ORIGIN:$ORIGIN/../ure-link/lib' -shar
ed -L../../unxlngppc.pro/lib -L../lib -L/var/tmp/portage/app-office/openoffice-2
.4.1/work/ooo/build/OOH680_m17/solenv/unxlngppc/lib -L/var/tmp/portage/app-offic
e/openoffice-2.4.1/work/ooo/build/OOH680_m17/solver/680/unxlngppc.pro/lib -L/var
/tmp/portage/app-office/openoffice-2.4.1/work/ooo/build/OOH680_m17/solenv/unxlng
ppc/lib -L/usr/lib/icedtea6-1.2/lib -L/usr/lib/icedtea6-1.2/jre/bin -L/usr/lib/i
cedtea6-1.2/jre/bin/classic -L/usr/lib/icedtea6-1.2/jre/bin -L/usr/lib -L/usr/li
b/xulrunner-1.9/sdk/lib ../../unxlngppc.pro/slo/officebean_version.o -o ../../un
xlngppc.pro/lib/libofficebean.so ../../unxlngppc.pro/slo/com_sun_star_comp_beans
_LocalOfficeWindow.o ../../unxlngppc.pro/slo/com_sun_star_beans_LocalOfficeWindo
w.o -ljawt -lstdc++ -ldl -lpthread -lm
/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.1/../../../../powerpc-unknown-linux-g
nu/bin/ld: cannot find -ljawt
collect2: ld returned 1 exit status
dmake:  Error code 1, while making '../../unxlngppc.pro/lib/libofficebean.so'
---* tg_merge.mk *---
================
Comment 10 Andreas Proschofsky (RETIRED) gentoo-dev 2008-10-16 20:22:17 UTC

*** This bug has been marked as a duplicate of bug 193998 ***