This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------oMjcbc7qIz9DfTH0hVewN3ti
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3/13/25 12:21 PM, orbea@riseup.net wrote:

From: orbea <orbea@riseup.net>

When using slibtoolize it needs the /usr/share/slibtool/slibtool.m4 file
to properly create the configure script. The current method of using it
is to set AT_SYS_M4DIR in make.conf, while this works for most cases it
does not work for app-crypt/tpm2-tss which uses ACLOCAL_AMFLAGS with the '--install' argument in Makefile.am which results in it trying to
install .m4 files to /usr/share/slibtool. This thankfully fails due to sandbox.

To solve this problem the /usr/share/slibtool path can be directly
appended to "${T}"/aclocal/dirlist if the LIBTOOLIZE variable is set to 'slibtoolize'.

Closes: https://bugs.gentoo.org/950648
Signed-off-by: orbea <orbea@riseup.net>
---
eclass/autotools.eclass | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 1545b88bc4..023bedc8eb 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -382,6 +382,12 @@ eaclocal() {
${BROOT}/usr/share/aclocal
${ESYSROOT}/usr/share/aclocal
EOF
+ if [ "${LIBTOOLIZE:-}" = 'slibtoolize' ]; then
+ printf '%s\n' \
+ "${BROOT}/usr/share/slibtool" \
+ "${ESYSROOT}/usr/share/slibtool" \
+ >> "${T}"/aclocal/dirlist
+ fi
fi

[[ ! -f aclocal.m4 || -n $(grep -e 'generated.*by aclocal' aclocal.m4) ]] && \

I had discussed this in IRC last week with Sam. My conclusion was:

We end up running with

aclocal -I ${AT_M4DIR} -I ${AT_SYS_M4DIR} ${ACLOCAL_AMFLAGS} --system-acdir="${T}"/aclocal

We *should* be running with this instead:


aclocal -I ${AT_M4DIR} ${ACLOCAL_AMFLAGS} -I ${AT_SYS_M4DIR} --system-acdir="${T}"/aclocal


Slibtool is a symptom of an underlying problem which is that the eclass
has broken ordering regardless.


--
Eli Schwartz

--------------oMjcbc7qIz9DfTH0hVewN3ti--

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ9OoPwUDAAAAAAAKCRCEp9ErcA0vV8AP AQCqV5smmrOmYvLhcMkF6A/aSrlyhWLTDqOurPkJzsqTrwEA4i+M/ZaBZcSonV9V7xsFOfWYLZiG WGbVGyhT22AepAE=
=u7AQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 13 Mar 2025 23:53:34 -0400
Eli Schwartz <eschwartz@gentoo.org> wrote:

On 3/13/25 12:21 PM, orbea@riseup.net wrote:

From: orbea <orbea@riseup.net>

When using slibtoolize it needs the /usr/share/slibtool/slibtool.m4
file to properly create the configure script. The current method of
using it is to set AT_SYS_M4DIR in make.conf, while this works for
most cases it does not work for app-crypt/tpm2-tss which uses ACLOCAL_AMFLAGS with the '--install' argument in Makefile.am which
results in it trying to install .m4 files to /usr/share/slibtool.
This thankfully fails due to sandbox.

To solve this problem the /usr/share/slibtool path can be directly
appended to "${T}"/aclocal/dirlist if the LIBTOOLIZE variable is
set to 'slibtoolize'.

Closes: https://bugs.gentoo.org/950648
Signed-off-by: orbea <orbea@riseup.net>
---
eclass/autotools.eclass | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 1545b88bc4..023bedc8eb 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -382,6 +382,12 @@ eaclocal() {
${BROOT}/usr/share/aclocal
${ESYSROOT}/usr/share/aclocal
EOF
+ if [ "${LIBTOOLIZE:-}" = 'slibtoolize' ]; then
+ printf '%s\n' \
+ "${BROOT}/usr/share/slibtool" \
+ "${ESYSROOT}/usr/share/slibtool" \
+ >> "${T}"/aclocal/dirlist
+ fi
fi

[[ ! -f aclocal.m4 || -n $(grep -e 'generated.*by aclocal'
aclocal.m4) ]] && \

I had discussed this in IRC last week with Sam. My conclusion was:

We end up running with

aclocal -I ${AT_M4DIR} -I ${AT_SYS_M4DIR} ${ACLOCAL_AMFLAGS} --system-acdir="${T}"/aclocal

We *should* be running with this instead:

aclocal -I ${AT_M4DIR} ${ACLOCAL_AMFLAGS} -I ${AT_SYS_M4DIR} --system-acdir="${T}"/aclocal

The trivial change which does work for tpm2-tss would be to change it
to:

aclocal -I ${AT_M4DIR} ${ACLOCAL_AMFLAGS} --system-acdir="${T}"/aclocal
-I ${AT_SYS_M4DIR}

Changing it as you suggested I think would be significantly more
complicated and would require refactoring the eclass.

However I wonder if my patch still has merit since in the case of
slibtoolize it only needs to be set for aclocal and not all the other
tools that are executed during eautoreconf? Although including it
everywhere doesn't seem to cause any problems yet either.

Slibtool is a symptom of an underlying problem which is that the
eclass has broken ordering regardless.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------AGKaddkaCCdnz1JEZqct0BrG
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 3/14/25 11:31 AM, orbea wrote:

Changing it as you suggested I think would be significantly more
complicated and would require refactoring the eclass.

Yes, it's unfortunately the type of thing that would be a somewhat
involved change. :(

However I wonder if my patch still has merit since in the case of
slibtoolize it only needs to be set for aclocal and not all the other
tools that are executed during eautoreconf? Although including it
everywhere doesn't seem to cause any problems yet either.

Not sure I understand what you mean. :) This is only used for aclocal
either way.

And your patch is I think fundamentally correct.

The externally injected AT_SYS_M4DIR documented in the wiki is an understandable hack but nonetheless a *hack* and we should move away
from it by treating slibtool the same as our generic aclocal handling.

That's true even though I'd *also* like to see AT_SYS_M4DIR unbroken. It
is nominally for "cases such as slibtool but where the user / system
integrator has added it in ways ::gentoo cannot predict", but given
slibtool is packaged in ::gentoo it is eminently reasonable to just
include it directly in the list.

...

Hmm, now that makes me think. Sam, maybe we can fix AT_SYS_M4DIR by
making it not get passed as -I but instead get concatenated into ${T}/aclocal/dirlist


--
Eli Schwartz

--------------AGKaddkaCCdnz1JEZqct0BrG--

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ9+f+QUDAAAAAAAKCRCEp9ErcA0vV/KU AQDxqeukiQs3Uou/udbWdjBO6QNnh4ZgicXcyslhqYpZtQD/YbQzdmY0Uq0Z+MOVIlRzFfVASiXB NyIpFVUK07fu3As=
=lK/5
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Eli Schwartz <eschwartz@gentoo.org> writes:

On 3/14/25 11:31 AM, orbea wrote:

Changing it as you suggested I think would be significantly more
complicated and would require refactoring the eclass.

Yes, it's unfortunately the type of thing that would be a somewhat
involved change. :(

However I wonder if my patch still has merit since in the case of
slibtoolize it only needs to be set for aclocal and not all the other
tools that are executed during eautoreconf? Although including it
everywhere doesn't seem to cause any problems yet either.

Not sure I understand what you mean. :) This is only used for aclocal
either way.

And your patch is I think fundamentally correct.

The externally injected AT_SYS_M4DIR documented in the wiki is an understandable hack but nonetheless a *hack* and we should move away
from it by treating slibtool the same as our generic aclocal handling.

That's true even though I'd *also* like to see AT_SYS_M4DIR unbroken. It
is nominally for "cases such as slibtool but where the user / system integrator has added it in ways ::gentoo cannot predict", but given
slibtool is packaged in ::gentoo it is eminently reasonable to just
include it directly in the list.

...

Hmm, now that makes me think. Sam, maybe we can fix AT_SYS_M4DIR by
making it not get passed as -I but instead get concatenated into ${T}/aclocal/dirlist

I agree, and I think it was an oversight to not do that when introducing
it...

Eli or orbea, do you want to send a patch for that (on top of this one)?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)