This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
sysdeps/powerpc/libgcc-compat.c problem (glibc-2-2-branch)
- From: Peter Bergner <bergner at brule dot borg dot umn dot edu>
- To: drepper at sources dot redhat dot com, libc-alpha at sources dot redhat dot com
- Date: Wed, 19 Jun 2002 16:07:07 -0500
- Subject: sysdeps/powerpc/libgcc-compat.c problem (glibc-2-2-branch)
- Reply-to: bergner at vnet dot ibm dot com
Ulrich,
We have the following code snipits on the CVS mainline:
include/libc-symbols.h:
/* Handling on non-exported internal names. We have to do this only
for shared code. */
#ifdef SHARED
# define INTUSE(name) name##_internal
[snip]
#else
# define INTUSE(name) name
[snip]
#endif
sysdeps/powerpc/libgcc-compat.c:
extern int64_t __ashldi3 (int64_t, int32_t);
int64_t INTUSE (__ashldi3) (int64_t u, int32_t b)
{
return __ashldi3 (u, b);
}
symbol_version (INTUSE (__ashldi3), __ashldi3, GLIBC_2.0);
On the glibc-2-2-branch, you removed the use of the INTUSE macro
from sysdeps/powerpc/libgcc-compat.c which gives us:
extern int64_t __ashldi3 (int64_t, int32_t);
int64_t __ashldi3 (int64_t u, int32_t b)
{
return __ashldi3 (u, b);
}
symbol_version (__ashldi3, __ashldi3, GLIBC_2.0);
I'm assuming you didn't mean to create infinite recursion and want something
closer to what CVS mainline gets (after macro expansion):
extern int64_t __ashldi3 (int64_t, int32_t);
int64_t __ashldi3_internal (int64_t u, int32_t b)
{
return __ashldi3 (u, b);
}
symbol_version (__ashldi3_internal, __ashldi3, GLIBC_2.0);
Ditto for the other routines in that file.
Peter
--
Peter Bergner
Linux PPC64 & GLIBC Kernel Development
IBM Rochester, MN
bergner@vnet.ibm.com