Re: binaries compiled on slink don't run anywhere else
Date: Sun, 15 Nov 1998 06:56:42 +0900 (JST)
Resent-from: debian-devel@lists.debian.org
From: Fumitoshi UKAI <ukai@debian.or.jp>
Resent-sender: debian-devel-request@lists.debian.org
Sender: Fumitoshi UKAI <ukai@jp.hpl.hp.com>
Resent-cc: recipient list not shown: ;
Cc: debian-devel@lists.debian.org
Precedence: list
X-Envelope-Sender: ukai@jp.hpl.hp.com
X-Dispatcher: imput version 980114
X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/19333
X-Loop: debian-devel@lists.debian.org
Content-Type: Text/Plain; charset=us-ascii
Content-Length: 2037
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
/usr/lib/gcc-lib/i486-linux/egcs-*/libgcc.a,
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 2.7.2.3, not with egcs
or
- linked with libgcc.a of egcs, that is, add -lgcc when linking *.so.
It doesn't help....
In GCC linkage against libc occurs before linkage to libgcc,
thus if linker finds reference resolution in the libc, it will not
link the code from libgcc.a
The only possible solution i can think about:
- create static library which contains __register_frame_info
(can it be taken from libc.a?) and name it lib_register_frame_info.a
- modify egcs spec file to force linkage library sequence like
-l_register_frame_info -lc -lgcc
- create shared library which contains __register_frame_info
in order to have the ability to transfer precompiled binaries from
slink to hamm/RH/whatever via LD_LIBRARY_PRELOAD
I don't think recompilation of zillions slink binaries is necessary...
regards
OK
Reply to: