Roopa V <roopa.v1@xxxxxxxxx> writes: > I have tried both the approaches. Approach 1 will have libdynamic > compatibility issue. The libstatic library is not backward compatible > and libdynamic promises backward compatibility. > If libdynamic uses libstatic APIs which are not supported in its older > versions of libstatic and application links to older libstatic, then > libdynamic will not be able to resolve its libstatic symbols. So as > per the design, libdynamic shared library is advised to carry its > libstatic with it. Is there any linker option which overrides global > precedence over local scope? That makes it sound like you need to support the case of an application linked against an older libstatic and a shared library linked against newer libstatic. As far as I can see, that can only work if you are prepared to tolerate duplicate instantiations of libstatic. I'm not sure what you mean by "overrides global precedence over local scope." You may want to look at the -fvisibility compiler options. > With the approach 2, I have to keep track of all global symbols of > libstatic library in the future and export them in the libdynamic > export file. Maintainability will be a problem. libstatic.a is the > static library which provides some common functionalities which are > used by both the application and libdynamic library. Yes, maintainability is a problem. > I have also tried undefining libstatic symbols in libdynamic so that > they resolve at link time of the application. This can be done using > ld linker option --undefined=symbol, but this is not working for me. The --undefined option does not turn a defined symbol into an undefined symbol. It starts the linker off with an undefined reference. Ian
