axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dinesh Premalal" <>
Subject Re: AXIS2/C OpenVMS Port
Date Mon, 29 Oct 2007 08:26:20 GMT

  Please find my comments inline.

On 10/24/07, Stadelmann Josef <> 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
> 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.
> GSMATCH=lequal,1,1000
>                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.


View raw message