Date: 28 Feb 2003 20:00:34 -0800 From: Joe Kelsey <joek@flyingcroc.net> To: John Polstra <jdp@polstra.com> Cc: ports@freebsd.org, joek@mail.flyingcroc.net Subject: Re: WARNING: portupgrade considered harmful Message-ID: <1046491234.458.53.camel@zircon> In-Reply-To: <200303010232.h212WkFj000353@vashon.polstra.com> References: <3E5FB1F8.4050405@mail.flyingcroc.net> <3E5FD22B.3040904@mail.flyingcroc.net> <200302282148.h1SLm8pc031639@vashon.polstra.com> <3E5FEE23.8050403@mail.flyingcroc.net> <200303010232.h212WkFj000353@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2003-02-28 at 18:32, John Polstra wrote: > In article <3E5FEE23.8050403@mail.flyingcroc.net>, > Joe Kelsey <joek@mail.flyingcroc.net> wrote: > > What I objected to before and what I still object to in the shared > > library is that it allows loading of *multiple* copies of a single > > library as many times as are requested. > > It's not supposed to do that. Do you have a test case that > demonstrates it, or some "ldd" output that shows it happening? The > code that loads a shared library checks to see if the library is > already loaded, and if it is then it just adds a reference to it > instead of loading it again. It checks by pathname and it checks by > device + inode number. I believe that the correct behavior is to leave off the version number and directory when checking for duplicates. I believe that that behavior matches Solaris and Linux. > > It also allows loading of multiple different versions of the same > > library as many times as requested. > > It's true that it allows multiple versions of the same library to be > loaded. But it loads each version only once. > > > Neither Solaris nor SVR4 support this behavior. > > I haven't tested Solaris lately, but I think you're wrong about > SVR4. The SVR4 dynamic linker didn't know anything about version > numbers. It has been a long time since I have used a true SVR4 system, and I do believe that you are correct. However, there were plenty of things wrong with the shared library implementation on SVR4 besides that... > > I have no idea why the FreeBSD loader supports it. It is > > explicitly supported plainly in the code of the runtime loader. > > I don't know what you mean by that. The code checks for matching > files, nothing more and nothing less. It doesn't know anything > about version numbers. Here is the actual bug from my work trying to get the JVM to work. The problem with Java is that it uses a combination of shared libraries, some of which are explicitly requested at run-time. *some* of the shared libraries loaded at run-time using the dlopen calls. The problem is that if some shared library included the linker commands to load other shared libraries, these were not checked when performing the explicit dlopen. If a previous shared library was loaded through the linker reference method, it was loaded *again* by dlopen and *not* reference checked! This is contrary to the way that Solaris behaves. The Java make files are riddled with people who do not understand shared libraries wildly linking shared libraries toghether with -l switches. This causes a *huge* problem on FreeBSD because you have to carefully audit each and every little makefile to track down some foolish shared library linking problem. Then, you have to go back and carefully replace only those libraries which *really* need to be linked together to achieve the correct balance between Java's explicit dlopen and the automatic referencing of other libraries needed. It was an *extremely* frustrating experience to try to debug the jvm because it would segfault for no discernible reason. It was only by putting a breakpoint in dlopen and looking at each and every library loaded before and after that I was able to see the double-loading of libraries. I consider the loading of duplicate, gratituitous libraries differing only by version number to be a similar fault. I am willing to let that go as possibly too much of a linuxism, but I really do not like it. I do not recall it ever being a problem on solaris, probably because they didn't overuse explicit numeric linking that way people seem to do on FreeBSD. I personally think that there is far too much dependence on using explicit library version numbers, causing horrid problems for upgrading. Of course, I think that this is a very thorny issue. I think that the dlopen versus linker reference problem still exists and is a very real bug. The loading of multiple libraries based on number is something I consider a bug, but I agree to disagree with you on that. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1046491234.458.53.camel>