public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gafton@redhat.com
Cc: libc-hacker@sourceware.cygnus.com
Subject: Re: the setrlimit changes in glibc 2.1.3
Date: Wed, 12 Jan 2000 14:58:00 -0000	[thread overview]
Message-ID: <200001122252.XAA00590@delius.kettenis.local> (raw)
In-Reply-To: <Pine.LNX.4.10.10001121523140.12491-100000@alien.devel.redhat.com>

   Date: Wed, 12 Jan 2000 15:30:25 -0500 (EST)
   From: Cristian Gafton <gafton@redhat.com>

   The current changes in setrlimit that were backported to glibc 2.1.3 are
   causing this library to become once again binary incompatible with the
   preivious releases. You you have any dynamic library linked against a
   previous version of glibc that is calling setrlimit, you'll not be able to
   use it after upgrading to glibc 2.1.3.

Of course we are no longer binary compatible.  We have fixed some bugs
:).  But seriously:

   At linking stage, the linker complains about an undefined
   setrlimit@@GLIBC_2.0 symbol - this is because previously the setrlimit was
   not a versioned symbol.

If this is really what is happening, that is:

 * You built a shared library, that references setrlimit, linked
   against glibc 2.1, 2.1.1 or 2.1.2.

 * You replaced glibc with version 2.1.3.

 * If you now link against your shared library you get a warning about
   setrlimit@@GLIBC_2.0 undefined.

Then either something went wrong during your built of glibc 2.1.3, or
there is a bug in the (static) linker.  To check what is really you
could do

   nm /lib/libc-2.1.3.so | grep setrlimit

This should output at least two lines looking like

   xxxxxxxx T setrlimit@@GLIBC_2.1.3
   xxxxxxxx T setrlimit@GLIBC_2.0

If this is not the case, something went wrong when buildig glibc
2.1.3.  Otherwise it is most likely a linker bug.

Mark

  reply	other threads:[~2000-01-12 14:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-12 12:30 Cristian Gafton
2000-01-12 14:58 ` Mark Kettenis [this message]
2000-01-12 15:44   ` Cristian Gafton
2000-01-12 20:21     ` H . J . Lu
     [not found] <200001122306.PAA02712@localhost.cygnus.com>
2000-01-12 15:12 ` Cristian Gafton
2000-01-13  4:32   ` Andreas Schwab
2000-01-13  5:38     ` Cristian Gafton
2000-01-13  6:18       ` Mark Kettenis
2000-01-13  6:35         ` Cristian Gafton
2000-01-13  6:55           ` Jakub Jelinek
2000-01-13  7:02           ` Mark Kettenis
2000-01-13 11:40             ` Roland McGrath
2000-01-13 12:45               ` Joel Klecker
2000-01-13 14:47               ` Thorsten Kukuk
2000-01-14  1:05               ` Andreas Jaeger
2000-01-14 13:20                 ` Roland McGrath
     [not found] <200001122329.PAA02745@localhost.cygnus.com>
2000-01-12 15:41 ` Cristian Gafton
2000-01-12 20:41   ` H . J . Lu
2000-01-12 22:21     ` Thorsten Kukuk
2000-01-13  6:33       ` Mark Kettenis
2000-01-13  9:26       ` H . J . Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200001122252.XAA00590@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=gafton@redhat.com \
    --cc=libc-hacker@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).