Re: Status update hppa - glibc 2.2.92 (Problems with __divdi3)
Carlos,
You don't have to resort to the full blown assembly version of
libgcc-compat.S for hppa. You could just use the original version
that was written in c...it won't be optimized but it will suffice...
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/Attic/libgcc-compat.c?rev=1.1.2.3&content-type=text/x-cvsweb-markup&cvsroot=glibc
Note that you will want the current version of divdi3.c which only
presents the symbols for runtime resolution and not exported for linking.
You can check this in a build by doing...
objdump --dynamic-sym ./libc.so.6 | grep __divdi3
and making sure that the versioning on __divdi3 is (GLIBC_2.0) and not
just GLIBC_2.0. The former will not export for linking while the latter
will. Also, you will, unfortunately, need to determine for hppa exactly
which symbols from libgcc, which are now hidden under gcc >= 3.1, need
to be provided by libgcc-compat for run-time resolution. The description
of this process by Jakub is...
------------------------------------------------------------------
Basically, you take the list of libgcc.a (formerly) exported symbols
and scan all binaries/libraries if they have undefined references to any
of these symbols (as libc.so exports those on ia32/sparc and a few
others only, they will not be exported on other arches from libc, thus
are resolved to some unintentionally exported symbol in some other library
which is going away after rebuild with 3.2).
Jakub
-------------------------------------------------------------------
Of the arches Jakub mentioned looking at, hppa was absent, so you
may very well need a libgcc-compat. If you don't make one and
install a gcc >= 3.1 built glibc 2.2.93 on your machine you may find
some binaries built under gcc < 3.1 breaking. In particular check for
things like sendmail. Sorry it not any easier...which is why we spent
so much time fussing with this on ppc.
Jack
Reply to: