On 17 Jan 2022 11:09, Sam James wrote:
> When -I${SYSROOT} is injected, it'll override the default of -Im4, which
> results in trying to install macros to ${SYSROOT} (a sandbox violation)
> when they can't be found.
>
> From aclocal(1):
> ```
> -I DIR add directory to search list for .m4 files
>
> --install
> copy third-party files to the first -I directory
> ```
>
> The first directry is normally -Im4 if anything, whereas when injected
> (when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so
> we try to copy macros to somewhere outside of the build directory).
we should define the semantics we want and bring it upstream to get into
automake. although it seems like ACLOCAL_PATH might work well enough
for us now to switch to that.
as a stop gap, it seems like the use of --install is pretty low ? we're
cross-compiling about ~2.5k packages in CrOS every day and never seen a
failure here. so the few packages which are running into troubles can
workaround it by setting AT_SYS_M4DIR right ?
> In EAPI 7+, this is almost always the case! We don't generally expect
> to find macros (particularly things like autoconf-archive) in ${SYSROOT}
> because that's for DEPEND-class dependencies, then they end up being
> copied in unnecessarily and wrongly.
i think this optimism is misplaced. libraries often install m4 files
which is precisely why this logic is in here.
https://bugs.gentoo.org/677002#c10
deleting this check will break things. prob more than we're fixing.
-mike
signature.asc
Description: PGP signature
