>>>>> Mattey writes:
> CXX: gcc 3.2.3 (I'am using g++)
> LD: /usr/ccs/bin/ld
I assume you mean that you are using the native AIX linker, but
invoking "g++" to perform the link, not invoking "ld" directly.
Otherwise, using "-Wl," in the LDFLAGS could not possibly work.
> CXXFLAGS= -c -g \
> -Wno-deprecated \
> -D_AIX \
> -fpic \
> -pthread \
> -fexceptions
Why are you adding "-fexceptions"? The GNU C++ Compiler defaults
to exceptions on. This is CXXFLAGS, not CFLAGS.
> LDFLAGS= -pthread \
> -Wl,-brtl \
> -Wl,-bnoquiet \
> -Wl,-bh:5 \
> ${XERCESC_LDFLAGS}
> SHARED_LDFLAGS= -pthread -shared \
> -Wl,-bE:symbols.exp \
> -Wl,-binitfini:init:fini:0 \
> -bM:SRE \
> -Wl,-bnoquiet \
> -Wl,-bh:5 \
> ${XERCESC_LDFLAGS}
I assume LDFLAGS is for the application and SHARED_LDFLAGS is for
the shared library.
Why does LDFLAGS contain "-Wl,-brtl", but SHARED_LDFLAGS does not
contain "-Wl,-G"? Does the application use some other shared library with
System-V semantics? Not all shared libraries need to be linked with
"-Wl,-G", but "-Wl,-brtl" serves no purpose unless the shared library was
linked with "-Wl,-G". If you are using "-Wl,-brtl" for the linker to
notice shared libraries with the file suffix ".so", don't do that. AIX
shared libraries normally are archives (ar command) of shared objects.
You can use the ".a" suffix directly on the shared object instead of
creating an archive. Using the ".so" suffix for non-System-V semantics
shared objects just creates confusion.
Also, I am concerned that you need to add "-Wl,-bh:5" to your link
line. If you need to change the linker halt level from the default,
something is wrong.
You have not mentioned what errors are produced by the AIX linker
requiring raising the halt level and you have not mentioned what "problem"
you encounter if your server does many calls.
While AIX provides a thread-safe C library and GCC libstdc++-v3
strives to be thread safe, libstdc++-v3 may not interact with AIX libc in
a thread-safe manner. libstdc++-v3 makes assumptions based on GNU libc
that are not correct on all platforms. For instance, there are known
issues with libstdc++-v3 use of setlocale() in I/O functions. Does your
shared library perform threaded I/O?
User-written code interacting with libstdc++-v3 must follow the
SGI thread-safety rule, which basically says that the direct use of any
global library object (e.g. std::cout is global) or non-local object
returned from the library shared amongst user threads, must be protected
by a mutex or similar by the user.
David
