Strange Invalid connection handle when adding in "proxy shared lib"?

I am doing some C code on a Solaris SPARC system and am scratching my head at an "inconsistency" I have found in my integration testing.

I am doing some tests into an SAP system and am using the SAP RFCSDK, but SAP is not my question here at all.....I am wondering if I am missing some compile options etc

Let me try explain:

Client code -> Shared lib(custom) -> Shared Lib (SAP) -> SAP === works 100%

Client code -> Shared lib(custom PROXY)-> Shared lib(custom) -> Shared Lib (SAP) -> SAP ==INVALID handle

So without going into too much detail have you ever heard of any "handle" becoming invalid just because another shared lib was "inbetween" the client and "destination shared lib"?

The PROXY shared lib that is causing the issue with the INVALID HANDLE does nothing special, just a "pass through"

#include <stdio.h>
#include <stdlib.h>
#include "saprfc_receiver_proxy.h"
#include "saprfc_receiver.h"

int saprfc_receiver_proxy_initialize(char *sap_hostname, char *sap_client,
       int sap_sysnbr, char *sap_language, char *sap_user, char *sap_password,
       int sap_rfctrace){
    return saprfc_receiver_initialize(sap_hostname, sap_client, sap_sysnbr,
               sap_language, sap_user, sap_password, sap_rfctrace);
}

int saprfc_receiver_proxy_beginTransaction(char *tid){
    return saprfc_receiver_beginTransaction(tid);
}

int saprfc_receiver_proxy_commitTransaction(char *tid){
    return saprfc_receiver_commitTransaction(tid);
}

int saprfc_receiver_proxy_rollbackTransaction(char *tid){
    return saprfc_receiver_rollbackTransaction(tid);
}

int saprfc_receiver_proxy_writeMessage(char *tid, char *buffer){
    return saprfc_receiver_writeMessage(tid, buffer);
}

int saprfc_receiver_proxy_openConnection(){
    return saprfc_receiver_openConnection();
}

int saprfc_receiver_proxy_closeConnection(){
    return saprfc_receiver_closeConnection();
}

The compilation is very straightforward, here is the shared lib compile that calls the SAP shared libs directly:

/usr/sfw/bin/gcc -m64 -R/usr/sfw/lib/64 -c -fPIC -I../include \
    -I../rfcsdk/include saprfc_receiver.c -o saprfc_receiver.o
/usr/sfw/bin/gcc -m64 -R/usr/sfw/lib/64 -shared -L../rfcsdk/lib/ \
    -o libsaprfc_receiver.so saprfc_receiver.o -lrfccm -lrfc

And here is the proxy shared lib compile:

/usr/sfw/bin/gcc -m64 -R/usr/sfw/lib/64 -c -fPIC -I../include \
    saprfc_receiver_proxy.c -o saprfc_receiver_proxy.o
/usr/sfw/bin/gcc -m64 -R/usr/sfw/lib/64 -shared -L../lib \
    -o libsaprfc_receiver_proxy.so saprfc_receiver_proxy.o -lsaprfc_receiver

So is there any "golden rule" when using C t开发者_开发技巧o make sure that "shared libs in between" do not influence the state at all?

Sorry if my explaining is bad, I will try edit this post later with more detail....

The bottom line is that if the client calls the shared lib (custom) directly then it works, the moment I add a SIMPLE proxy in between the SAP handle goes bad.