libtool: use a different way to avoid autoreconfiguration
PATCH 1/1 libtool: use a different way to avoid autoreconfiguration
In 4268d39, a patch was added to update libtool.m4 for MIPS n64 targets. However, this caused the configure script to be regenerated during the build steps, which in turn caused build failures on Fedora 12 hosts. In ed73d1d, this was fixed by patching the installed libtool.m4 file instead of the source file.
However, ed73d1d did not take into account that the target libtool will also install libtool.m4 to staging, and that that version has precedence over the one in HOST_DIR.
Therefore, this patch takes a different approach: the source file is patched in the usual way, and instead the reconfigure is avoided by touching the generated files.
On the target, we also cannot use the AUTORECONF mechanism because of some mysterious Makefile.inc file. So just use the same approach and wait for upstream to make a new release.
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
---
...l-patch => libtool-01-mips64-n64-linking.patch} | 0
package/libtool/libtool.mk | 29 ++++++++++++++--------
2 files changed, 18 insertions(+), 11 deletions(-)
rename package/libtool/{libtool-mips64-n64-linking.post-install-patch => libtool-01-mips64-n64-linking.patch} (100%)package/libtool/libtool-01-mips64-n64-linking.patch renamed from package/libtool/libtool-mips64-n64-linking.post-install-patch +0 -0
package/libtool/libtool.mk +18 -11
@@ -13,18 +13,25 @@ LIBTOOL_LICENSE_FILES = COPYING HOST_LIBTOOL_LIBTOOL_PATCH = NO -# libtool-mips64-n64-linking.post-install-patch is an upstream patch that -# fixes MIPS64 n64 link failures. However, because the patch touches an m4 -# file, applying it triggers a run of autoconf, automake, etc. This sometimes -# leads to build failures due to incompatible system autotools. We cannot -# simply set HOST_LIBTOOL_AUTORECONF = YES because that would create a -# circular dependency on host-libtool. Therefore, just apply the patch -# directly on the installed file. -define HOST_LIBTOOL_FIXUP_LIBTOOL_M4 - patch $(HOST_DIR)/usr/share/aclocal/libtool.m4 < \ - package/libtool/libtool-mips64-n64-linking.post-install-patch +# We have a patch that affects libtool.m4, which triggers an autoreconf +# in the build step. Normally we would set AUTORECONF = YES, but this +# doesn't work for host-libtool because that creates a circular +# dependency. Instead, touch the generated files so autoreconf is not +# triggered in the build step. Note that aclocal.m4 has to be touched +# first since the rest depends on it. Note that we don't need the changes +# in libtool.m4 in our configure script, because we're not actually +# running it on the target. +# For the target, we would normally be able to use AUTORECONF, but it +# fails on libltdl/Makefile.inc. Rather than trying to fix that failure, +# just use the same hack as on the host. +define LIBTOOL_AVOID_AUTORECONF_HOOK + find $(@D) -name aclocal.m4 -exec touch '{}' \; + find $(@D) -name config-h.in -exec touch '{}' \; + find $(@D) -name configure -exec touch '{}' \; + find $(@D) -name Makefile.in -exec touch '{}' \; endef -HOST_LIBTOOL_POST_INSTALL_HOOKS += HOST_LIBTOOL_FIXUP_LIBTOOL_M4 +LIBTOOL_PRE_CONFIGURE_HOOKS += LIBTOOL_AVOID_AUTORECONF_HOOK +HOST_LIBTOOL_PRE_CONFIGURE_HOOKS += LIBTOOL_AVOID_AUTORECONF_HOOK $(eval $(autotools-package)) $(eval $(host-autotools-package))
Signature · 1 line
1.9.0
PATCH 1/1 libtool: use a different way to avoid autoreconfiguration
Dear Arnout Vandecappelle (Essensium/Mind),
Quoted 10 lines · Arnout Vandecappelle (Essensium/Mind)
In 4268d39, a patch was added to update libtool.m4 for MIPS n64 targets. However, this caused the configure script to be regenerated during the build steps, which in turn caused build failures on Fedora 12 hosts. In ed73d1d, this was fixed by patching the installed libtool.m4 file instead of the source file.
However, ed73d1d did not take into account that the target libtool will also install libtool.m4 to staging, and that that version has precedence over the one in
HOST_DIR.
Quoted 7 lines
Therefore, this patch takes a different approach: the source file is patched in the usual way, and instead the reconfigure is avoided by touching the generated files.
On the target, we also cannot use the AUTORECONF mechanism because of some mysterious Makefile.inc file. So just use the same approach and wait for upstream to make a new release.
Shouldn't we mark libtool on the target as something deprecated? We have already removed the support for autoconf and automake on the target, so having libtool seems quite useless, no?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 libtool: use a different way to avoid autoreconfiguration
Quoted 18 lines · Thomas Petazzoni
Dear Arnout Vandecappelle (Essensium/Mind),
Quoted 14 lines · Arnout Vandecappelle (Essensium/Mind)
In 4268d39, a patch was added to update libtool.m4 for MIPS n64 targets. However, this caused the configure script to be regenerated during the build steps, which in turn caused build failures on Fedora 12 hosts. In ed73d1d, this was fixed by patching the installed libtool.m4 file instead of the source file.
However, ed73d1d did not take into account that the target libtool will also install libtool.m4 to staging, and that that version has precedence over the one in
HOST_DIR.Therefore, this patch takes a different approach: the source file is patched in the usual way, and instead the reconfigure is avoided by touching the generated files.
Quoted 7 lines
Quoted 3 lines
On the target, we also cannot use the AUTORECONF mechanism because of some mysterious Makefile.inc file. So just use the same approach and wait for upstream to make a new release.
Shouldn't we mark libtool on the target as something deprecated? We have already removed the support for autoconf and automake on the target, so having libtool seems quite useless, no?
Pulseaudio depends on libtool. I guess it actually depends on libltdl,
though. But is precisely in libltdl that the problem occurs.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/1 libtool: use a different way to avoid autoreconfiguration
Dear Arnout Vandecappelle,
Quoted 6 lines · Arnout Vandecappelle
Quoted 3 lines
Shouldn't we mark libtool on the target as something deprecated? We have already removed the support for autoconf and automake on the target, so having libtool seems quite useless, no?
Pulseaudio depends on libtool. I guess it actually depends on libltdl,
though. But is precisely in libltdl that the problem occurs.
But isn't the libltdl code normally "copied" into the project when autoreconf is made, so that there should in fact not be any dependency from pulseaudio to the target libtool?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 libtool: use a different way to avoid autoreconfiguration
Quoted 8 lines · Thomas Petazzoni
Dear Arnout Vandecappelle,
Quoted 4 lines · Arnout Vandecappelle
Quoted 3 lines
Shouldn't we mark libtool on the target as something deprecated? We have already removed the support for autoconf and automake on the target, so having libtool seems quite useless, no?
Quoted 6 lines
Quoted 2 lines
Pulseaudio depends on libtool. I guess it actually depends on libltdl,
though. But is precisely in libltdl that the problem occurs.But isn't the libltdl code normally "copied" into the project when autoreconf is made, so that there should in fact not be any dependency from pulseaudio to the target libtool?
I have no idea. Feel free to investigate.
If we do deprecate libtool on target, then this patch is no longer
needed to fix the autobuild issue. However, perhaps it would still be considered a cleaner way to handle things?
Or perhaps another cleaner way is to use
touch -t 201110171216 $(@D)/libltdl/m4/libtool.m4
in a post-patch hook. The -t option is POSIX so it should be OK to use. There are actually many more places where we could use that.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Thomas Petazzoni
AppliedPATCH 1/1 libtool: use a different way to avoid autoreconfiguration
In reply to Arnout Vandecappelle (Essensium/Mind)Dear Arnout Vandecappelle (Essensium/Mind),
Quoted 14 lines · Arnout Vandecappelle (Essensium/Mind)
In 4268d39, a patch was added to update libtool.m4 for MIPS n64 targets. However, this caused the configure script to be regenerated during the build steps, which in turn caused build failures on Fedora 12 hosts. In ed73d1d, this was fixed by patching the installed libtool.m4 file instead of the source file.
However, ed73d1d did not take into account that the target libtool will also install libtool.m4 to staging, and that that version has precedence over the one in
HOST_DIR.Therefore, this patch takes a different approach: the source file is patched in the usual way, and instead the reconfigure is avoided by touching the generated files.
Quoted 8 lines
On the target, we also cannot use the AUTORECONF mechanism because of some mysterious Makefile.inc file. So just use the same approach and wait for upstream to make a new release.
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Applied, thanks.
Can you let me know if this patch was superseds
http://patchwork.ozlabs.org/patch/331090/ ?
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 libtool: use a different way to avoid autoreconfiguration
Quoted 25 lines · Thomas Petazzoni
Dear Arnout Vandecappelle (Essensium/Mind),
Quoted 21 lines · Arnout Vandecappelle (Essensium/Mind)
In 4268d39, a patch was added to update libtool.m4 for MIPS n64 targets. However, this caused the configure script to be regenerated during the build steps, which in turn caused build failures on Fedora 12 hosts. In ed73d1d, this was fixed by patching the installed libtool.m4 file instead of the source file.
However, ed73d1d did not take into account that the target libtool will also install libtool.m4 to staging, and that that version has precedence over the one in
HOST_DIR.Therefore, this patch takes a different approach: the source file is patched in the usual way, and instead the reconfigure is avoided by touching the generated files.
On the target, we also cannot use the AUTORECONF mechanism because of some mysterious Makefile.inc file. So just use the same approach and wait for upstream to make a new release.
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Quoted 6 lines
Quoted 1 line
Applied, thanks.
Can you let me know if this patch was superseds
http://patchwork.ozlabs.org/patch/331090/ ?
Yes it does, I marked it as such.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 1/1 libtool: use a different way to avoid autoreconfiguration
Dear Arnout Vandecappelle,
Quoted 4 lines · Arnout Vandecappelle
Quoted 2 lines
Can you let me know if this patch was superseds
http://patchwork.ozlabs.org/patch/331090/ ?Yes it does, I marked it as such.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com