|
From: Andreas W. <And...@ei...> - 2003-10-13 08:41:52
|
Eric,
since you didn't provide the error messages you get when running the =
wrapper, it's hard to tell what your problem is.
I'm also not quite sure if you mentioned it, but what are the versions =
of your OS and GCC?
BTW, you should link the executable and the library with the same linker =
and not one with gcc and one with ld.
Cheers,
Andreas
> -----Original Message-----
> From: EXT-Smith, Eric M [mailto:eri...@bo...]
> Sent: Friday, October 10, 2003 5:39 PM
> To: wra...@li...
> Subject: [Wrapper-user] Re: HP-UX libwrapper.so fails to load
>=20
>=20
> Leif, et al.
>=20
> I have run some simple tests using the input from Andreas=20
> Wendt (Thank you Andreas).
>=20
> Here is what I have come up with so far: The problem is in=20
> the way that wrapper is built.
>=20
> I came to this conclusion after the following:
>=20
> 1) Modified the Makefile.hpux file as follows:
> a) Set up the following as the definitions:
> DEFS =3D -I/opt/java1.4/include=20
> -I/opt/java1.4/include/hp-ux
> DEFVALS =3D -DHPUX -D_HPUX=20
> -D_POSIX_C_SOURCE=3D199506L -D_XOPEN_SOURCE_EXTENDED
> OPTS =3D -ansi -fPIC
> COMPILE =3D gcc -c $(DEFVALS) $(OPTS) $(DEFS)
> COMPILE_LINK =3D gcc $(DEFVALS) $(OPTS) $(DEFS)
> LINK =3D ld -b
> realpath_SOURCE =3D realpath.c
> wrapper_SOURCE =3D wrapper.c wrapper_unix.c=20
> property.c logger.c
> wrapper_OBJECTS =3D wrapper.o wrapper_unix.o=20
> property.o logger.o
> libwrapper_sl_SOURCE =3D wrapperjni_unix.c wrapperjni.c
> libwrapper_sl_OBJECTS =3D wrapperjni_unix.o wrapperjni.o
> BIN =3D ../../bin
> LIB =3D ./../lib
>=20
> b) changed the rule for wrapper to
> wrapper: $(wrapper_SOURCE)
> $(COMPILE_LINK) $(wrapper_OBJECTS) -lm=20
> -o $(BIN)/wrapper
>=20
> c) changed the rule for libwrapper to=20
> libwrapper.sl: $(libwrapper_so_OBJECTS)
> ${COMPILE} $(libwrapper_sl_SOURCE)
> ${LINK} -b -o $(LIB)/libwrapper.sl=20
> $(libwrapper_sl_OBJECTS)
>=20
> d) changed the compile rule to
> %.o: %.c
> ${COMPILE} ${OPTS} ${DEFS} $<
>=20
> 2) Ran the entire build as follows:
> ./build.sh clean
> ./build.sh compile
> ./build.sh main
> I know the main build rule takes care of everything, but I=20
> did this just to be sure.
>=20
> 3) Edited the conf/wrapper.conf file to point to the proper=20
> JAVA_HOME and libwrapper.sl file . <<NOTE, the .sl and not=20
> .so extension>>
>=20
> 4) Changed the SHLIB_PATH environment variable to reference=20
> the wrapper/lib directory.
>=20
> 5) Tried running bin/testwrapper console
> Failed
>=20
> 6) Tried running bin/wrapper with the proper parameters
> Failed
>=20
> 7) Tried running the org.tanukisoftware.wrapper.test.Main=20
> class straight from Java
> Success
>=20
> Then to be sure the shared library was loading...
>=20
> 8) Added lines to the WrapperManager.java bracketing the=20
> System.loadLibrary
>=20
> 9) Tried running the org.tanukisoftware.wrapper.test.Main=20
> class straight from Java to see the bracketing labels
> Success
>=20
> Therefore, I am now looking at how wrapper is built for a solution.
>=20
> I have already tried splitting the compilation and linking=20
> for wrapper (using gcc and ld), but the resulting file is not=20
> executable.
>=20
> Our biggest problem is the lack of the native HP-UX ansi C=20
> compiler on our test machine. We are stuck with ISO C89=20
> unless we use gcc. We are searching for an ansi compiler=20
> in-house, but haven't found one yet.
>=20
> Any suggestions (other than locating the ansi c compiler)?
>=20
> Eric M. Smith
> InfoStructure Systems
> Boeing Chairman's Innovation Initiative
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>=20
|