Date: Tue, 12 Nov 2002 00:12:59 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Loren James Rittle <rittle@latour.rsch.comm.mot.com> Cc: current@freebsd.org, dfr@nlsystems.com Subject: Re: binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING) Message-ID: <3DD0B80B.2279721@mindspring.com> References: <3DCADE51.2090607@acm.org> <200211120553.gAC5rQFi093274@latour.rsch.comm.mot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Loren James Rittle wrote: > FYI, the libstdc++-v3 maintainers on the FSF side are only > guaranteeing forward ABI compatibility of any sort if libstdc++.so is > built with symbol versioning and symbol hiding. FWIW: symbol versioning is incredibly broken. It attempts to do in UNIX what interface versioning does in Windows, through the use of class factories accessed via IUnknown. The point of the exercise is to allow multiple simultaneous versions of an interface to be exported by a single library. The main reason this is bas is the same reason that Novell must, in their SDK's, support interface versions all the way back to NetWare 1.x: in order to hve the largest possible user base, a software vendor would have to be stupid to write to anything other than the lowest common denominator of interfaces: it's really stupid to limit your customers to running NetWare 4.2 or above, when there is still such a large installed base of 3.x, 4.0, and 4.1 versions of NetWare. The only thing you do when you do that is to disenfranchise postential customers for your product. Windows uses this approach because they do not have the concept of shared object versioning; VCRTL32.DLL is VCRTL32.DLL, no matter what, so a version change that permits old applications to continue working is a the same DLL, plus extensions (since there is no version in the file name,multiple versions can only exist simultaneously if they exist in the same file). It would be a very big mistake to actually utilize symbol name versioning on a UNIX system, and buy into this model, even if the idea was supported by the tools. That Linux has bought into the idea of using this is, frankly, Linux's problem, and they are going to regret it in the future as much, or more, than they regretted implementing shared library support in the SVR3.2 way, of linking libraries to fixed locations, and carving up chunks of the user virtual address space to implement them, back when they first supported shared libraries. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DD0B80B.2279721>