Hello! We are currently making a reconfiguration to our make file ruleset and come along with a phenomena where we can link in our own library thus being able to define rulesets that can be used to both build the library from scratch as well as publish the same ruleset to components with dependencies to that library. Our question is if its an undocuemented feature or working as intended. We have the ruleset. ifeq "$(BCAF_MSGSVC-IFD)" "1" INCPATH += -I$(TOPDIR)/$(BCSW)source/bcaf/af_ifd_msgsvc LDPATH += -laf_ifd_msgsvc.so BCAF_BASETYPES-IFD=1 EPP_LDPATH=1 endif This can be compiled but when we link it with the command: g++ -shared -laf_ifd_msgsvc.so -L/home/workspace/epp-rulesset-change-tck69/lib/linux_x86 -L/home/workspace/epp-rulesset-change-tck69/lib/linux_x86 -o libaf_ifd_msgsvc.so AFSendMsgToObjMgrIF.o AFBaseMsgC.o AFErrorIndicationMsgC.o AFMsgSvcIFPkg.o -lACE /opt/rhapsody_oxf/LangCpp/lib/linuxoxf.a we get a failure that it cannot find the libaf_ifd_msgsvc.so file. But if we change the link option to: g++ -shared -o -laf_ifd_msgsvc.so -L/home/workspace/epp-rulesset-change-tck69/lib/linux_x86 -L/home/workspace/epp-rulesset-change-tck69/lib/linux_x86 -o libaf_ifd_msgsvc.so AFSendMsgToObjMgrIF.o AFBaseMsgC.o AFErrorIndicationMsgC.o AFMsgSvcIFPkg.o -lACE /opt/rhapsody_oxf/LangCpp/lib/linuxoxf.a i.e adding the –o flag in the start as well we can compile it as well as linking to it in the same ruleset. This makes it easier to maintain the compile options in one file both for building as well as linking in dependencies to it. But is it undocumented feature that it seems to ignore the linking to its own library when used and should not be trusted for future releases of the compiler. We are running gcc version 3.4.6. In the test we have done building from scratch where the lib doesnt existst as well as when the library exists it seems to work with our current unittests etc. // Andreas
