> On 19 Jan 2022, at 06:35, Mike Frysinger wrote:
>
> 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 ?
I've only seen it in the wild with:
- app-crypt/tpm2-tss (https://bugs.gentoo.org/756211
)
- another package which I hit during "normal" use but I'm afraid I can't
recall what. I suspect I hit it before Python grew a BDEPEND on autoconf-archive
so we're less likely to hit it now.
But I accept it's niche. See below though, I think we agree that AT_SYS_M4DIR /
system acdir should be satisfactory here.
I don't mind keeping the old logic for < EAPI 7 if that'll help you in CrOS
though.
>
>> 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.
Sorry, you're absolutely right here!
But I think it's addressed by the system-acdir commit that follows it up.
i.e. the commit message is totally wrong (and I'll fix this), but the change is
correct
given we follow it up with seemingly a better way of handling
the original case.
Does that sound right?
Best,
sam
signature.asc
Description: Message signed with OpenPGP
