Rod Evans wrote: > Wyllys Ingersoll wrote: >> >> I am building a library that is dyamically loaded >> by an app via dlopen(3C). The plugin library I am >> working on depends on the NSS libraries in /usr/lib/mps >> (yes, we have a contract to use them). >> When I do *not* turn off the ZDEFS, I get the following >> messages when I build the library: >> >> Undefined first referenced >> symbol in file >> PR_Delete pics/nss_spi.o (symbol belongs >> to implicit dependency /usr/lib/mps/libnspr4.so) >> ... >> >> Is disabling ZDEFS the proper way to deal with this? The code runs >> fine once >> it is built, so I don't think there is a problem with unreferenced >> code at runtime. >> >> My library Makefile currently uses this which seems to make the >> message go away. >> ZDEFS=$(ZNODEFS) > > > The library you are building references PR_Delete, and thus *your* > library should have an explicit dependency on the provider of this > function (libnspr4.so?). > > As part of the link-edit, ld(1) has found a definition, but through > an implicit dependency. Perhaps you have: > > % cc -o my-plugin $(MY-OBJECTS) -lfoo > > where libfoo.so.1 has a dependency on libnspr4.so. Thus libnspr4.so > is getting pulled in with the use of zdefs, but in an indirect manner. > > The reason for the error condition is that it's possible that a new > version of libfoo.so.1 gets delivered in the future, and that this new > version no longer has a dependency on libnspr4.so. If this did happen > your plugin would no longer have the dependencies it needs to satisfy > its references. > > The use of -zdefs insures that *you* define the dependencies you need, > rather than finding symbol definitions from third parties. This makes > your object robust in the face of changes other may make in future. > >
Thanks for the clarification. I will update my Makefile to include -lnspr4 and see if that clears it up. -Wyllys
