Re: glibc 2.3.1-12 ...
At Tue, 18 Feb 2003 15:43:37 +0100,
Sven Luther wrote:
> On Tue, Feb 18, 2003 at 10:47:50PM +0900, GOTO Masanori wrote:
> > At Tue, 18 Feb 2003 12:03:01 +0100,
> > Sven Luther wrote:
> > > Could you perhaps add a :
> > >
> > > Conflict: ocaml (<<3.06-7)
> > >
> > > This is not a problem with unstable, since i rebuilt the ocaml packages,
> > > but the version in testing was built with the older glibc, and will
> > > break with the newer glibc, if the new glibc enters testing before the
> > > ocaml packages do.
> > >
> > > It is not all that important though, so i don't know if it is worth it,
> > > especially since that means that ocaml stuff will hold up glibc if it is
> > > not yet ready to enter testing, but i guess other packages will present
> > > the same problem.
> >
> > Hmm, on my testing, ocaml 3.04-12 with libc6 2.3.1-12 runs well.
> > What is the problem?
>
> Well the symptoms are actually :
>
> $ ocamlopt str.cmxa stuff.ml
> /usr/lib/ocaml/libasmrun.a(str.o)(.text+0x1de): In function `is_printable':
> : undefined reference to `__ctype_b'
> collect2: ld returned 1 exit status
> Error during linking
__ctype_b issue was already fixed and patched with
glibc-2.3.1/debian/patches/glibc23-ctype-compat.dpatch.
In addition, my test on sarge does not break such problem.
air:/tmp# dpkg -s ocaml | grep Version
Version: 3.04-12
air:/tmp# dpkg -s libc6 | grep Version
Version: 2.3.1-12
air:/tmp# cat tmp/stuff.ml
air:/tmp# ocamlopt str.cmxa stuff.ml
air:/tmp# cat /etc/issue
Debian GNU/\s testing/unstable \n \l
air:/tmp# objdump -x ./a.out | grep __ctype
08058784 g O .bss 00000004 __ctype_b@@GLIBC_2.0
air:/tmp# ./a.out
I built "a.out" created by woody's ocamlopt, then move it to sid
machine, and a.out still works well.
Am I missing?
> where wtuff.ml is an empty file.
>
> I guess it has to do because libasmrun.a (which contains parts of the
> ocaml runtime needed to run nativecode executables) is linked statically
> when built, and references this symbol from the old libc.
>
> The easy solution is simply to rebuild the ocaml compiler for the new
> glibc, i don't think you can really do a lot about static linked
> executables, can you ?
We could do a lot, with much discussions, check debian-glibc
list archives.
> Anyway, as said, it is not really all that problematic, provided the new
> ocaml make it into testing quickly, but a conflict would be nice for
> later versions of glibc, so that the woody->sarge migration does not
> cause problems.
>
> > > Anyway, if you don't do it yet, maybe it could be done at a later time,
> > > when both the new ocaml and the new glibc is in testing, so that people
> > > upgrading from woody don't have this problems ?
> >
> > glibc should provide back compatibility, but if something is broken,
> > at least new ocaml depends on new libc6, so we don't get any problem,
> > I think.
>
> Well, like said, i don't think you can provide back compatibility to
> static binaries, but i may be wrong. I think it is another instance of
> the hidden symbols or something such, but since this only appears when
> building new nativecode executables, it is not really as big a problem
> as with gcc-3.2, and the faster the new ocaml packages make it in
> testing, the less a problem it will be. I will widely publisize this
> fact on the ocaml lists, to make sure it is not a problem. Anyway, 3.04
> is old and most people use the woody backported 3.06 packages, and there
> is no way we can do anything about that.
>
> The only thing i wish is that people upgrading from stable woody to
> freshly released sarge will have their ocaml package upgraded at the
> same time their glibc is.
Yes, it's hidden symbols issue. __ctype_b symbol are crashed with the
old 2.2.x dynamic linking code in static binaries, which are now
exported with our glibc23-ctype-compat.dpatch.
Regards,
-- gotom
Reply to: