Bug#165358: workaround for __libc_fork and winex 2.0
On Mon, Nov 04, 2002 at 07:38:39AM -0500, Jeff Bailey wrote:
> On Mon, 2002-11-04 at 07:01, GOTO Masanori wrote:
>
> > Yes, we have to warn "for developer, you don't use such an internal
> > symbol", but from user point of view "I don't know such a export
> > issue, because I am a user". Sarge release documents only say some
> > commercial programs do not run after sarge, so we recommend to
> > upgrade such softwares.
>
> Then, is it possible to put a hack in the linker that prints an message
> to STDERR or something? Something really clear like "This package has
> had a work around applied to it to make it run. Please get a new
> version. It will break sometime in the future".
>
> I mean, obviously the wording should be such that the user doesn't
> panic.
At runtime? No, and I don't think it's a particularly good idea -
redirecting output would break... and the check to print the warning
would be in the fast path of the runtime linker.
> > In addition, the most important benefit is "we don't see this kind
> > of BTS" :-)
>
> *lol* True...
>
> I want to make sure we're not dragging crap around from version to
> version, and having to attempt to preserve this indefinetly. Daniel
> notes:
>
> > __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.
>
> But I think that part of the hiding of the interface is that upstream is
> free to change this interface at any time without notifying us. Let's
> say drepper changed it for 2.3.2. (Note that I'm just about to run to
> work, so I don't have time to look up what the actual interface is)
> Something subtle like changing the width of a parameter, or making it a
> pointer instead of passing a value. What we're proposing here is that
> we will track those changes and compensate for them. If we don't, some
> upload sometime will start causing segfaults, or creating processes with
> strange properties and do so subtly. We'll then spend time chasing down
> why "Upgrading to 2.x.y causes my JVM to segfault" when having it block
> at load time could have solved the problem.
The interface is simple: it's a strong alias to the exported waitpid()
function. Similarly for fork. It's there for libraries like
libpthread, which need to touch glibc internals in order to override
fork() etc. That's not likely to change.
> Perhaps the warning could also be changed to say "Symbol not found,
> perhaps upgrade your program?" or something like that, with an
> explanation of what the typical causes of that error message are?
Hmm...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: