Re: Binary incompatibility between RH6.1 and potato on Alpha
On Thu, 10 Feb 2000, David Huggins-Daines wrote:
> I'm sending this to the list (and to Chris who builds our glibc packages)
> instead of reporting it as a bug against libc6.1 because I am not really
> sure we are in the wrong here.
>
> Basically, the problem is that binaries compiled on potato cannot be run on
> Red Hat 6.1 for Alpha (though the opposite is not true, thankfully). It's
> the old __register_frame_info problem from glibc2.0 days come back to haunt
> us. :(
Argh!
> Could the cause of this be that our glibc is built with gcc 2.96 snapshots,
> whereas theirs is built with egcs 1.1.2? I say that they may be in the
> wrong, because the glibc2.1 FAQ indicates that glibc2.1 is suppposed to
> provide the exception handling symbols in order to prevent other libraries
> from providing them.
Yes. Our first libc6.1 packages were built with egcs 1.1.x, but most of
the latter ones have all been built with gcc 2.95 or one of the snapshots
(the last I uploaded was built with 2.95 with the complex patch to allow
glibc to compile on Alpha with proper complex support).
> Also, on i386, both Debian and Red Hat's glibc2.1 seem to be providing them,
> since the same program does show __register_frame_info@@GLIBC_2.0 and
> company in its 'nm' output (well, it's listed as 'U' on Red Hat, and 'w' on
> Debian, but that's not really important since it's a dependency either way).
Yes, i386 shouldn't have this problem since gcc 2.95 is used on both to
build the glibc packages (they never had the complex support problem we
did). I'd have to toss this one back into RH's court, though, since we're
really doing things "the right way". Problem is, I'd like to maintain
compatibility. Argh, what an ugly problem. Any suggestions? I mean, we
could, for now, recompile glibc with egcs 1.1.x and then recompile all
affected packages (pretty much all), but that's alot to do in such a short
amount of time.
Is it possible that we just bill this as "the next step" type of release
and wait for RH to catch up for a change?
C
Reply to: