[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binaries compiled on slink don't run anywhere else

From: "Marcelo E. Magallon" <mmagallo@efis.ucr.ac.cr>
Subject: binaries compiled on slink don't run anywhere else
Date: Sat, 14 Nov 1998 11:50:00 -0600

> Package: libc6
> Version: 2.0.7u-5
> Severity: critical
> As you are well aware of, binaries compiled on slink won't run on any other
> system (not hamm, not RH, not hand rolled unless it's some specific version
> of glibc). Now, it's obviously a big problem because that means I can't
> compile anything on my debian system because I *know* it won't run on the
> machine next door.
> Solving this is a bigger problem than it might seem at first glance: a *lot*
> of packages have been already compiled against 2.0.7u, that means upgrading
> to a libc that doesn't have this problem would break things awfully (A
> library can be preloaded to supply the missing __register_frame_info in the
> mean time). Essentially this means slink's gotta be delayed to let
> developers catch up, OR a massive NMU has to be performed.
> A possible solution is revert to 2.0.7t, that wouldn't break too many things
> according to libc6's changelog, but that leaves us with the
> all-my-system-is-broken problem.
> Ideas ASAP welcomed!

I'm not sure this is the case of this problems...

I think missing __register_frame_info problem was caused by egcs.
When egcs compiles binaries, it will produces __register_frame_info
and so on, so it should be linked with libgcc.a of egcs, which is
in case you build shared library.

However, libc6 (and maybe other shared libraries) may not be linked
with libgcc.a of egcs, so missing __register_frame_info happens.

If this is the case of the problem here, the solution, I think, is:
  - compile with gcc, not with egcs
  - linked with libgcc.a of egcs, that is, add -lgcc when linking *.so.


Fumitoshi UKAI / Debian JP Projects

Reply to: