On Tue, 2008-11-18 at 12:07 +0000, Dave Howorth wrote:

Dominique Leuenberger wrote:

...

http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy

Interesting. I have a couple of dumb questions:

There doesn't seem to be any discussion about installing both 32-bit and 64-bit versions. Does that mean there are no issues? How are the packages distinguished?

My dumb question is: When the .so file is installed from the -devel package, should it symlink to the lib with the major number only, or the lib with the major and minor numbers? This will, of course, effect the lib any programs that are built will want at runtime: it will want the one that the .so was symlinked linked to at link time on the system on which it was built, NOT where it points at runtime in the system it runs on. Which is of course why this useful doc exists in the first place. But I missed this point. Whichever one it links to is the only one that needs to be distributed, because that is the only one that will be looked for. I think that as long as the choice is allowed, there will be confusion. Perhaps the -devel package should do symlinks as: libX.so -> libX.so.1 libX.1.2.3.so -> libX.so.1.2.3 So, if I use -lX, I get the major release version. After all, I was not specific. If I use -lX.1.2.3, I get the very specific version. It is fully backwards compatible. The use of '.' or '-' or '_' is a detail. I remember that the AT&T SVR4 compiler had an option when making libs that told what file should be looked for at runtime - independent of the name of the file that was linked when a program was made. Madness, you say? Perhaps. But the intention was that, no matter what the ultimate sym link pointed to at program compile built time, the library would tell what should be looked for at runtime. When the library is built, the decision is made. What it is called in the various places it may get installed (.so. or so.major or .so.major.minor) was not important. All those odd local links need not be distributed in a runtime lib. Only the original name used when the lib was made is delivered. Not a bad feature, IMHO.

...

Exceptions (1) Shared libraries which are used solely and only by programs from the containing main package ... - ... - no devel files for those shared libs are packaged anywhere ...

Perhaps I'm being dumb, but how is the main package built if there are no devel files?

Cheers, Dave

-- 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

On Fri, 2008-11-21 at 10:07 +0100, Philipp Thomas wrote:

On Tue, 18 Nov 2008 14:46:43 +0100, you wrote:

...

This will, of course, effect the lib any programs that are built will want at runtime:

No, it won't! The soname, i.e. the internal name of a library is recorded in the binary (the NEEDED entries when running 'objdump -p' on it) that needs it and the dynamic linker will look for this name. That's the reason why ldconfig will create that symlink (full version -> soname) if it doesn't exist.

BTW, 'objdump -p' will show the soname.

Despite appearances, I think we are saying sort of the same thing. I see the issue as Shared_Library_Packaging_Policy not being explicit on this point: the name of the file that you link with is not necessarily the name of the file you will need at runtime. The soname in the library is the name that gets put in the application. I mentioned that the SVR4 lib tools allowed one to set this explicitly. I am not sure how it gets set with the gcc tools. The question is not what one or the other tool allows. It is how they are used. 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. 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. -- 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

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