Date: Fri, 10 Sep 1999 09:36:39 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions Message-ID: <37D8B507.CC33F50F@scc.nl> References: <199909100030.EAA02516@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitrij Tejblum wrote: > > > > It is other way around. I don't want half of FreeBSD binaries linked > > > with libc.so.3 and half is linked with libc.so.4. > > > > Recompile. You have the sources. > > ??? What recompile? Why do you think I have the sources - there is > quite a few binary-only FreeBSD programs? Why should I waste my time by > recompiling and reinstalling something? Why should I waste my time and > network bandwidth by downloading every package twice - for -stable and > for -current? Because you can't live with having two actively used versions a library. You have the problem; you also have the solution. I don't want the complete history of development bundled in a library. That's my problem. Now tell me how do I solve it? > > > related example: one kernel support all binaries, why libc should be > > > different?) > > > > The difference is that a library is a static object, > > I can't parse the above line s/static/passive/g > > while a kernel > > actively maintains that compatibility. There's code involved to do that. > > Something a library can't handle for itself. And that's precisely why you > > need versioning: to assist in maintaining compatibility. > > You described the existing situation. You could notice that I suggest to > change it. Strange. You are the one that is also refering to rules and standards that are in use now and you are using that to validate your point. Now you are telling me that you actually are diverting from the rules and a proposing a change? Why am I having this discussion? > > > > Your suggestion has more impact than that. It violates POLA. In all case a > > > > certain function is called `foo' except in the library where it resides, > > > > where it is called `bar'. > > > I didn't invent the idea. NetBSD do it for a long time. > > I don't care who invented the idea. We're discussing this and we both have > > our opinions on this matter. The fact that NetBSD uses it for some time > > doesn't make it right. > > My point is just that NetBSD give an experience, in particular w.r.t. POLA > violations. You also ignored my refence to <arpa/inet.h>. I will > expand: When you see call to inet_aton() in the source, your object file > actually call __inet_aton(). This is quite similar to the thing I > suggest. This is the case at least still 3.0-RELEASE. From this > experience we can say that POLA violation here is very low. The fact that it has been done, doesn't mean that it is a good thing. It also doesn't validate to do it again (especially as a policy). > OK, I failed to convince you. New attempt: I am switching to your > original question. > > > Since libc and libc_r have changed on the interface level, they > > need a version bump. I assume that all others automaticly also need a > > version bump then. Am I correct in this assumption? > > Yes. You need to manually bump version of every other library, > including those from ports. You also going to have some fun when the > version of the "other library" need to be bumped by its internal > vendor-specific reasons. No, I was not correct in that assumption. Libraries that don't use the changed datatype do not need a version bump. > Look: suppose there is libfoo.so.15, that use, say, setjmp() for its > internal purposes. If you didn't recompile the library, you cannot > build new programs with it: the library will call setjmp() from > libc.so.4, while it want to call setjmp() from libc.so.3. Correct. > If you recompile libfoo and > didn't bump its version, old programs linked with libc.so.3 will break - > libfoo will call setjmp() from libc.so.3 where it want to call setjmp() > from libc.so.4. So, you have to bump the version number. Also correct. > You probably already understand above. So, what's the plan? Do you > actually plan to bump the version of every library under the moon? No. > Or you will say - oh, if some programs borke, just recompile them? Not if this was to happen on -stable. > Or do > something like linux when they switched from libc5 to libc6 - I believe > they have had separate directories for libc5 and libc6 worlds? libc5 and glibc2 coexist, yes. Listen, you made a good point. It clearly shows where the problem is. The "solutions" we have been discussing aren't the proper solutions. The current situation doesn't handle the (complex) dependencies, because there's no way you can "bind" a version of a library (say libfoo.so.15) to a version of another library (libc.so.3). A version bump messes things up if you're not careful. That's why we already minimize version bumps. Having all versions of a library called the same has also its disadvantages. First of all every incarnation of a function is present in a library. In the long run this will unnecessary bloat the library. Every incarnation has to be named differently. First incarnations are named as published, new incarnations are not. Secondly, maintenance of the library will be more cumbersome with every major change made. Since it's the programmer that has to do the maintaining, I'm not surprised if he himself adds version tags to his library name just to avoid the burden. Thirdly, see counter example below. > if the library interface have something sigset-related, you are still > in trouble, but it is unlikely and you would have to deal with the > trouble anyway. A counter example: libc has new functions to accomodate the sigset_t change. Primarily these are the functions that have a sigset_t somewhere in their argument list (sigprocmask, sigsuspend). Secondly, you also have to add new functions for those functions that have arguments that are indirectly changed (sigaction and such). Of course you also need to reimplement functions that are changed by a changing sigaction... and so on and so forth... You need to reimplement every function in every library that has changed directly or indirectly for this scheme to work. Now, are you going to do the reimplementation for every library on this planet just to prevent someone from recompiling his library and forgetting to reimplement those functions that got changed indirectly *without he even knowing that something has changed*? Are you the one that does the debugging to find out exactly what has gone wrong? What are the changes of finding the problem? -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37D8B507.CC33F50F>