* Re: the setrlimit changes in glibc 2.1.3 [not found] <200001122329.PAA02745@localhost.cygnus.com> @ 2000-01-12 15:41 ` Cristian Gafton 2000-01-12 20:41 ` H . J . Lu 0 siblings, 1 reply; 26+ messages in thread From: Cristian Gafton @ 2000-01-12 15:41 UTC (permalink / raw) To: egcs; +Cc: libc-hacker On Wed, 12 Jan 2000, Geoff Keating wrote: > So how did the shared lib get a reference to an unversioned setrlimit? > Was it linked with glibc 2.0? In glibc 2.1.2 the setrlimit was not versioned. For unversioned references the linker assumes GLIBC_2.0. Which in this case is not correct. > I suspect it was not linked with any libc at all, which would be the > problem. It was linked against libc (glibc 2.1.2). The test case is attached. Install glibc 2.1.2 (before the setrlimit changes), do a "make libfoo.so", then upgrade to the current glibc and in the same directory do a "make test". The link will fail. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "How could this be a problem in a country where we have Intel and Microsoft?" --Al Gore on Y2K ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-12 15:41 ` the setrlimit changes in glibc 2.1.3 Cristian Gafton @ 2000-01-12 20:41 ` H . J . Lu 2000-01-12 22:21 ` Thorsten Kukuk [not found] ` <200001131720.JAA20544@localhost.cygnus.com> 0 siblings, 2 replies; 26+ messages in thread From: H . J . Lu @ 2000-01-12 20:41 UTC (permalink / raw) To: Cristian Gafton; +Cc: libc-hacker On Wed, Jan 12, 2000 at 06:41:30PM -0500, Cristian Gafton wrote: > > Install glibc 2.1.2 (before the setrlimit changes), do a "make libfoo.so", > then upgrade to the current glibc and in the same directory do a "make > test". The link will fail. > Thanks. It is what I need. I will try to fix the linker. H.J. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 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 [not found] ` <200001131720.JAA20544@localhost.cygnus.com> 1 sibling, 2 replies; 26+ messages in thread From: Thorsten Kukuk @ 2000-01-12 22:21 UTC (permalink / raw) To: H . J . Lu; +Cc: libc-hacker On Wed, Jan 12, H . J . Lu wrote: > On Wed, Jan 12, 2000 at 06:41:30PM -0500, Cristian Gafton wrote: > > > > Install glibc 2.1.2 (before the setrlimit changes), do a "make libfoo.so", > > then upgrade to the current glibc and in the same directory do a "make > > test". The link will fail. > > > > Thanks. It is what I need. I will try to fix the linker. Just curious: I have reported this problem when we have introduced symbol versioning, and everybody here explained me this is the expected behaviour because library and main program should never call 2 different versions of the same function. Now it is a bug ? Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-12 22:21 ` Thorsten Kukuk @ 2000-01-13 6:33 ` Mark Kettenis 2000-01-13 9:26 ` H . J . Lu 1 sibling, 0 replies; 26+ messages in thread From: Mark Kettenis @ 2000-01-13 6:33 UTC (permalink / raw) To: kukuk; +Cc: hjl, libc-hacker Date: Thu, 13 Jan 2000 07:21:06 +0100 From: Thorsten Kukuk <kukuk@suse.de> Just curious: I have reported this problem when we have introduced symbol versioning, and everybody here explained me this is the expected behaviour because library and main program should never call 2 different versions of the same function. Now it is a bug ? No, it's not a bug. It was designed this way. As soon as we introduce a new version for a symbol, the old one will become hidden and the (static) linker will refuse to use it. Mark ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-12 22:21 ` Thorsten Kukuk 2000-01-13 6:33 ` Mark Kettenis @ 2000-01-13 9:26 ` H . J . Lu 1 sibling, 0 replies; 26+ messages in thread From: H . J . Lu @ 2000-01-13 9:26 UTC (permalink / raw) To: Thorsten Kukuk; +Cc: libc-hacker On Thu, Jan 13, 2000 at 07:21:06AM +0100, Thorsten Kukuk wrote: > On Wed, Jan 12, H . J . Lu wrote: > > > On Wed, Jan 12, 2000 at 06:41:30PM -0500, Cristian Gafton wrote: > > > > > > Install glibc 2.1.2 (before the setrlimit changes), do a "make libfoo.so", > > > then upgrade to the current glibc and in the same directory do a "make > > > test". The link will fail. > > > > > > > Thanks. It is what I need. I will try to fix the linker. > > Just curious: I have reported this problem when we have introduced > symbol versioning, and everybody here explained me this is the expected > behaviour because library and main program should never call 2 > different versions of the same function. Now it is a bug ? I was on vacation for a few weeks. I just came back. Besides, a testcase makes a big difference. H.J. ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <200001131720.JAA20544@localhost.cygnus.com>]
* A patch for binutils (Re: the setrlimit changes in glibc 2.1.3) [not found] ` <200001131720.JAA20544@localhost.cygnus.com> @ 2000-01-13 11:23 ` H . J . Lu 2000-01-13 12:21 ` Ian Lance Taylor 0 siblings, 1 reply; 26+ messages in thread From: H . J . Lu @ 2000-01-13 11:23 UTC (permalink / raw) To: Geoff Keating; +Cc: Ian Lance Taylor, gafton, GNU C Library > > > > > > Install glibc 2.1.2 (before the setrlimit changes), do a "make libfoo.so", > > > then upgrade to the current glibc and in the same directory do a "make > > > test". The link will fail. > > > > > > > Thanks. It is what I need. I will try to fix the linker. > > I happen to have this testcase handy. It may be easier to deal with > (it could actually be turned into an expect test for the linker). > > Just do 'make'. It should build properly, but it doesn't. > Thanks. Here is a patch for binutils 2.9.5.0.22. Ian, what do you think? H.J. ---- Thu Jan 13 11:03:29 2000 H.J. Lu <hjl@gnu.org> * elflink.h (elf_link_add_object_symbols): Bound the external references to the default version to the hidden version. Index: elflink.h =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v retrieving revision 1.14 diff -u -p -r1.14 elflink.h --- elflink.h 1999/11/01 22:47:51 1.14 +++ elflink.h 2000/01/13 19:18:31 @@ -1463,7 +1463,12 @@ elf_link_add_object_symbols (abfd, info) version, we create an indirect symbol from the default name to the fully decorated name. This will cause external references which do not specify a version to be - bound to this version of the symbol. */ + bound to this version of the symbol. + + If this symbol is hidden, we create an indirect symbol + from the default version the hidden one. This will cause + external references to the default version to be bound to + this symbol. */ if (definition) { char *p; @@ -1738,6 +1743,117 @@ elf_link_add_object_symbols (abfd, info) & ELF_LINK_HASH_REF_REGULAR) != 0) dynsym = true; } + } + } + } + } + else if (p != NULL) + { + char *defaultversion; + struct elf_link_hash_entry *hi; + boolean override; + + defaultversion = bfd_hash_allocate (&info->hash->table, + strlen (name) + 2); + if (defaultversion == NULL) + goto error_return; + strncpy (defaultversion, name, p - name + 1); + defaultversion[p - name + 1] = ELF_VER_CHR; + strcpy (&defaultversion[p - name + 2], p + 1); + + /* We are going to create a new symbol. Merge it + with any existing symbol with this name. For the + purposes of the merge, act as though we were + defining the symbol we just defined, although we + actually going to define an indirect symbol. */ + type_change_ok = false; + size_change_ok = false; + if (! elf_merge_symbol (abfd, info, defaultversion, &sym, &sec, + &value, &hi, &override, + &type_change_ok, &size_change_ok)) + goto error_return; + + if (override + || ! (_bfd_generic_link_add_one_symbol + (info, abfd, defaultversion, BSF_INDIRECT, + bfd_ind_section_ptr, (bfd_vma) 0, name, false, + collect, (struct bfd_link_hash_entry **) &hi))) + goto error_return; + + /* If there is a duplicate definition somewhere, + then HI may not point to an indirect symbol. We + will have reported an error to the user in that + case. */ + + if (hi->root.type == bfd_link_hash_indirect) + { + struct elf_link_hash_entry *ht; + + /* If the symbol became indirect, then we assume + that we have not seen a definition before. */ + BFD_ASSERT ((hi->elf_link_hash_flags + & (ELF_LINK_HASH_DEF_DYNAMIC + | ELF_LINK_HASH_DEF_REGULAR)) + == 0); + + ht = (struct elf_link_hash_entry *) hi->root.u.i.link; + + /* Copy down any references that we may have + already seen to the symbol which just became + indirect. */ + ht->elf_link_hash_flags |= + (hi->elf_link_hash_flags + & (ELF_LINK_HASH_REF_DYNAMIC + | ELF_LINK_HASH_REF_REGULAR + | ELF_LINK_HASH_REF_REGULAR_NONWEAK + | ELF_LINK_NON_GOT_REF)); + + /* Copy over the global and procedure linkage table + offset entries. These may have been already set + up by a check_relocs routine. */ + if (ht->got.offset == (bfd_vma) -1) + { + ht->got.offset = hi->got.offset; + hi->got.offset = (bfd_vma) -1; + } + BFD_ASSERT (hi->got.offset == (bfd_vma) -1); + + if (ht->plt.offset == (bfd_vma) -1) + { + ht->plt.offset = hi->plt.offset; + hi->plt.offset = (bfd_vma) -1; + } + BFD_ASSERT (hi->plt.offset == (bfd_vma) -1); + + if (ht->dynindx == -1) + { + ht->dynindx = hi->dynindx; + ht->dynstr_index = hi->dynstr_index; + hi->dynindx = -1; + hi->dynstr_index = 0; + } + BFD_ASSERT (hi->dynindx == -1); + + /* FIXME: There may be other information to copy + over for particular targets. */ + + /* See if the new flags lead us to realize that + the symbol must be dynamic. */ + if (! dynsym) + { + if (! dynamic) + { + if (info->shared + || ((hi->elf_link_hash_flags + & ELF_LINK_HASH_REF_DYNAMIC) + != 0)) + dynsym = true; + } + else + { + if ((hi->elf_link_hash_flags + & ELF_LINK_HASH_REF_REGULAR) != 0) + dynsym = true; } } } ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A patch for binutils (Re: the setrlimit changes in glibc 2.1.3) 2000-01-13 11:23 ` A patch for binutils (Re: the setrlimit changes in glibc 2.1.3) H . J . Lu @ 2000-01-13 12:21 ` Ian Lance Taylor 2000-01-13 12:47 ` H . J . Lu 0 siblings, 1 reply; 26+ messages in thread From: Ian Lance Taylor @ 2000-01-13 12:21 UTC (permalink / raw) To: hjl; +Cc: geoffk, gafton, libc-hacker Date: Thu, 13 Jan 2000 11:23:31 -0800 From: "H . J . Lu" <hjl@lucon.org> Thanks. Here is a patch for binutils 2.9.5.0.22. Ian, what do you think? Thu Jan 13 11:03:29 2000 H.J. Lu <hjl@gnu.org> * elflink.h (elf_link_add_object_symbols): Bound the external references to the default version to the hidden version. There is something odd about this case. libtest.so has an external reference to symbol foo in version FOO_1.0. Why are we looking up foo@@FOO_1.0? Why aren't we looking up foo@FOO_1.0? If I understand your patch, the latter is defined while the former is not. That also matches my intuition. We use the double @ to indicate the default version of a symbol. But that is only applicable to a definition. It does not make sense to refer to the default version of a symbol and to simultaneously specify a specific version. When we do use the double @, we also set up a reference from the unqualified symbol name, and from the symbol name with a single @. So I suspect that your patch, which sets up an indirection from foo@@FOO_1.0 to foo@FOO_1.0, is fixing the wrong thing. We should be asking why there would ever be a reference to foo@@FOO_1.0. Perhaps the fix is as simple as changing the code to not add a second ELF_VER_CHR if sym.st_shndx is SHN_UNDEF. Ian ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A patch for binutils (Re: the setrlimit changes in glibc 2.1.3) 2000-01-13 12:21 ` Ian Lance Taylor @ 2000-01-13 12:47 ` H . J . Lu 2000-01-13 12:55 ` H . J . Lu 2000-01-13 13:08 ` Ian Lance Taylor 0 siblings, 2 replies; 26+ messages in thread From: H . J . Lu @ 2000-01-13 12:47 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: geoffk, gafton, libc-hacker On Thu, Jan 13, 2000 at 03:21:29PM -0500, Ian Lance Taylor wrote: > Date: Thu, 13 Jan 2000 11:23:31 -0800 > From: "H . J . Lu" <hjl@lucon.org> > > Thanks. Here is a patch for binutils 2.9.5.0.22. Ian, what do you > think? > > Thu Jan 13 11:03:29 2000 H.J. Lu <hjl@gnu.org> > > * elflink.h (elf_link_add_object_symbols): Bound the external > references to the default version to the hidden version. > > There is something odd about this case. libtest.so has an external > reference to symbol foo in version FOO_1.0. Why are we looking up > foo@@FOO_1.0? Why aren't we looking up foo@FOO_1.0? If I understand It is because libtest.so is linked against the older libfoo.so, libfoo.so.1.0, where the FOO_1.0 of foo is the default. You got the reference to foo@@FOO_1.0. The new libfoo.so, libfoo.so.1.1, has the FOO_1.1 of foo as default and foo@FOO_1.0 is hidden. > your patch, the latter is defined while the former is not. That also > matches my intuition. > > We use the double @ to indicate the default version of a symbol. But > that is only applicable to a definition. It does not make sense to > refer to the default version of a symbol and to simultaneously specify > a specific version. When we do use the double @, we also set up a > reference from the unqualified symbol name, and from the symbol name > with a single @. Please remember a specific version may change from default to hidden. However, foo@FOO_1.0 will always be 100 binary compatible with foo@@FOO_1.0. > > So I suspect that your patch, which sets up an indirection from > foo@@FOO_1.0 to foo@FOO_1.0, is fixing the wrong thing. We should be > asking why there would ever be a reference to foo@@FOO_1.0. > > Perhaps the fix is as simple as changing the code to not add a second > ELF_VER_CHR if sym.st_shndx is SHN_UNDEF. > You are right. Here is the new patch. Please ignore my previous one. Thanks. H.J. -- Index: elflink.h =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v retrieving revision 1.14 diff -u -p -r1.14 elflink.h --- elflink.h 1999/11/01 22:47:51 1.14 +++ elflink.h 2000/01/13 20:45:07 @@ -1293,7 +1442,13 @@ elf_link_add_object_symbols (abfd, info) strcpy (newname, name); p = newname + namelen; *p++ = ELF_VER_CHR; - if ((iver.vs_vers & VERSYM_HIDDEN) == 0) + /* For the undefined versioned symbol, we always + reference the hidden version. The default version + will resolve the reference to the hidden one. It + solves the problem where a version changes from + default to higgen. */ + if ((iver.vs_vers & VERSYM_HIDDEN) == 0 + && sym.st_shndx != SHN_UNDEF) *p++ = ELF_VER_CHR; strcpy (p, verstr); ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A patch for binutils (Re: the setrlimit changes in glibc 2.1.3) 2000-01-13 12:47 ` H . J . Lu @ 2000-01-13 12:55 ` H . J . Lu 2000-01-13 13:08 ` Ian Lance Taylor 1 sibling, 0 replies; 26+ messages in thread From: H . J . Lu @ 2000-01-13 12:55 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: geoffk, gafton, libc-hacker On Thu, Jan 13, 2000 at 12:46:58PM -0800, H . J . Lu wrote: > > Perhaps the fix is as simple as changing the code to not add a second > > ELF_VER_CHR if sym.st_shndx is SHN_UNDEF. > > > > You are right. Here is the new patch. Please ignore my previous one. > Ooops. There is a typo in comment. Here is the fixed one. H.J. Index: elflink.h =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v retrieving revision 1.14 retrieving revision 1.18 diff -u -p -r1.14 -r1.18 --- elflink.h 1999/11/01 22:47:51 1.14 +++ elflink.h 2000/01/13 20:52:34 1.18 @@ -1293,7 +1442,13 @@ elf_link_add_object_symbols (abfd, info) strcpy (newname, name); p = newname + namelen; *p++ = ELF_VER_CHR; - if ((iver.vs_vers & VERSYM_HIDDEN) == 0) + /* For the undefined versioned symbol, we always + reference the hidden version. The default version + will resolve the reference to the hidden one. It + solves the problem where a version changes from + default to hidden. */ + if ((iver.vs_vers & VERSYM_HIDDEN) == 0 + && sym.st_shndx != SHN_UNDEF) *p++ = ELF_VER_CHR; strcpy (p, verstr); ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: A patch for binutils (Re: the setrlimit changes in glibc 2.1.3) 2000-01-13 12:47 ` H . J . Lu 2000-01-13 12:55 ` H . J . Lu @ 2000-01-13 13:08 ` Ian Lance Taylor 1 sibling, 0 replies; 26+ messages in thread From: Ian Lance Taylor @ 2000-01-13 13:08 UTC (permalink / raw) To: hjl; +Cc: geoffk, gafton, libc-hacker Date: Thu, 13 Jan 2000 12:46:58 -0800 From: "H . J . Lu" <hjl@lucon.org> On Thu, Jan 13, 2000 at 03:21:29PM -0500, Ian Lance Taylor wrote: > Date: Thu, 13 Jan 2000 11:23:31 -0800 > From: "H . J . Lu" <hjl@lucon.org> > > Thanks. Here is a patch for binutils 2.9.5.0.22. Ian, what do you > think? > > Thu Jan 13 11:03:29 2000 H.J. Lu <hjl@gnu.org> > > * elflink.h (elf_link_add_object_symbols): Bound the external > references to the default version to the hidden version. > > There is something odd about this case. libtest.so has an external > reference to symbol foo in version FOO_1.0. Why are we looking up > foo@@FOO_1.0? Why aren't we looking up foo@FOO_1.0? If I understand It is because libtest.so is linked against the older libfoo.so, libfoo.so.1.0, where the FOO_1.0 of foo is the default. You got the reference to foo@@FOO_1.0. The new libfoo.so, libfoo.so.1.1, has the FOO_1.1 of foo as default and foo@FOO_1.0 is hidden. I think you probably understood my point. Just in case, though, I'll expand further. The @ characters do not appear in the dynamic symbol table. All that is in the file is the symbol name, the associated version name, and a flag indicating whether this is a hidden version or not. The linker introduces the @ characters as, essentially, a trick to combine the version name into the symbol name for the linker hash table. The linker uses a double @ for the default version. Now that I look at the code, I'm not sure why it does that (I didn't write this code). I mean, I see why the linker needs to know whether the symbol is the default version, but I don't see why it needs to be recorded in the symbol name itself. That seems like it's trying to overload the symbol name unnecessarily. I know that we permit a source file to use a double @ to indicate the default version, but that's just a hack to ease life for library maintainers. I'm not sure why it should slip into the linker hash table. When the linker create a symbol with a double @, it also introduces an indirection from the symbol of the same name name but with a single @. Anyhow, this all means that the shared library has no reference to the literal string "foo@@FOO_1.0". What it has is a reference to symbol foo, version FOO_1.0, and the version is not hidden. So I was asking why we were trying to look up foo@@FOO_1.0. What we should have been looking up was symbol foo, version FOO_1.0. In the hash table that is represented by foo@FOO_1.0 with a single @. > We use the double @ to indicate the default version of a symbol. But > that is only applicable to a definition. It does not make sense to > refer to the default version of a symbol and to simultaneously specify > a specific version. When we do use the double @, we also set up a > reference from the unqualified symbol name, and from the symbol name > with a single @. Please remember a specific version may change from default to hidden. However, foo@FOO_1.0 will always be 100 binary compatible with foo@@FOO_1.0. In fact, I believe the two names always name precisely the same symbol. It's not a case of compatibility. foo@FOO_1.0 and foo@@FOO_1.0 are identical. > So I suspect that your patch, which sets up an indirection from > foo@@FOO_1.0 to foo@FOO_1.0, is fixing the wrong thing. We should be > asking why there would ever be a reference to foo@@FOO_1.0. > > Perhaps the fix is as simple as changing the code to not add a second > ELF_VER_CHR if sym.st_shndx is SHN_UNDEF. You are right. Here is the new patch. Please ignore my previous one. Thanks for the patch. Ian ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <200001122306.PAA02712@localhost.cygnus.com>]
* Re: the setrlimit changes in glibc 2.1.3 [not found] <200001122306.PAA02712@localhost.cygnus.com> @ 2000-01-12 15:12 ` Cristian Gafton 2000-01-13 4:32 ` Andreas Schwab 0 siblings, 1 reply; 26+ messages in thread From: Cristian Gafton @ 2000-01-12 15:12 UTC (permalink / raw) To: egcs; +Cc: libc-hacker On Wed, 12 Jan 2000, Geoff Keating wrote: > If you run 'nm libc.so.6 | grep setrlimit', do you get > > 000b18b4 T setrlimit@@GLIBC_2.1.3 > 000b1b74 T setrlimit@GLIBC_2.0 > > (of course, your hex numbers will vary)? The problem is that the linker complains about a missing setrlimit@@GLIBC_2.0 (note the double @@), which means that the shared lib in question has a reference to an unversioned setrlimit. But in the glibc 2.1.3 we only have versioned information. The linker then expects to have the GLIBC_2.0 as the default version in the library, but we're out of luck again, because the default one is GLIBC_2.1.3 Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "How could this be a problem in a country where we have Intel and Microsoft?" --Al Gore on Y2K ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-12 15:12 ` the setrlimit changes in glibc 2.1.3 Cristian Gafton @ 2000-01-13 4:32 ` Andreas Schwab 2000-01-13 5:38 ` Cristian Gafton 0 siblings, 1 reply; 26+ messages in thread From: Andreas Schwab @ 2000-01-13 4:32 UTC (permalink / raw) To: Cristian Gafton; +Cc: libc-hacker [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 862 bytes --] Cristian Gafton <gafton@redhat.com> writes: |> On Wed, 12 Jan 2000, Geoff Keating wrote: |> |> > If you run 'nm libc.so.6 | grep setrlimit', do you get |> > |> > 000b18b4 T setrlimit@@GLIBC_2.1.3 |> > 000b1b74 T setrlimit@GLIBC_2.0 |> > |> > (of course, your hex numbers will vary)? |> |> The problem is that the linker complains about a missing |> setrlimit@@GLIBC_2.0 (note the double @@), which means that the shared lib |> in question has a reference to an unversioned setrlimit. Then you must rebuild the shared lib in question. Binary compatibility is only about *runtime* compatibility, but not *linktime* compatibility. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." schwab@suse.de SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-13 4:32 ` Andreas Schwab @ 2000-01-13 5:38 ` Cristian Gafton 2000-01-13 6:18 ` Mark Kettenis 0 siblings, 1 reply; 26+ messages in thread From: Cristian Gafton @ 2000-01-13 5:38 UTC (permalink / raw) To: libc-hacker On Thu, 13 Jan 2000, Andreas Schwab wrote: > Then you must rebuild the shared lib in question. Binary compatibility is > only about *runtime* compatibility, but not *linktime* compatibility. No way. I don't see why I should do that. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-13 5:38 ` Cristian Gafton @ 2000-01-13 6:18 ` Mark Kettenis 2000-01-13 6:35 ` Cristian Gafton 0 siblings, 1 reply; 26+ messages in thread From: Mark Kettenis @ 2000-01-13 6:18 UTC (permalink / raw) To: gafton; +Cc: libc-hacker Date: Thu, 13 Jan 2000 08:38:32 -0500 (EST) From: Cristian Gafton <gafton@redhat.com> On Thu, 13 Jan 2000, Andreas Schwab wrote: > Then you must rebuild the shared lib in question. Binary compatibility is > only about *runtime* compatibility, but not *linktime* compatibility. No way. I don't see why I should do that. Because mixing modules that use interfaces that are binary incompatible is dangerous. In the case of setrlimit, the rlim_t type changed. If both the shared library and an application that links with that library use rlim_t in their communication, bad things may happen if the library is using the old type and the application is using the new type. By the way, you should not simply rebuild the shared lib, but also check if the interfaces it provides didn't change because of the changes to the interface in libc. If the interfaces did change, you must bump the lib's soname or version the symbols in your library itself. Mark ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 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 0 siblings, 2 replies; 26+ messages in thread From: Cristian Gafton @ 2000-01-13 6:35 UTC (permalink / raw) To: libc-hacker On Thu, 13 Jan 2000, Mark Kettenis wrote: > No way. I don't see why I should do that. > > Because mixing modules that use interfaces that are binary > incompatible is dangerous. In the case of setrlimit, the rlim_t type > changed. If both the shared library and an application that links > with that library use rlim_t in their communication, bad things may > happen if the library is using the old type and the application is > using the new type. > > By the way, you should not simply rebuild the shared lib, but also > check if the interfaces it provides didn't change because of the > changes to the interface in libc. If the interfaces did change, you > must bump the lib's soname or version the symbols in your library > itself. All fine and dandy, now think big-time vendors and tell me how to tell them that all their dveelopment libraries they have put out are now useless. It is quite of a challenge to deal with the big folks as it is; if we pull a fast one like this on them it is going to become increasingly difficult. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-13 6:35 ` Cristian Gafton @ 2000-01-13 6:55 ` Jakub Jelinek 2000-01-13 7:02 ` Mark Kettenis 1 sibling, 0 replies; 26+ messages in thread From: Jakub Jelinek @ 2000-01-13 6:55 UTC (permalink / raw) To: Cristian Gafton; +Cc: libc-hacker On Thu, Jan 13, 2000 at 09:35:15AM -0500, Cristian Gafton wrote: > On Thu, 13 Jan 2000, Mark Kettenis wrote: > > > No way. I don't see why I should do that. > > > > Because mixing modules that use interfaces that are binary > > incompatible is dangerous. In the case of setrlimit, the rlim_t type > > changed. If both the shared library and an application that links > > with that library use rlim_t in their communication, bad things may > > happen if the library is using the old type and the application is > > using the new type. > > > > By the way, you should not simply rebuild the shared lib, but also > > check if the interfaces it provides didn't change because of the > > changes to the interface in libc. If the interfaces did change, you > > must bump the lib's soname or version the symbols in your library > > itself. > > All fine and dandy, now think big-time vendors and tell me how to tell > them that all their dveelopment libraries they have put out are now > useless. It is quite of a challenge to deal with the big folks as it is; > if we pull a fast one like this on them it is going to become increasingly > difficult. Actually, it would be probably better to keep the old definitions and signed rlim_t type in 2.1.3 and make the interface change in 2.1.90 only to avoid the trouble. 2.1.3 setrlimit/getrlimit should internally use the old setrlimit/getrlimit calls. People can use setrlimit64/getrlimit64 if they need to play with limits between 2G and 4G and 2.1.3 setrlimit64/getrlimit64 should internally use the new setrlimit/getrlimit calls if they are available. If people agree on this, I can post a patch. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj Linux version 2.3.39 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 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 1 sibling, 1 reply; 26+ messages in thread From: Mark Kettenis @ 2000-01-13 7:02 UTC (permalink / raw) To: gafton; +Cc: libc-hacker Date: Thu, 13 Jan 2000 09:35:15 -0500 (EST) From: Cristian Gafton <gafton@redhat.com> All fine and dandy, now think big-time vendors and tell me how to tell them that all their dveelopment libraries they have put out are now useless. It is quite of a challenge to deal with the big folks as it is; if we pull a fast one like this on them it is going to become increasingly difficult. The solution is very simple. Tell people not to upgrade their development environment to glibc 2.1.3. This doesn't prevent people from upgrading their runtime environment. It is not too difficult to set things up such that the compiler and linker keep on using the old libs and headers. This has the additional advantage that you'll be able to produce binaries that run on older systems. But you'll also get the important bug-fixes contained in glibc 2.1.3. Mark ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-13 7:02 ` Mark Kettenis @ 2000-01-13 11:40 ` Roland McGrath 2000-01-13 12:45 ` Joel Klecker ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Roland McGrath @ 2000-01-13 11:40 UTC (permalink / raw) To: Mark Kettenis; +Cc: gafton, libc-hacker So I think the real question here is, what warranted this kind of change in a "bug-fix" release? I think folks around here have gotten pretty unclear on the concept of maintenance releases, and everybody's playing fast and loose. This is just not the way to operate. That's why we have a development branch, for pete's sake. Are we going to have to add another level of ".x" to the versions to get a truly conservative maintenance release branch? And, Mark: I'm afraid the realities of packaging systems (and of humans) make it hopelessly unwise to attempt to have "the right thing" for anyone be to upgrade their shared libraries differently than they upgrade their development environment. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 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 2 siblings, 0 replies; 26+ messages in thread From: Joel Klecker @ 2000-01-13 12:45 UTC (permalink / raw) To: libc-hacker At 14:40 -0500 2000-01-13, Roland McGrath wrote: >So I think the real question here is, what warranted this kind of change in >a "bug-fix" release? I think folks around here have gotten pretty unclear >on the concept of maintenance releases, and everybody's playing fast and >loose. >This is just not the way to operate. That's why we have a development >branch, for pete's sake. Are we going to have to add another level of ".x" >to the versions to get a truly conservative maintenance release branch? <AOL/> What the hell kinda release management is this? I don't trust any of the new rlimit or LFS stuff, so I'm avoiding it in Debian. Stable releases should never have anything but bug fixes, except perhaps allowing new features in things besides libc and the dynamic linker themselves, e.g. nscd or the libthread_db library. >And, Mark: I'm afraid the realities of packaging systems (and of humans) >make it hopelessly unwise to attempt to have "the right thing" for anyone >be to upgrade their shared libraries differently than they upgrade their >development environment. I have to agree with that. /usr/<cpu>-linux-gnulibc{2.1,2.1.1,2.1.2} is not my idea of a good thing. -- Joel Klecker (aka Espy) <URL: mailto:espy@debian.org > Debian Package Maintainer for the GNU C Library. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 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 2 siblings, 0 replies; 26+ messages in thread From: Thorsten Kukuk @ 2000-01-13 14:47 UTC (permalink / raw) To: Roland McGrath; +Cc: libc-hacker Hi, On Thu, Jan 13, Roland McGrath wrote: > So I think the real question here is, what warranted this kind of change in > a "bug-fix" release? I think folks around here have gotten pretty unclear > on the concept of maintenance releases, and everybody's playing fast and loose. > This is just not the way to operate. That's why we have a development > branch, for pete's sake. Are we going to have to add another level of ".x" > to the versions to get a truly conservative maintenance release branch? > > And, Mark: I'm afraid the realities of packaging systems (and of humans) > make it hopelessly unwise to attempt to have "the right thing" for anyone > be to upgrade their shared libraries differently than they upgrade their > development environment. I think the biggest problem is another: We need to much time for bug fix releases and the development branch. Why not make much ofter "bug-fix only" releases ? What is the problem if we would have glibc 2.1.14 ? It is stupid to know the bug was fixed 3 month ago, but is not released yet. The distributors start adding patches, and nobody really know the version which is used. And maybe it is necessary to maintain 3 branches: 1. the current "bug-fix" version 2. the next bigger release with new, smaller features like support for new kernel functions. 3. the version with big changes like locale support. We have the current situation, because small, new features go into the "bug-fix" branch, since nobody will wait 2 years until the next major release is made. glibc 2.2 was scheduled to come 6 month after glibc 2.1, but this was for a much longer time then 6 month. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 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 2 siblings, 1 reply; 26+ messages in thread From: Andreas Jaeger @ 2000-01-14 1:05 UTC (permalink / raw) To: libc-hacker >>>>> Roland McGrath writes: > So I think the real question here is, what warranted this kind of change in > a "bug-fix" release? I think folks around here have gotten pretty unclear > on the concept of maintenance releases, and everybody's playing fast and loose. After working some more time with the 32bit UID support, I'd like to apologize for proposing the 32bit UID support for glibc 2.1.x. I was outvetoed - but now I'm convinced that the patches shouldn't go into 2.1[1]. > This is just not the way to operate. That's why we have a development > branch, for pete's sake. Are we going to have to add another level of ".x" > to the versions to get a truly conservative maintenance release branch? > And, Mark: I'm afraid the realities of packaging systems (and of humans) > make it hopelessly unwise to attempt to have "the right thing" for anyone > be to upgrade their shared libraries differently than they upgrade their > development environment. Andreas Footnotes: [1] But they should go into 2.2 to get further testing. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-14 1:05 ` Andreas Jaeger @ 2000-01-14 13:20 ` Roland McGrath 0 siblings, 0 replies; 26+ messages in thread From: Roland McGrath @ 2000-01-14 13:20 UTC (permalink / raw) To: Andreas Jaeger; +Cc: libc-hacker > After working some more time with the 32bit UID support, I'd like to > apologize for proposing the 32bit UID support for glibc 2.1.x. I was > outvetoed - but now I'm convinced that the patches shouldn't go into > 2.1[1]. There is no need to apologize for the proposal. The important thing is that you were ready to listen to those of us who thought it was a bad idea. No harm done. One should never apologize for being wrong the first time, only if one insists on staying wrong. ^ permalink raw reply [flat|nested] 26+ messages in thread
* the setrlimit changes in glibc 2.1.3 @ 2000-01-12 12:30 Cristian Gafton 2000-01-12 14:58 ` Mark Kettenis 0 siblings, 1 reply; 26+ messages in thread From: Cristian Gafton @ 2000-01-12 12:30 UTC (permalink / raw) To: libc-hacker 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. 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. There are anumber of vendors that are hit by this problem, and I would like to ask the hackers from other vendors what do they think about this change. The options are: 1. revert the change and call it good for glibc 2.1. Life sucks. 2. build a custom object file (or static archive) that gets listed in /usr/lib/libc.so that will provide that dummy symbol version - will this work? 3. other options? In any case, if we leave it the way it is now, we will be screwing up people that have put out development environments linked against previous versions of glibc. And again we are at fault. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "How could this be a problem in a country where we have Intel and Microsoft?" --Al Gore on Y2K ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-12 12:30 Cristian Gafton @ 2000-01-12 14:58 ` Mark Kettenis 2000-01-12 15:44 ` Cristian Gafton 0 siblings, 1 reply; 26+ messages in thread From: Mark Kettenis @ 2000-01-12 14:58 UTC (permalink / raw) To: gafton; +Cc: libc-hacker 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-12 14:58 ` Mark Kettenis @ 2000-01-12 15:44 ` Cristian Gafton 2000-01-12 20:21 ` H . J . Lu 0 siblings, 1 reply; 26+ messages in thread From: Cristian Gafton @ 2000-01-12 15:44 UTC (permalink / raw) To: egcs; +Cc: libc-hacker On Wed, 12 Jan 2000, Mark Kettenis wrote: > * If you now link against your shared library you get a warning about > setrlimit@@GLIBC_2.0 undefined. It's an error. > 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. I _do_ get that. The problem is that setrlimit@GLIBC_2.0 is different than the setrlimit@@GLIBC_2.0, which is what the liker expects to find. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "How could this be a problem in a country where we have Intel and Microsoft?" --Al Gore on Y2K ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: the setrlimit changes in glibc 2.1.3 2000-01-12 15:44 ` Cristian Gafton @ 2000-01-12 20:21 ` H . J . Lu 0 siblings, 0 replies; 26+ messages in thread From: H . J . Lu @ 2000-01-12 20:21 UTC (permalink / raw) To: Cristian Gafton; +Cc: libc-hacker On Wed, Jan 12, 2000 at 06:44:33PM -0500, Cristian Gafton wrote: > On Wed, 12 Jan 2000, Mark Kettenis wrote: > > > * If you now link against your shared library you get a warning about > > setrlimit@@GLIBC_2.0 undefined. > > It's an error. > > > 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. > > I _do_ get that. The problem is that setrlimit@GLIBC_2.0 is different than > the setrlimit@@GLIBC_2.0, which is what the liker expects to find. Please send me a testcase. I will take a look. It sounds like a linker bug to me. H.J. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2000-01-14 13:20 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200001122329.PAA02745@localhost.cygnus.com> 2000-01-12 15:41 ` the setrlimit changes in glibc 2.1.3 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 [not found] ` <200001131720.JAA20544@localhost.cygnus.com> 2000-01-13 11:23 ` A patch for binutils (Re: the setrlimit changes in glibc 2.1.3) H . J . Lu 2000-01-13 12:21 ` Ian Lance Taylor 2000-01-13 12:47 ` H . J . Lu 2000-01-13 12:55 ` H . J . Lu 2000-01-13 13:08 ` Ian Lance Taylor [not found] <200001122306.PAA02712@localhost.cygnus.com> 2000-01-12 15:12 ` the setrlimit changes in glibc 2.1.3 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 2000-01-12 12:30 Cristian Gafton 2000-01-12 14:58 ` Mark Kettenis 2000-01-12 15:44 ` Cristian Gafton 2000-01-12 20:21 ` H . J . Lu
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).