axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dami...@opensource.lk
Subject RE: porting axis-c++ to Mac OS 10.3
Date Mon, 08 Mar 2004 07:19:37 GMT
Hi Andrew,

Currently in the cvs, server module has a dependancy on client
library. I think this should be removed ASAP.
So in the current context you need to first build the current
library by
cd $AXISCPP_HOME/src/client
sh autogen.sh
sh runconfig.sh
make install

Then the library will be installed in
$AXISCPP_HOME/lib/axis.

After that you can build the server by

cd $AXISCPP_HOME
sh autogen.sh
sh runconfig.sh
make install

Note that when you build the client $AXISCPP_HOME should be set
correctly.
This procedure has been tested on redhat 8,9 and Mandrake8

If you are working with Mac OS, problem may be with the dynamic
library loader. The code which do that part is in
$AXISCPP_HOME/src/engine/HandlerLoader.cpp file. Since a mac is not
available with me I cannot test whether that code work with mac.
May be since the code there is simple you can add whatever needed
for mac


damitha



> Damitha,
>  After doing some analysis of the preprocessor output, which looked
> fine, I decided that the problem might be due to different compiler
> flags and defines that apache uses and axis-c++ uses. So, I tweaked
> those for src/server/apache. I think the critical change was to remove
> -ansi -pedantic. Now I get no fatal compile errors but I get links
> errors when I compiled in c/build:
>
> Making all in server
> Making all in apache
> /bin/sh ../../../libtool --mode=link gcc  -Wall -Wshadow  -s -o
> libaxiscpp_mod.la -rpath
> /Users/aje/src/axis/axis-cvs-source/ws-axis/c/release  mod_axis.lo
> ../../common/libcommon.la ../../engine/libengine.la
> ../../soap/libsoap.la ../../wsdd/libwsdd.la ../../xml/libxml.la
> -L/Users/aje/src/axis/axis-cvs-source/ws-axis/c/lib/expat -lexpat -ldl
> -lstdc++
> gcc -dynamiclib  -flat_namespace -undefined suppress -o
> .libs/libaxiscpp_mod.0.dylib  .libs/mod_axis.o -all_load
> ../../common/.libs/libcommon.a ../../engine/.libs/libengine.a
> ../../soap/.libs/libsoap.a ../../wsdd/.libs/libwsdd.a
> ../../xml/.libs/libxml.a
> -L/Users/aje/src/axis/axis-cvs-source/ws-axis/c/lib/expat
> -L/Users/aje/src/axis/axis-cvs-source/ws-axis/c/lib/axis
> -laxiscpp_client /usr/local/lib/libexpat.dylib -ldl -lstdc++
> -install_name
> /Users/aje/src/axis/axis-cvs-source/ws-axis/c/release/libaxiscpp_mod.0.d
> ylib -compatibility_version 1 -current_version 1.0
> /usr/bin/libtool: can't locate file for: -laxiscpp_client
> /usr/bin/libtool: file: -laxiscpp_client is not an object file (not
> allowed in a library)
> make[4]: *** [libaxiscpp_mod.la] Error 1
>
> (I switched to compiling in build vs the source tree hoping it would
> help; also, I am now building from the cvs source at the suggestion of
> Roshan). The link errors seemed seemed to indicate that maybe I have to
> build axiscpp_client.a separately. I did not see any mention of that in
> build instructions, but there was a autorun.sh file in c/src/client, so
> I tried it out. That generates a sea of errors (13,000 lines of output).
> Here are first and last few:
>
> cd src/client
> make  all-recursive
> Making all in transport
> Making all in axis
> make[3]: Nothing to be done for `all'.
> make[3]: Nothing to be done for `all-am'.
> /bin/sh ./libtool --mode=link g++  -g -O2  -s -o libaxiscpp_client.la
> -rpath /Users/aje/src/axis/axis-cvs-source/ws-axis/c
> /lib/axis  Call.lo ./transport/axis/libtransport.la -ldl -lstdc++
> g++ -dynamiclib  -single_module -flat_namespace -undefined suppress -o
> .libs/libaxiscpp_client.0.dylib  .libs/Call.o -all_
> load  ./transport/axis/.libs/libtransport.a  -ldl -lstdc++
> -install_name  /Users/aje/src/axis/axis-cvs-source/ws-axis/c/l
> ib/axis/libaxiscpp_client.0.dylib -compatibility_version 1
> -current_version 1.0
> ld: warning -dylib_install_name
> /Users/aje/src/axis/axis-cvs-source/ws-axis/c/lib/axis/libaxiscpp_client
> .0.dylib not found
>  in segment address table LD_SEG_ADDR_TABLE
> /sw/var/lib/fink/prebound/seg_addr_table
> ld: warning -undefined suppress disables -prebind
> ld: multiple definitions of symbol
> _ZNKSt12_Base_bitsetILm1EE15_M_do_find_nextEmm.eh
> /usr/lib/gcc/darwin/3.3/libstdc++.a(bitset.o) private external
> definition of absolute _ZNKSt12_Base_bitsetILm1EE15_M_do_fi
> nd_nextEmm.eh (value 0x0)
> /usr/lib/gcc/darwin/3.3/libstdc++.a(bitset.o) private external
> definition of absolute _ZNKSt12_Base_bitsetILm1EE15_M_do_fi
> nd_nextEmm.eh (value 0x0)
> ld: multiple definitions of symbol
> _ZNKSt12_Base_bitsetILm1EE16_M_do_find_firstEm.eh
>
> ---- snip ----
> ld: multiple definitions of symbol ___cxa_dyn_string_resize
> /usr/lib/gcc/darwin/3.3/libstdc++.a(dyn-string.o) private external
> definition of ___cxa_dyn_string_resize in section (__TEXT,__text)
> /usr/lib/gcc/darwin/3.3/libstdc++.a(dyn-string.o) private external
> definition of ___cxa_dyn_string_resize in section (__TEXT,__text)
> ld: multiple definitions of symbol ___cxa_dyn_string_substring
> /usr/lib/gcc/darwin/3.3/libstdc++.a(dyn-string.o) private external
> definition of ___cxa_dyn_string_substring in section (__TEXT,__text)
> /usr/lib/gcc/darwin/3.3/libstdc++.a(dyn-string.o) private external
> definition of ___cxa_dyn_string_substring in section (__TEXT,__text)
> make[2]: *** [libaxiscpp_client.la] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
>
> And so I am pretty much stuck. Note that I have never seen axis-c++
> compile successfully for me on *any* platform and the binary releases
> don't work on my redhat system, so I am flying blind.
>
> I am considering to switching my efforts to axis for java since I am
> wondering whether this release is just too green for our purposes.
> Another question I had: is there any support for sending base64 blobs of
> binary data in this release? We need this for our service so if axis c++
> does not support it, it is kind of academic.
>
> To answer your other question:
>
>>
>>
>> >      ./configure --prefix=/path/to/apache \
>> >                    --enable-module=most \
>> >                    --enable-shared=max
>>
>> By the way what does --enable-module=most do?. Does it also
>> enable module so?
>>
>
> I think it just tells apache to compile all the available modules as
> shared loadable objects, except for the module that apache uses to load
> other modules, which is still linked in statically to bootstrap the
> whole thing. I pulled this config out of a suggestion in the readme in
> the apache release. Note I actually used prefix=/usr/local/apache, not
> /path/to/apache.
>
> Thanks for your help,
>
> Andrew
>
>


Mime
View raw message