Hi, Please find my comments inline.
On 10/24/07, Stadelmann Josef <[EMAIL PROTECTED]> wrote: > > Hi developer team, > > I have ported almost a great part of AXIS2/C to HP Alpha/OpenVMS > > so far, all basic libs (zlib, libxml2, ... ) a re running, are tested, > > so far, libxml2 is built and test after I have managed to move the test > and result xml files correctly to OpenVMS > > so far, axutil is ported and has passed all given test (including uuidgen) > > so far, axiom is ported and has passed all existing tests (could use more > testing on that component) > > so far, all core and module sources are compiled and .obj's are inserted > into relevant .OLB files > > so far, axis2_http_server.c is compiled and linkes with only 3 minor > warnings BUT IT FAILS ON STARTUP > > The reason is that AXIS2_PLAFTFORM_LOADLIB (axutil_class_loader) uses > > #include <dlfcn.h> > void *dlopen (char ****pathname*, int*** mode*); > > BUT my pathname arg points i.e to axis2_mod_addr.olb which is wrong and > must be axis2_mod_addr.exe implemented as a shareable image > > On a Alpha/OpenVMS system, shareable Images depend on a option file for > linking, defining a transfer vector to gloabl processes, data, symbols, etc. > > i.e. > > $ LINK/SHAREABLE MY_MATH, SYS$INPUT/OPT > GSMATCH=lequal,1,1000 > SYMBOL_VECTOR=(myadd=PROCEDURE,- > mysub=PROCEDURE,- > mymul=PROCEDURE,- > mydiv=PROCEDURE,- > my_symbol=DATA,- > my_data=PSECT) > *[Ctrl/Z]* > > I would like to know from you dear team members, which routines, symbols, > etc. of > > addr_in_handler.c;2 > addr_out_handler.c;2 > mod_addr.c;2 > > I do have to declare in this option file as PROCEDURE, DATA, PSECT > > How can I get this information from existing axis2_mod_addr.lib's out of > Visual Studio C++ 2005, which I use for parallel development purpose, and > then move the source to OpenVMS. > > I have made some MMK make files to build the components; not as clean as > delivered, all in absence of dozends of unix tools (automake configure > libtool etc) on OpenVMS, they need improvments in the area of generic and > intrinsic rules, also maybe a better MMK.EXE would do the job more cleaner > by following sub dirs etc. i.e. build of this mmk description files is a > major work; > I think you could get an idea about build frameworks of both unix and window by looking at make files and nmake files. I would recommend you to look at nmake file which is located in build/win32/makefile , which will be much more useful to get the details that you asked. thanks, Dinesh
