Hi there,
have been trying to get acquainted with MacOSX, which is not that easy
at all, if one has never worked on that platform.
In the meantime I have been able to adapt the BSF4ooRexx.cc to not
generate any warnings with MacOSX g++. It has also been possible to
create a i386 (32-bit Intel) and x86_64 (64-bit-Intel) library, as well
as combining both as a universal library. The makefile I came up with is
given at the end of the message.
However, like the students have reported a couple of times the 32-bit
version causes bus errors which are created by an "invalid memory
access", when in librexx.4.dylib ("RexxInternalObject::isBaseClass() +
9". The error occurs while a Rexx program is executing, which got
started via Java using BSF4ooRexx; after a couple of interactions with
Java from Rexx an ooRexx string return value gets returned from a
BSF4ooRexx external Rexx function at which point the reported error
occurs. Any ideas/hints highly appreciated as to possible reasons for
this behaviour. [The loading of all dylibs has been successfully carried
out in 32-bit.]
The 64-bit version of BSF4ooRexx works with the 64-bit versions of
ooRexx and Java without an error!
---
This is running Bruce's 4.0.1 build in 32- and 64-bit Intel mode. Maybe
the 32-bit version of ooRexx for MacOSX has a problem?
@Bruce: would it be possible for you to create a 32-bit version of the
release version of ooRexx 4.1.0 by any chance (a tgz-file would be just
fine)? Maybe you could take a look at my makefile in the case I made an
error there?
TIA,
---rony
P.S.: The MacOSX, especially with Java, poses some challenges, to say
the least, if one wishes to demand load the JVM in the right mode:
* the 32-bit version (i386) will find and map the dylib, but is not
able to retrieve the entry point for the "JNI_CreateJavaVM"
function (dlsym() returns a NULL handle);
* the 64-bit version (x86_64) does not find an appropriate
libjvm.dylib, dlerror() yields: "dlopen(libjvm.dylib, 9): no
suitable image found. Did find: /Developer/.../libjvm.dylib: can't
map"; however the indicated dylib according to lipo is a
"dynamically linked shared library i386" and "dynamically linked
shared library x86_64".
Using "file" however indicates that only stubs are there, looking
at the dylib entry it shows that it is a link to "libclient.dylib"
(which is both, 32- and 64-bit dynamically linked shared). Using
"libclient.dylib" yields the same error as using "libjvm.dylib".
Thankful for any ideas as well!
---------------- cut here ---------------------
# usage: make -f makefile-rgf.mac [all \ universal \ clean ]
# rgf, 2011-01-02
INC_PATH = -I. -I/System/Library/Frameworks/JavaVM.framework/headers
INC_PATH_ORX = -I/opt/ooRexx/include $(INC_PATH)
# LIB_PATH = -L/opt/ooRexx/lib/ooRexx
LIB_PATH = -L/opt/ooRexx-i386/lib/ooRexx -L/opt/ooRexx-x86_64/lib/ooRexx
CFLAGS = -fPIC
LFLAGS = -shared
# --------------------------------------------------------
all: i386 x86_64 universal
i386: BSF4ooRexx.cc
g++ -c $(CFLAGS) $(INC_PATH) -I/opt/ooRexx-i386/include -m32 -arch i386
-DUSE_OREXX -DUNIX -DBSF4REXX_32_BIT -oBSF4ooRexx-mac-i386.o BSF4ooRexx.cc
g++ -dynamiclib $(LFLAGS) -o libBSF4ooRexx-i386.dylib
BSF4ooRexx-mac-i386.o /opt/ooRexx-i386/lib/ooRexx/librexx.dylib
/opt/ooRexx-i386/lib/ooRexx/librexxapi.4.dylib -framework JavaVM -arch i386
x86_64: BSF4ooRexx.cc
g++ -c $(CFLAGS) $(INC_PATH) -I/opt/ooRexx-x86_64/include -m64 -arch
x86_64 -DUSE_OREXX -DUNIX -DBSF4REXX_64_BIT -oBSF4ooRexx-mac-x86_64.o
BSF4ooRexx.cc
g++ -dynamiclib $(LFLAGS) -o libBSF4ooRexx-x86_64.dylib
BSF4ooRexx-mac-x86_64.o /opt/ooRexx-x86_64/lib/ooRexx/librexx.dylib
/opt/ooRexx-x86_64/lib/ooRexx/librexxapi.4.dylib -framework JavaVM -arch x86_64
universal: BSF4ooRexx.cc i386 x86_64
lipo -create -output libBSF4ooRexx.dylib -arch x86_64
libBSF4ooRexx-x86_64.dylib -arch i386 libBSF4ooRexx-i386.dylib
# cp libBSF4ooRexx.dylib libBSF4ooRexx.jnilib
.PHONY: clean
clean:
rm -f *.dylib
rm -f *.jnilib
rm -f *.o
------------------------------ cut here ----------------------------------
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
