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