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 Thu, 11 Mar 2004 09:57:48 GMT
Hi,

> 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

Joe Bester has sent a patch to use ltdl library for handler
loading. I applied the patch and it's working on linux fine.

according to the libtool documentation this should support following dynamic
loading mechanisms,

dlopen of solaris, various bsd flavors and linux
shl_load of HP_US
LoadLibrary of Windows
load_add_on of BeOS

What is the dll loading mechanism of Mac. Maybe now it works
after the patch.

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