On Tue, 2008-11-18 at 11:58 +0100, Roger Oberholtzer wrote:
On Tue, 2008-11-18 at 11:53 +0100, Pavol Rusnak wrote:
Larry Stotler wrote:
Does anyone know where I can get this compat-expat? I need to be able to use libexpat.so.0 instead of the newer so.1 that comes with opensuse(older program). I've seen some stuff recommending the compat-expat, but can't seem to find it. Thanx
The package is now called libexpat0 according to Shared Library Packaging Policy.
Sounds like an interesting policy to know about. Where is it documented?
http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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?
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 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dave Howorth wrote:
- 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?
No need for building with old versions of the library. You only need legacy binary for running compiled old applications. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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 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. Philipp -- 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 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)! 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. Philipp -- 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
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.
OK, so we did indeed say the same :)
Packaging a zillion variant names for a library seemed, to me, to be a bit of overkill.
Where do such packages include zillion variant names? Or do you mean the various symlinks?
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.
Sorry, but my answer is no. My most prominent example are the boost libraries (www.boost.org) where libraries for Unix/Linux have ridiculous names that include the compiler and its version, threadind/non-threading and major and minor version of the library, leading to monsters such as=20 libboost_filesystem-gcc43-mt-1_36.so.1.36.0 and that name was also used as soname. Given our shared library policy, you can imagine the riddiculous package names that would have lead. So for OS 11.1 and with the help of the upstreams boost:build maintainer I fixed the configuration to get rid of all the extra baggage, build and include only the multithreaded libs and thus use same names like libboost_filesystem.so.1.36.0.
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.
The policy talks about the names of the packages, it does not regulate in any way the way the library is built and that is how it should be. BTW, I now realize this discussion should have taken place on opensuse-packaging as that is where other packagers could have chimed in.
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.
You don't have to include a file with that name, it just makes things more obvious. And if that file doesn't exist, the next call to ldconfig (as done by the post install section of every library package) will create that symlink. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (5)
-
Dave Howorth
-
Dominique Leuenberger
-
Pavol Rusnak
-
Philipp Thomas
-
Roger Oberholtzer