On Sun, 2008-11-23 at 04:44 +0100, Philipp Thomas wrote:
On Fri, 21 Nov 2008 10:35:08 +0100, you wrote:
Despite appearances, I think we are saying sort of the same thing.
I dont't think so.
I mentioned that the SVR4 lib tools allowed one to set this explicitly.
I guess you mean the name that gets recorded in the binary?
I am not sure how it gets set with the gcc tools.
You set the soname of a library with the -soname= option for ld. If you don't give one explicitly, it will, AFAIR, be the file name of the library.
The various Makefiles for libs do it differently. Some make a libX.so and make links to it for the libX.so.MAJ.min files. Some make a libX.so.MAJ and link to get the libX.so and libX.so.MAJ.min. All will have different soname in their libraries.
The soname that get's recorded in a binary does not depend on the symlink but rather what got recorded in the DT_SONAME field of the shared object (i.e. library)!
This is what I have been saying. Perhaps not clear enough. The name put in a binary linked with a library has nothing to do with the library's disk file name. And this is what I thought the Shared_Library_Packaging_Policy should spend a bit of time describing. Packaging a zillion variant names for a library seemed, to me, to be a bit of overkill. Only one of those names is going to be the one needed. And that name is decided by the person who made the library, not the packager of the library images or the user of the library. So, I suggested that perhaps there should be a policy for how the names are assigned to libraries when they are created. That is when the real decisions are made. As to the symlink not getting recorded in the file: what I was trying to say is that nothing from the symlink itself is used. Instead, it takes the information from wherever the symlink is pointing.
Example:
libfoo.so.1.2.3 has an soname of libfoo.so.1
No matter what the symlink libfoo.so points to, the binary linked with this library will always require libfoo.so.1.
Of course Shared_Library_Packaging_Policy is about packaging and not building. You must supply all the variant names of a file to cover all bases.
No, you use only one name and that is based on the soname as hardcoded in the shared library.
Exactly my point as well. However, my original point was that the Shared_Library_Packaging_Policy does not mention that one must be sure to include a file with that name. It just mentions making names with major and minor numbers. That is not relevant as that may not be what was used when the library was made. My sidebar about UnixWare was meant to demonstrate that soname may not be the disk file name of the library. There is nothing to stop some Makefile for a library from having one disk file name and a different soname in the library. I suggest a section that tells how to find out the soname in a library, and then be sure that there is a file with that name in the package. All other libraries should be symbolic links to that file. They can have the various names already listed in the document. This tells the name the library should have in the packages: objdump -x -headers library.so | grep SONAME It would also be good if there was a section in Shared_Library_Packaging_Policy on getting the RPM dependencies correct. Granted it is not complete, but a start could be doing objdump -x -headers library.so | grep NEEDED and being sure the RPM of these are listed as dependencies. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 -- "On two occasions I have been asked (by members of Parliament!), 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage 1791-1871) English computer pioneer, philosopher And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org