[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: