Hi Ulf,
Ulf Wendel wrote:
The last time I tried OOo with GCC on OpenSolaris the configure failed [1]:
> [1] http://www.nabble.com/[EMAIL PROTECTED]
> checking the GNU gcc compiler version... checked (gcc 3.4.3)
> checking gcc linker... configure: error: failed (not GNU ld). Use GNU ld
> instead of Sun ld on Solaris
Hmm, why don't you tweak a PATH environment variable for the ./configure?
Setting PATH with /opt/SUNWspro/bin followed by /usr/sfw/bin like this
export
PATH=/opt/SUNWspro/bin:/usr/sfw/bin:/usr/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/local/bin
would bring you a better result.
checking for gcc... /opt/SUNWspro/bin/cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether /opt/SUNWspro/bin/cc accepts -g... yes
checking for /opt/SUNWspro/bin/cc option to accept ISO C89... none needed
Because OpenSolaris comes with 1.6. In a certain way OOo and OpenSolaris
are Sun products. Why not check if they work nicely together using
out-of-the-box installations and OpenSolaris packages...
Is the could not find jni.h problem a problem that's likely related to
1.5 vs. 1.6? I can't imagine that.
You might have heard that changing version of Java is problematic.
Some Java applications might become not to work after updating Java.
I do not refer to jni.h, but that is a general story.
My starting point was basically on ./configure
CPPFLAGS="-I/path/to/jdk/some/path" [...] --without-java resulting into
CC -INO_JAVA_HOME/some/path. Is that because I used --without-java? If I
could tell OOo where to search for jni.h my issue might be gone.
Maybe no. You would also need to specify by means of something where
jni.h relevant .so files are. Otherwise, you would face another problem
at linking stage or running stage even though compilation would have
become succeeded. .h and .so files are a set of files.
The simplest way to instantly specify both at once is to use --with-jdk-home=,
i think. For instance, --with-jdk-home=/usr/j2se brings the following settings:
$ grep j2se SolarisX86Env.Set.sh
JAVA_HOME="/usr/j2se"
JAVAINTERPRETER="/usr/j2se/bin/java"
JAVACOMPILER="/usr/j2se/bin/javac"
JAVADOC="/usr/j2se/bin/javadoc"
$ grep JAVA_HOME solenv/inc/*.mk
solenv/inc/ant.mk:JAVA_HOME=$(JDK14PATH)
solenv/inc/ant.mk:CLASSPATH!:=$(CLASSPATH)$(PATH_SEPERATOR)$(ANT_CLASSPATH)$(PATH_SEPERATOR)$(JAVA_HOME)$/lib$/tools.jar
solenv/inc/antsettings.mk:JAVA_HOME=
solenv/inc/antsettings.mk:.EXPORT : JAVA_HOME
solenv/inc/libs.mk:AWTLIB*=$(JAVA_HOME)$/lib$/jawt.lib
solenv/inc/target.mk:.IF "$(JAVALOCATION)"!="$(JAVA_HOME)"
solenv/inc/target.mk:.ELSE # "$(JAVALOCATION)"!="$(JAVA_HOME)"
solenv/inc/target.mk:.ENDIF # "$(JAVALOCATION)"!="$(JAVA_HOME)"
solenv/inc/target.mk: @echo JAVALOCATION:=$(JAVA_HOME) >> $@
solenv/inc/tg_javav.mk:.IF "$(JAVAVER)"=="" || "$(JAVALOCATION)"!="$(JAVA_HOME)"
solenv/inc/tg_javav.mk:JAVAVER:=$(shell @-$(JAVA_HOME)$/bin$/java
$(JFLAGSVERSION_CMD))
solenv/inc/tg_javav.mk:JAVANUMVER:=$(shell @-$(JAVA_HOME)$/bin$/java
$(JFLAGSNUMVERSION_CMD))
solenv/inc/tg_javav.mk:.ENDIF # "$(JAVAVER)"=="" ||
"$(JAVALOCATION)"!="$(JAVA_HOME)"
What's wrong with trying to build OOo on a platform that is not on the
list of platforms used by maintainers and release engineers? Sure, its
new grounds and likely to be bloody. But why should I not try to use
OpenSolaris as a development platform.
Now I understand what you want to do. Thank you for the comments.
I admire your challenges.
My interest is different from yours. It is to find a cause of bug, to
try to fix a bug, to confirm a fix done by developers or myself, to make
a mock-up for proposing enhancement, to provide my customers with a binary
patch .so files, and so on.
What i normally do is building a specific module, not building entire OOo.
For example,
1. Obtain source files of DEV300_mXX
2. Prepare build environment
3. cd sw; build.pl --all
4. cd sw; make some modifications in the existing source files
5. cd sw; build.pl debug=1
6. Install DEV300_mXX released by the release engineer of OOo.
7. Replace libswsi.so in the installation directory with the built one.
8. Start OOo.
9. Attach a debugger to the process of soffice.bin
So, I carefully try to avoid any compilation errors which are not related
to the module in which I am interested. Additionally I try to tweak my
build environment to meet the one used by the RE as much as i can.
Best,
Tora
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
