likong@email.com schrieb:
> Hi,
>
> Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is
> 9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is
> NOT possible to update customer's xlC.rte.

If this is true, you should downgrade your dev machine. But I don't know
a good reason, why it should not be possible to upgrade the C++ runtime
libs on the production machine.

--
Uli

likong@email.com writes:

> Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is
> 9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is
> NOT possible to update customer's xlC.rte.

As Uri Link noted, your simplest choice is to build using xlC v6.0
in that case.

> Things we have tried:

You are trying "random" permutations of reasonable approaches
(reasonable in that they all could have worked), and abandoning them
half-way because they "don't work". But you are not analyzing
*why* they don't work (i.e. you are not understanding the
problem, and are thus "programming by coincidence" -- see
http://www.pragprog.com/the-pragmati...ts/coincidence).

Now, to really understand why your methods don't work would require
an expert on AIX dynamic linking. You can try to find a consultant
that would solve your problem, or you can try asking "smart"
questions here (Gary Hook is the resident linking expert).

This link will tell you how to ask questions that are likely to
produce useful answers: http://catb.org/esr/faqs/smart-questions.html

> 1. static link our the dynamic linked lib (apache module) to version 9
> of libC.a. But somehow the module still needs to dynamically link
> with version 9 of libC.a.

What was the link line? What is the output with '-bnoquiet' ?
What is the output from 'dump -Tv your_module.o' ?

> 5. We tried to statically link the apache module with all .o files
> extracted from v9 of libC.a. But somehow the apache module still
> references v9 of libC.a.

Did v9 libC.a contain 'shr.o' (probably did).
Do you understand that 'shr.o' is a shared library, and not a
'regular' object? If you didn't, you have a *long* way to go before
you understand AIX shared library model.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul Pluzhnikov wrote:
> likong@email.com writes:
>
>> Our development machine is AIX 5.3 with XLC/C++ 9.0. Its xlC.rte is
>> 9.0. Our customer's machine is also AIX 5.3 with xlC.rte 6.0. It is
>> NOT possible to update customer's xlC.rte.
>
> Now, to really understand why your methods don't work would require
> an expert on AIX dynamic linking. You can try to find a consultant
> that would solve your problem, or you can try asking "smart"
> questions here (Gary Hook is the resident linking expert).

Yes, please ask smart questions.

Short answer: what you are doing is unsupported. If you need to support
the 6.0 runtime, then you need to build with the 6.0 compiler and runtime.

Please push on the customer to update their runtime level. There is no
reason not to do so, as all later versions support apps built on earlier
versions.


> This link will tell you how to ask questions that are likely to
> produce useful answers: http://catb.org/esr/faqs/smart-questions.html
>
>> 1. static link our the dynamic linked lib (apache module) to version 9
>> of libC.a. But somehow the module still needs to dynamically link
>> with version 9 of libC.a.

Don't even try to statically link your copy of libC.a into your module.
A single process can _not_ have more than one instance of the C++
runtime and be expected to work, but this scenario would require exactly
that. Completely unsupported.

Longer answer: don't do that. Set your requisites for your customers
and require them to meet those requisites. Or develop on an older level
so you can satisfy and support older levels.

--
-------------------------------------
http://www.photo.net/photos/garyrhook
Vocatus atque non vocatus deus aderit

"Gary R. Hook" writes:

> Don't even try to statically link your copy of libC.a into your module.
> A single process can _not_ have more than one instance of the C++

Can't it?

If the library has only 'extern "C"' interface, is statically linked
with C++ runtime, *and* that runtime is completely hidden (not
exported), technically one can't tell that there is C++ runtime
inside; it's just a "black box" with C-callable interfaces.

Now, obviously you can't throw out of the library, but most everything
else would still work, wouldn't it?

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Paul Pluzhnikov wrote:
> "Gary R. Hook" writes:
>
>> Don't even try to statically link your copy of libC.a into your module.
>> A single process can _not_ have more than one instance of the C++
>
> Can't it?
>
> If the library has only 'extern "C"' interface, is statically linked
> with C++ runtime, *and* that runtime is completely hidden (not
> exported), technically one can't tell that there is C++ runtime
> inside; it's just a "black box" with C-callable interfaces.
>
> Now, obviously you can't throw out of the library, but most everything
> else would still work, wouldn't it?

I understand your point, but I believe the answer is no. Black box
or not, the runtime does hook into other parts of the process (libc,
libpthreads, etc) and there _might_ be issues because of that.
Therefore, just like libc.a(shr.o) I believe that two instances
of libC.a(*) is an unsupported configuration. Someone from Toronto
would have to chime in with an official position; I'm simply
relaying my understanding.

--
-------------------------------------
http://www.photo.net/photos/garyrhook
Vocatus atque non vocatus deus aderit

It seems to me that we found a solution, without upgrading the
client's xlC.rte from v6 to v9.

What we did was
1. compile the apache module as dynamic link lib as before.
2. run the command rtl_enable (that comes with AIX 5.3) against libC.a
in v9 xlC.rte to generate a new libC.a. Do the same for libC_r.a
(actually these two lib point to the same file.)
3. copy both libC.a and libC_r generated from rtl_enable to a target
directory on the client's machine (with older xlC.rte). Include this
directory in front of LIBPATH before starting apache server.

I ran "genld -l" and indeed apache server references the two new lib
without referencing the older /usr/lib/libC.a nor /usr/lib/libC_r.a.

Thanks.

Kong