This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V8 test-in-container patch
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: nd <nd at arm dot com>, "carlos at redhat dot com" <carlos at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "fweimer at redhat dot com" <fweimer at redhat dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>
- Date: Thu, 11 Oct 2018 09:51:19 +0000
- Subject: Re: V8 test-in-container patch
- References: <xnwoqpvc5h.fsf@greed.delorie.com>
On 10/10/18 20:23, DJ Delorie wrote:
>
> Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
>> is this step really needed? i thought all binaries in
>> the testroot are newly built so we should know exactly
>> the dependencies (including dlopen ones which are not
>> handled by this logic).
>
> The step is needed to handle DSOs that gcc adds dependencies for (like
> libgcc_s.so). We install them in the testroot in the same location as
> outside the testroot. This may be in /lib, or may be in
> /home/me/cross/glibc/arm/lib, etc.
>
i still don't see what guarantees that copies will
be in the library search path inside the container.
if it's only done for libgcc_s.so.1 and libstdc++.so.6
then i'd just explicitly copy those two from the build
dir to the testroot lib prefix.
> We do this part before the "make install" to ensure if any glibc DSOs
> are pulled in from outside the build, they get overwritten by built
> DSOs.
>
> Adding flags to find our own DSOs at this step isn't important because
> we need to copy them, it's important because we don't want to copy the
> wrong ones into a location that might override the newly built ones
> (i.e. earlier in ld.so's search path).
>