public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Sam James <sam@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org, cross@gentoo.org,
	base-system@gentoo.org, chewi@gentoo.org
Subject: [gentoo-dev] Re: [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal
Date: Wed, 19 Jan 2022 01:35:27 -0500	[thread overview]
Message-ID: <YeexLwjU7NmBNWpJ@vapier> (raw)
In-Reply-To: <20220117110950.139015-1-sam@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-01-19  6:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-17 11:09 [gentoo-dev] [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal Sam James
2022-01-17 11:09 ` [gentoo-dev] [PATCH 2/4] autotools.eclass: use --system-acdir for aclocal Sam James
2022-01-17 11:15   ` Sam James
2022-01-17 11:09 ` [gentoo-dev] [PATCH 3/4] autotools.eclass: update for latest automake 1.16.4 Sam James
2022-01-17 11:09 ` [gentoo-dev] [PATCH 4/4] autotools.eclass: update for autoconf 2.71 Sam James
2022-01-19  6:35 ` Mike Frysinger [this message]
2022-01-20  5:58   ` [gentoo-dev] [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YeexLwjU7NmBNWpJ@vapier \
    --to=vapier@gentoo.org \
    --cc=base-system@gentoo.org \
    --cc=chewi@gentoo.org \
    --cc=cross@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=sam@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox