Doug Ledford wrote: > It didn't loose the information, it never had it. When you link both > libs against the application binary, the linker is resolving linkups and > writing that into the resulting application binary output, but unless > it's allowed to write into the libsrqtest.so binary and modify *it's* > link table, that particular versioning information can't be written.
I thought that this might be the case, but I had never run into this before. Thanks for clearing that up. > Obviously, if every gcc compile that touched a shared library as a > source object file also attempted to write back to that source object > file, people would be very surprised when their attempt to link an > application failed due to permission problems on the shared library. Yes. I thought perhaps it would use the default ABI when the symbols were resolved when making the binary, but as I said, I've never seen this issue before. Clearly, it is working as you've described, and that one thought I had seems not to make sense. Even when I tried making my shared library the way I thought it should be done the first time, I linked libibverbs into it at shared library creation time. Only when I saw the difference did I try waiting until building the application. > Yes. If you want symbol information in a shared lib that uses other > shared libs, then they have to be linked at .so creation time, not at > application creation time. I can make this happen. I am testing it now. -- Shaun Rowland [EMAIL PROTECTED] http://www.cse.ohio-state.edu/~rowland/ _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
