Re: Problem with new ld.so.cache format on 64-bit machines

[David Huggins-Daines <dhd at linuxcare dot com>]

Andreas Jaeger <aj@suse.de> writes:

> How was the cache created?

[dhd@curacao]:~/src/glibc-build$ sudo elf/ldconfig -r /home/glibc-2.2-chroot/

I am also using some "non-standard" library directories, just to make
sure everything works.

> I just run a test on i686 and Alpha - and both work as expected.  Can
> you please double check that you're really using my patch - and only
> mine?

Yes.

It looks like this is the problem (cache.c:139):

       /* This is where the strings start.  */
       cache_data = (const char *) &cache->libs[cache->nlibs];
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^

If a new-style cache is detected then cache_data should be set to
cache_new, since the string offsets in the new cache refer to the
start of the new cache structure, not the end of the old one.

This fix works for me:

 	  if (!memcmp (cache_new->magic, CACHEMAGIC_NEW, sizeof CACHEMAGIC_NEW - 1)
 	      && !memcmp (cache_new->version, CACHE_VERSION,
 			  sizeof CACHE_VERSION - 1))
+	    cache_data = (const char *) cache_new;
 	    format = 1;
 	}
     }

Strange that it worked for you though...  I'm also not sure that it is
really compatible with the old cache format:

[dhd@curacao]:~/work/jumpstart-cd$ sudo /home/glibc-2.2-chroot/sbin/ldconfig -p
825126771 libs found in cache `/etc/ld.so.cache'
Segmentation fault

But that is a different problem ... I will see if I can track it down.

-- 
David Huggins-Daines, Senior GNU/Linux Consultant, Linuxcare, Inc.
613.562.1239 desk, 613.223.0225 mobile
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.