More issues with the lsparc 64 bit stuff vs. other 64 bit archs in ldconfig/ld.so
Well, I didn't even get to file a bug report and patch to ld.so before
the new package was uploaded, and I spent several hours today tracking
the problem, too. I guess I should get into the habit of tracking
incoming for this sort of thing. It sure would be nice if (a) the BTS
were faster, and (b) people would copy bug reports to the appropriate
mailing lists so as to avoid duplication of effort.
Anyway, regarding the LIB_ELF64 flag:
a) It's only relevant to architectures that have a single dynamic
loader that handles both 32 and 64 bit libraries (currently Sparc,
maybe also PowerPC in the future, but definitely not Alpha or
IA-64, ever)
b) It's not handled at all by the current ld-linux.so code. In fact,
ld-linux.so has LIB_ELF and LIB_ELF_LIBC6 as magic numbers in its
cache searching code (line 203,
glibc-2.1.3/sysdeps/generic/dl-cache.c in the glibc source tree):
if ((flags == 1 || flags == 3)
&& cache->libs[middle].value < cachesize - sizeof *cache)
c) We have a patch for our libc on Sparc that has its own version of
ldconfig, and this version of ldconfig uses a *different* flag to
indicate ELF64 libraries (debian/patches/ldconfig.dpatch in the
glibc source tree):
+#define FLAG_ANY -1
+#define FLAG_TYPE_MASK 0x00ff
+#define FLAG_LIBC4 0x0000
+#define FLAG_ELF 0x0001
+#define FLAG_ELF_LIBC5 0x0002
+#define FLAG_ELF_LIBC6 0x0003
+#define FLAG_REQUIRED_MASK 0xff00
+#define FLAG_SPARC_LIB64 0x0100
^^^^^^
It would be nice to have some consistency between the various things
that read and write the ld.so.cache (and no more magic numbers). The
way that ldconfig.dpatch does things looks to be more correct to me,
but it also constitutes a backwards-incompatible change to the cache
format and so not only do we have to coordinate a fix to glibc but
also the upgrade needs to be handled carefully.
The Sparc people should probably sit down and figure out a good way to
do all this that won't break other archs.
Cheers
Reply to: