322727 - Java to xpcom on OS/2

Status: RESOLVED FIXED

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[Andy Willis (abwillis)]

Xulrunner is now defaulting to build javaxpcom so is failing on OS/2.
I am using Innotek Java but it did not have the include files so I copied them from GC Java for now.  
I use the following script before running setmozenv currently but will need to integrate it:
SET PATH=e:\programs\java142\bin;%PATH%
SET CLASSPATH= 
set java_home=e:\programs\java142
SET JAVA2_USERHOME=e:\usr\abwillis

Patches to follow but I have still been getting 16 cannot resolve symbol errors.  I have been trying to build static so I am trying now as the default libxul build.

Comment 1

[Andy Willis (abwillis)]

Attachment: Build patch

Comment 2

[Andy Willis (abwillis)]

Attachment: set libpath and libpathstrict=t

Without this the wrong dll's can be used or not found at all.

Comment 3

[Andy Willis (abwillis)]

Attachment: Errors I am getting during build

This was from a static build, as static builds are not supported on xulrunner I am rebuilding as a regular libxul build to see how it goes.

Comment 4

[Mike Kaply [:mkaply]]

we should disable javaxpcom for OS/2 in configure.in.

Comment 5

[Andy Willis (abwillis)]

It took me most of the day yesterday but I have it just about built now.  I have a feeling this will be of interest to someone who is wanting to build a RAD tool from it.  They are wanting to also add REXX support.  

Comment 6

[Andy Willis (abwillis)]

By suggestion I changed the makefile.in in extensions\java\xpcom\interfaces:
ifneq ($(OS_ARCH),OS2)
# Use find and xargs for passing list of Java files to JAVAC.  This avoids the
# "argument list too long" error on Windows when using *.java
org/mozilla/xpcom/.class_done: _javagen/org/mozilla/xpcom/.iface_done
	@echo Compiling Java interface classes
	find _javagen -name "*.java" | xargs $(JAVAC) $(JAVAC_FLAGS) -classpath . \
      -d . -sourcepath _javagen
	@touch $@
else
org/mozilla/xpcom/.class_done: _javagen/org/mozilla/xpcom/.iface_done
	@echo Compiling Java interface classes
	find _javagen -name "*.java">jfiles
	$(JAVAC) $(JAVAC_FLAGS) -classpath . -d . -sourcepath _javagen @jfiles
	@touch $@
endif

This created the jsfiles with:
_javagen/org/mozilla/xpcom/GREVersionRange.java
_javagen/org/mozilla/xpcom/IAppFileLocProvider.java
_javagen/org/mozilla/xpcom/IGRE.java
_javagen/org/mozilla/xpcom/INIParser.java
_javagen/org/mozilla/xpcom/IXPCOM.java
_javagen/org/mozilla/xpcom/IXPCOMError.java
_javagen/org/mozilla/xpcom/Mozilla.java
_javagen/org/mozilla/xpcom/VersionComparator.java
_javagen/org/mozilla/xpcom/XPCOMException.java

Comment 7

[jhp (no longer active)]

Comment on attachment 207879 [details] [diff] [review]
Build patch

>RCS file: /cvsroot/mozilla/extensions/java/xpcom/build/Makefile.in,v
>RCS file: /cvsroot/mozilla/extensions/java/xpcom/package/Makefile.in,v

These directories are no longer built/used, so no need to make changes here.

>Index: glue/Makefile.in
>===================================================================
> ifeq ($(OS_ARCH),WINNT)
> LOCAL_INCLUDES += -I$(JAVA_INCLUDE_PATH)/win32
> else
>+ifeq ($(OS_ARCH),OS2)
>+LOCAL_INCLUDES += -I$(JAVA_INCLUDE_PATH)/OS2
>+else
> LOCAL_INCLUDES += -I$(JAVA_INCLUDE_PATH)/linux
> endif
>+endif

This change is also needed in http://lxr.mozilla.org/mozilla/source/toolkit/library/libxul-config.mk.

>Index: interfaces/Makefile.in
>===================================================================
>+ifeq ($(OS_ARCH),OS2)
>+RUN = $(srcdir)/../run.cmd
>+OUTPUT_DIR = $(CURDIR)/_javagen/org/mozilla/xpcom
>+else
> RUN = $(DIST)/bin/run-mozilla.sh
> OUTPUT_DIR = $(CURDIR)/_javagen/org/mozilla/xpcom
> endif
>+endif

First, you should only set "RUN" for OS/2;  no sense in having two copies of the same "OUTPUT_DIR".  Second, do you really need your own script?  What about just setting those environment variables directly in the "RUN" statement?  For example:
  RUN = "set BEGINLIBPATH=$(DIST)\bin;%BEGINLIBPATH% && set LIBPATHSTRICT=T && "

But I'm not sure if that's the right syntax.  Try it out.

>Index: src/Makefile.in
>===================================================================
> ifeq ($(OS_ARCH),WINNT)
> RUN =
> SEP = ;
> else
>+ifeq ($(OS_ARCH),OS2)
>+RUN =
>+SEP = ;
>+else
> RUN = $(DIST)/bin/run-mozilla.sh
> SEP = :
> endif
>+endif

Since Windows and OS/2 are the same here, put the two together with "ifneq (,$(filter WINNT OS2,$(OS_ARCH)))".

Comment 8

[jhp (no longer active)]

(In reply to comment #6)
> By suggestion I changed the makefile.in in extensions\java\xpcom\interfaces:

I don't understand why you need to make these changes.  According to the error log that you posted, Java is trying to compile those files just fine, without this change.

As for the errors you are getting, this is because it is not finding the generated Java files.  When building in extensions/java/xpcom/interfaces, you should see the following:
  Copying Java source files
  Generating Java interface files
  ../../../../dist/bin/GenerateJavaInterfaces.exe .....
  Compiling Java interface files

It seems the copying is working correctly, and it is trying to compile them.  For whatever reason, you seem to be missing the generate step.

Comment 9

[jhp (no longer active)]

Ah, my guess is that your run script is not working properly, therefore GenerateJavaInterfaces.exe is not getting called.

Comment 10

[jhp (no longer active)]

(In reply to comment #0)
> I am using Innotek Java but it did not have the include files so I copied them
> from GC Java for now.  

My guess is that you only have the runtime installed.  The SDK should come with the appropriate header files.  Please try that.

> I use the following script before running setmozenv currently but will need to
> integrate it:
> SET PATH=e:\programs\java142\bin;%PATH%

You don't necessarily need to add Java to the PATH.  The main configure.in script finds the correct location based off of the JAVA_HOME env var.

> SET CLASSPATH= 

Is there a reason you need to clear out CLASSPATH?

> set java_home=e:\programs\java142

Are env vars case insensitive on OS/2.  As mentioned above, configure.in looks for JAVA_HOME.

> SET JAVA2_USERHOME=e:\usr\abwillis

Why is this needed?

Comment 11

[Andy Willis (abwillis)]

I am using the run.cmd only because that was what I saw with sign.cmd in nss I think it is and the linux path... I'll try the other method.
I finally found a post on the Innotek forums and they are not shipping the include files with their SDK, they expect people to be using the IBM include files (I may reinstall the IBM SDK to get those).  
I found that removing the classpath (only 1.1.8 stuff in it) helped with launching some java progs.  I can probably remove the SET JAVA2_USERHOME, not sure why I set it originally.  
Environment variables are case insensitive but beginlibpath/endlibpath ussually should be in CAPS as I guess they are not really true environment variables.
Here is the messages from make prior to the error, I thought this indicated that GenerateJavaInterfaces.exe was running but...:
make.exe[1]: Entering directory `E:/cvs/work/mozilla/xulobj/extensions/java/xpcom/interfaces'
Copying Java source files
Generating Java interface files
E:/cvs/work/mozilla/extensions/java/xpcom/interfaces/../run.cmd ../../../../dist/bin/GenerateJavaInterfaces.exe -d E:/cvs/work/mozilla/xulobj/extensions/java/xpcom/interfaces/_javagen/org/mozilla/xpcom
echo ../../../../dist/bin/GenerateJavaInterfaces.exe -d E:/cvs/work/mozilla/xulobj/extensions/java/xpcom/interfaces/_javagen/org/mozilla/xpcom
../../../../dist/bin/GenerateJavaInterfaces.exe -d E:/cvs/work/mozilla/xulobj/extensions/java/xpcom/interfaces/_javagen/org/mozilla/xpcom
set BEGINLIBPATH=DIST\bin;E:\compilers\gcc335\lib;E:\GLIBIDL335\GLIB\gcc\bin;E:\GLIBIDL335\LIBIDL\gcc\bin;E:\compilers\PERL\lib;E:\MOZTOOLS;E:\compilers\EMX\dll;E:\COMPILERS\GCC335\i386-pc-os2-emx\lib;E:\COMPILERS\GCC335\lib;e:\moztools\debug;E:\compilers\IBMCXXO\dll;e:\utils\larsen;
set LIBPATHSTRICT=T
Compiling Java interface classes
find _javagen -name "*.java">jfiles
e:/programs/java142/bin/javac.exe -source 1.4 -classpath . -d . -sourcepath _javagen @jfiles

Comment 12

[Andy Willis (abwillis)]

The jsfiles thing was just to make sure the files were all being found.

Comment 13

[jhp (no longer active)]

(In reply to comment #11)
> I finally found a post on the Innotek forums and they are not shipping the
> include files with their SDK, they expect people to be using the IBM include
> files (I may reinstall the IBM SDK to get those).

Hmm, that seems odd.  Normally, if I download an SDK, I expect it to have all the include files.  Bad call on Innotek's part.

> Here is the messages from make prior to the error, I thought this indicated
> that GenerateJavaInterfaces.exe was running but...:
> make.exe[1]: Entering directory
> `E:/cvs/work/mozilla/xulobj/extensions/java/xpcom/interfaces'
> Copying Java source files
> Generating Java interface files
> E:/cvs/work/mozilla/extensions/java/xpcom/interfaces/../run.cmd
> ../../../../dist/bin/GenerateJavaInterfaces.exe -d

No, this is just showing you the command that is getting called, but if you are in a debug build, GenerateJavaInterfaces.exe should spit out quite a few warnings (not my code, can just be ignored).

OK, I see what's wrong.  You are passing the GenerateJavaInterfaces.exe line to run.cmd, but you are not calling it from withing run.cmd.  Try to get it running without the run.cmd file first.  If all else fails, then we can go down that route.

Comment 14

[Andy Willis (abwillis)]

Ok to get rid of the problem of the run.cmd I 
	$(RUN) 
	$(DIST)/bin/GenerateJavaInterfaces$(BIN_SUFFIX) -d $(OUTPUT_DIR)
This gave a new error:
ERROR: output directory doesn't exist / isn't a directory
Usage: ../../../../dist/bin/GenerateJavaInterfaces.exe -d path
         -d output directory for Java interface files
make.exe[1]: *** [_javagen/org/mozilla/xpcom/.iface_done] Error 1
make.exe[1]: Leaving directory `E:/cvs/work/mozilla/xulobj/extensions/java/xpcom/interfaces'
make.exe: *** [all] Error 2

I need to change the forward slashes to backward slashes apparently.  From command line I changed the slashes and it then worked.
Have an idea on that, that I'll try.

Comment 15

[Andy Willis (abwillis)]

Attachment: New Build patch

With this patch and the other two files I will be uploading I am able to build javaxpcom successfully (right now I am getting an unresolved external in xulrunner.exe link but not related to this).  I am still trying to get this to build with just one extra file instead of two.  I think I have an idea how to do it but wanted to put this up.  I have done the libxul-config.mk update but it also has other updates in that file for another bug so I am not sure how to handle that.

Comment 16

[Andy Willis (abwillis)]

Attachment: libpath and libpathstrict

Comment 17

[Andy Willis (abwillis)]

Attachment: backward to forward slash

This still has the code in it for libpath and libpathstrict but because of where it is being executed these settings are lost before they are needed.  It took me quite awhile to figure out how to get the echo off to work in such a way as to not affect the OUTPUT_DIR I was trying to set, only to find that it did me no good to set it at that point.  I tried to set the libpath stuff from the RUN but I couldn't get it to not interfere with the execution code.  I should be able to use just one script though if I just follow the linux path above and then put the if statement before the 
$(RUN)	$(DIST)/bin/GenerateJavaInterfaces$(BIN_SUFFIX) -d $(OUTPUT_DIR)
line such that I execute the script in place of this line in such a way as to pass the information all on one line.

Comment 18

[jhp (no longer active)]

Comment on attachment 208085 [details] [diff] [review]
New Build patch

>Index: interfaces/Makefile.in
>===================================================================
>-RUN =
>+RUN = 

Please remove these "non-changes".

>+ifeq ($(OS_ARCH),OS2)
>+RUN = $(srcdir)/../run.cmd $(DIST) 
>+OUTPUT_DIR = $(shell $(srcdir)/../bfs.cmd $(DIST) $(CURDIR)/_javagen/org/mozilla/xpcom)
>+else

You shouldn't need a script to do this.  Try:
+OUTPUT_DIR = $(subst /,\\,$(CURDIR)/_javagen/org/mozilla/xpcom)

Comment 19

[jhp (no longer active)]

(In reply to comment #16)
Did you try setting the env vars on the same line in the Makefile as I mentioned in comment #7?

Comment 20

[Andy Willis (abwillis)]

Yes I tried to set the environment in the makefile.  Sorry, I guess I wasn't clear as I had said I hadn't been able to get that to work yet.  It doesn't set the environment but rather gives me an error that it tried to run it as a program. I'll play with that some more now that I see
I'll try the substitution method as that is much cleaner (though I like my script :) ).  I'll play with the environment thing more now that I see I shouldn't need a script for the foward to backward slash (first I was wanting to make sure I could indeed get it working).

Comment 21

[Andy Willis (abwillis)]

The substitution works fine but I am still trying to find a way to pass BEGINLIBPATH and LIBPATHSTRICT.  I have tried export as:
ifeq ($(OS_ARCH),OS2)
BEGINLIBPATH=$(DIST)/bin
LIBPATHSTRICT=T
RUN = export BEGINLIBPATH; export LIBPATHSTRICT;
OUTPUT_DIR = $(subst /,\\,$(CURDIR)/_javagen/org/mozilla/xpcom)
else

I also tried $(shell export BEGINLIBPATH; export LIBPATHSTRICT;)
as well as $(cmd.exe set BEGINLIBPATH=$(DIST)/bin; set LIBPATHSTRICT=T)
and a few other permutations but have not hit on the right way as yet.  
I thought of putting it in the SETMOZENV but the objdir is set in the .mozconfig and I have multiple .mozconfig files depending on what I am building  and realized this was not a clean solution. 

Comment 22

[knut st. osmundsen]

The correct way of doing it would have, *if* gmake knew what *LIBPATH* was (which it doesn't):
export BEGINLIBPATH=$(DIST)/bin;$(BEGINLIBPATH)
export LIBPATHSTRICT=T

Since it doesn't have a clue that BEGINLIBPATH isn't really an env.var. but a kernel thingy with special APIs for getting and setting, you'll have to do the same thing on the RUN line:
RUN=export BEGINLIBPATH="$(DIST)/bin;$$(BEGINLIBPATH)"; export LIBPATHSTRICT="T";

I think it would work fine without the 'export's and ';'. Ah, and btw. you'll have to use my ash port to get this cooking. I don't really think the older ones does beginlibpath, they certainly doesn't do libpathstrict.

Comment 23

[Andy Willis (abwillis)]

Attachment: complete patch

The recent change from GenerateJavaInterfaces to xpidl has made the previous issues with the libpath and libpathstrict obsolete.

Comment 24

[jhp (no longer active)]

Comment on attachment 236577 [details] [diff] [review]
complete patch

>Index: extensions/java/xpcom/tools/xpidl/Makefile.in

This change isn't necessary, since we no longer use any of the code in extensions/java/xpcom/tools.

>Index: modules/plugin/samples/default/os2/plugin.cpp

This change is unrelated to JavaXPCOM.

Otherwise, looks good.  r=jhpedemonte

Comment 25

[Andy Willis (abwillis)]

Attachment: removed excess from patch

Removed plugin.cpp and the tools section that is no longer used.  Did add an ifdef for OS2 only change to use SHORT_LIBNAME.
Carrying over review.

Comment 26

[Mike Kaply [:mkaply]]

Comment on attachment 238660 [details] [diff] [review]
removed excess from patch

sr=mkaply

Comment 27

[jhp (no longer active)]

Attachment: patch checked in

This is the patch I checked in to the trunk.

Notice the additional change to JavaXPCOMMethods.java, where I need to special case OS/2 in order to load the glue lib with the right name.  I found a web site that said that 'System.getProperty("os.name")' returns "OS/2", but I have no system to test this with.

Comment 28

[jhp (no longer active)]

Comment on attachment 240501 [details] [diff] [review]
patch checked in

Asking for 1.8.1 branch approval.  Patch is XULRunner only.

Comment 29

[Mike Connor [:mconnor]]

Comment on attachment 240501 [details] [diff] [review]
patch checked in

a=mconnor on behalf of drivers since this doesn't affect Firefox

Comment 30

[jhp (no longer active)]

Checked in to MOZILLA_1_8_BRANCH.