1) If the 2.0.45 header files will be backwards compatible with apache 2.0.43.
Here is how we would state it:
Build your module for 2.0.43 and it will work with 2.0 releases >= 2.0.43.
There is no promise that your module will load into an older Apache, and you may rely on compatible data structure changes (e.g., some field added to end of request_rec with 2.0.45) that aren't in the older Apache.
2) We were able to load library by doing away with -G option and adding the apr.exp and aprutil.exp.
The final link line being :
/usr/vacpp/bin/makeC++SharedLib_r -p 0 -bnoipath ../../Rosette30/unix/lib/aix-xlC_r/libbtunicode.so -b :SRE -berok -bnoentry -blibpath:/usr/lib/threads:/usr/ibmcxx/lib:/usr/lib:/lib -s -bI:/usr/IBMIHS/modules/httpd.exp -bI:/usr/IBMIHS/lib/apr.exp -bI:/usr/IBMIHS/lib/aprutil.exp -bE:my_lib.exp
Please can you suggest why -G option is preventing our library to load as this flag is required to produce the shared object. As we are using makeC++SharedLib_r instead of ld.
I don't know off the top of my head. The way to find out is to take the DSO linked with -brtl (instead of -G, that was my bug) and
1) use dump -Hv to see what libraries the DSO wants, and verify that they can all be loaded, either by the default search order built into the DSO or via LIBPATH
2) use dump -Tv to see what symbols the DSO imports, and verify that something loaded before the DSO actually exports such symbols
