Re: libc6 needs >= 2.0.7u (Closes: dpkg-shlibdeps is too strict
Dale Scheetz writes:
> On Mon, 7 Dec 1998, Gergely Madarasz wrote:
>
> > On Sun, 6 Dec 1998, Dale Scheetz wrote:
> >
> > > I was working on two assumptions, at least one of which was incorrect.
> > > Someone told me early on that __register_frame_info was supposed to be
> > > supplied static by the compiler. This, I am pretty sure, is incorrect. At
> > > least libgcc.a doesn't supply this symbol. My second assumption was that
> >
> > libgcc.a from egcs does.
>
> This agrees with my memory, and brings up several points with respect to
> what we are planning here.
>
> First: There is the compatibility question of having the two compilers
> generate different ineternals. As I understand it gcc doesn't do C++
> "correctly" and egcs does, so the incompatibility doesn't show itself at
> the moment.
>
> Second: It is my understanding that it is proper opperation for egcs to
> provide the code for such symbols as __register_frame_info (and the
> others) as a "static" inclusion of the code and not as a link reference
> statisfied at runtime.
>
> If this is correct, then it is just as big a mistake to supply the dynamic
> link for this code in libstdc++, as it was to supply it in libm. Once the
> library is "fixed" and egcs supplies the code instead of a reference we
> are going to have the same set of programs that will not run on other
> Linux systems that we arrived at with the mistaken introduction of the
> symbol into glibc. We will have to go through this all over again!
>
> Isn't it a better solution to see if egcs can be fixed now, and remove
> such references from the libstdc++ libraries? More to the point, if those
> routines are currently supplied in the library (libgcc.a) then there is
> every expectation that egcs already supplies them (if they aren't already
> supplied somewhere else first), and will produce "correct" code if the
> libstdc++ stops providing those routines, can't we move to that regimen
> now more easily than later?
libstdc++ needs to be linked with -lm. On the linker command line this
expands to .... -lm -lgcc -lc -lgcc. So if libm does not provide the
__register_frame_info, then libstdc++ doesn't find the shared symbol.
Please see my posting on debian-devel "Linking shared libs with -lc
considered harmful" (appended). I think this is a CRITICAL problem, if
we ever want to replace gcc with egcs. gcc now is fixed and appends
the -lc for shared libs. What packages should get this bug report?
----------------------
gcc-2.7 doesn't include -lc when linking shared libraries, egcs
does. If you don't add -lc on the command line:
gcc -shared -> ld -lgcc -lgcc
egcc -shared -> ld -lgcc -lc -lgcc
Adding -lc ...
gcc -shared -lc -> ld -lc -lgcc -lgcc
egcc -shared -lc -> ld -lc -lgcc -lc -lgcc
IMHO this is worse than linking without -lc, because libc is searched
before the internal libgcc. That's the cause of our
__register_frame_info problems. It was found in libc, not in libgcc.
What to do?
- Fix the gcc specs such that -lc is used when building a shared
library (should be done for slink, such that shared libs on slink
can be built without explicitely linking libc).
(done in gcc-2.7.2.3-6).
- As an interim solution, link shared libraries with -lgcc -lc
gcc -shared -lgcc -lc -> ld -lgcc -lc -lgcc -lgcc
egcc -shared -lgcc -lc -> ld -lgcc -lc -lgcc -lc -lgcc
(not needed with gcc-2.7.2.3-6)
- As a final solution, don't link shared libs with -lc.
All 'required' libs for the base system should checked before slink
is released.
- Check libtool if it adds -lc for linking of shared libs. If yes,
remove it and make libtool dependent on gcc (>= 2.7.2.3-6) | egcc
Could linitan detect if a shared lib is linked first with -lgcc -lc or
simply with -lc -lgcc ? That was easy with the buggy libm, so AFAIK
libguileX is wrongly linked with -lc.
Reply to: