Bug#165358: workaround for __libc_fork and winex 2.0
On Sun, Nov 03, 2002 at 09:13:33PM -0500, Jeff Bailey wrote:
> On Sun, 2002-11-03 at 20:24, Daniel Jacobowitz wrote:
>
> > I object to not adding the patch. Just like our other compatibility
> > patches, these binaries are a fact of life; we should prevent exposing
> > the symbols at _link_ time, but there's no benefit to us in hiding them
> > at runtime.
>
> The other compatibility patches are design to help programs that were
> following the rules and that broke. This patch is designed to help
> programs that were badly written. Will we be expected to maintain the
> internal structures when they change, too?
>
> In this particular case, we gain nothing by adding this patch (the
> various upstream authors recognise that they shouldn't have used that
> function and are patching their programs) - and simply postpone the fact
> that people have to replace these programs. Eventually the internal
> interface will change - and it will probably just quietly segfault or
> cause security problems instead of clearly saying that the program has
> problems.
>
> I think we should simply make sure that Sarge's release notes indicate
> that certain commercial programs (Java, WineX) had been incorrectly
> using the C library and may need to be upgraded to keep them running.
__libc_waitpid's hiding is not interface-related, it's
namespace-related. There are no changing interfaces involved, and it's
clear that we can safely continue to export it unless there's a major
change. __libc_fork similarly. If we make the symbol unavailable at
link time - there's plenty of examples of this in glibc - then bad
binaries can no longer be built on Sarge; then a release later we can
stop supporting them. I believe that the only fair thing for our users
is to allow a transition period. This is the first release which
enforced the namespace rules; it was not very clearly documented
before.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: