Re: Aarch64 test results and questions

[Florian Weimer <fweimer at redhat dot com>]

* Steve Ellcey:

> On Fri, 2019-07-26 at 18:52 +0200, Florian Weimer wrote:
>
>> > tst-ldconfig-bad-aux-cache also does not seem to have any known
>> > PR's. 
>> > I get the following in the .out file:
>> > 
>> > 	tst-ldconfig-bad-aux-cache.c:84: numeric comparison failure
>> > 	   left: 256 (0x100); from: status
>> > 	  right: 0 (0x0); from: 0
>> > 	error: support-xstat.c:29: stat64 ("/var/cache/ldconfig/aux-
>> > cache"): No such file or directory
>> > 	error: 2 test failures
>> > 	running post-clean rsync
>> 
>> What's the path that ldconfig is actually creating on this target?
>
> I built a toolchain (binutils, gcc, glibc) that are all in
> /extra/sellcey/test-glibc/install.
>
>
> % /extra/sellcey/test-glibc/install/sbin/ldconfig -p
> /extra/sellcey/test-glibc/install/sbin/ldconfig: Can't open cache file
> /extra/sellcey/test-glibc/install/etc/ld.so.cache
> : No such file or directory

I meant the aux-cache file.

> The directory /extra/sellcey/test-glibc/install/etc exists but
> there is no ld.so.cache in it.  This may be related to how I build the
> toolchain, I hack the GCC sources to change where it finds the dynamic
> linker and I also hack library scripts like libc.so and libm.so (when
> libmvec is built) after they are built to use the prefix I specify when
> building.  Maybe I need some option when building glibc and/or some hack
> to change where ld.so.cache is located?  I am using --prefix when building glibc.
> I know the documentation says to always use --prefix=/usr but I am building
> a native toolchain that looks for all of its libraries, headers, etc.
> under a non-standard location when compiling/linking and when running and for
> that I need to use --prefix=/something-other-than-usr when building glibc.

I think we can tweak the test so that it works with a non-standard
--prefix, too.

The test currently hard-codes /var:

  /* Create the needed directories. */
  xmkdirp ("/var/cache/ldconfig", 0777);

We can tweak this to something that suits your needs.  It will likely
require updating support/support_paths.c, though.  If localestatedir is
relevant to this, it will need capturing and exporting.  I'll gladly
help with patch review.

Thanks,
Florian