libtool: revert a commit which re-introduced an already fixed problem
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
The commit ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified the changes made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a. The problem that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
---
...patch => libtool-0001-mips64-n64-linking.patch} | 0
package/libtool/libtool.mk | 13 -------------
2 files changed, 0 insertions(+), 13 deletions(-)
rename package/libtool/{libtool-mips64-n64-linking.post-install-patch => libtool-0001-mips64-n64-linking.patch} (100%)package/libtool/libtool-0001-mips64-n64-linking.patch renamed from package/libtool/libtool-mips64-n64-linking.post-install-patch +0 -0
package/libtool/libtool.mk +0 -13
@@ -13,19 +13,6 @@ 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 -endef -HOST_LIBTOOL_POST_INSTALL_HOOKS += HOST_LIBTOOL_FIXUP_LIBTOOL_M4 - $(eval $(autotools-package)) $(eval $(host-autotools-package))
Signature · 1 line
1.7.1
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified the changes made by the commit4268d3967e2d691c151d6b5629e4051deb077b9a. The problem that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
So this basically just reverts Arnouts fix for old automake versions? Do we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?
Quoted 42 lines
Signed-off-by Vicente Olivert Riera <[email protected]>--- ...patch => libtool-0001-mips64-n64-linking.patch} | 0 package/libtool/libtool.mk | 13 ------------- 2 files changed, 0 insertions(+), 13 deletions(-) rename package/libtool/{libtool-mips64-n64-linking.post-install-patch => libtool-0001-mips64-n64-linking.patch} (100%)package/libtool/libtool-0001-mips64-n64-linking.patch renamed from package/libtool/libtool-mips64-n64-linking.post-install-patch +0
-0package/libtool/libtool.mk +0
-13@@ -13,19 +13,6 @@ 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 -endef -HOST_LIBTOOL_POST_INSTALL_HOOKS += HOST_LIBTOOL_FIXUP_LIBTOOL_M4 - $(eval $(autotools-package)) $(eval $(host-autotools-package))Signature · 6 lines
1.7.1 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
Quoted 8 lines · Peter Korsgaard
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified the changes made by the commit4268d3967e2d691c151d6b5629e4051deb077b9a. The problem that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.
Quoted 6 lines
Quoted 2 lines
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/So this basically just reverts Arnouts fix for old automake versions? Do we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?
I indeed never tested if the issue of 4268d39 was still fixed. I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.
It should be rather easy to get this right then: a patch that fixes up
configure directly, rather than libtool.m4.
Regards,
Arnout
Quoted 46 lines
Quoted 44 lines
Signed-off-by Vicente Olivert Riera <[email protected]>--- ...patch => libtool-0001-mips64-n64-linking.patch} | 0 package/libtool/libtool.mk | 13 ------------- 2 files changed, 0 insertions(+), 13 deletions(-) rename package/libtool/{libtool-mips64-n64-linking.post-install-patch => libtool-0001-mips64-n64-linking.patch} (100%)package/libtool/libtool-0001-mips64-n64-linking.patch renamed from package/libtool/libtool-mips64-n64-linking.post-install-patch +0
-0package/libtool/libtool.mk +0
-13@@ -13,19 +13,6 @@ 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 -endef -HOST_LIBTOOL_POST_INSTALL_HOOKS += HOST_LIBTOOL_FIXUP_LIBTOOL_M4 - $(eval $(autotools-package)) $(eval $(host-autotools-package))Signature · 6 lines
1.7.1 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
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: revert a commit which re-introduced an already fixed problem
Quoted 16 lines · Arnout Vandecappelle
Quoted 8 lines · Peter Korsgaard
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified the changes made by the commit4268d3967e2d691c151d6b5629e4051deb077b9a. The problem that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.Quoted 6 lines
Quoted 2 lines
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/So this basically just reverts Arnouts fix for old automake versions? Do we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?
Quoted 6 lines
I indeed never tested if the issue of 4268d39 was still fixed. I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that fixes up
configure directly, rather than libtool.m4.
Hello Arnout,
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue. AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])
Quoted 51 lines
Regards,
ArnoutQuoted 46 lines
Quoted 44 lines
Signed-off-by Vicente Olivert Riera <[email protected]>--- ...patch => libtool-0001-mips64-n64-linking.patch} | 0 package/libtool/libtool.mk | 13 ------------- 2 files changed, 0 insertions(+), 13 deletions(-) rename package/libtool/{libtool-mips64-n64-linking.post-install-patch => libtool-0001-mips64-n64-linking.patch} (100%)package/libtool/libtool-0001-mips64-n64-linking.patch renamed from package/libtool/libtool-mips64-n64-linking.post-install-patch +0
-0package/libtool/libtool.mk +0
-14@@ -13,19 +13,6 @@ 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 -endef -HOST_LIBTOOL_POST_INSTALL_HOOKS += HOST_LIBTOOL_FIXUP_LIBTOOL_M4 - $(eval $(autotools-package)) $(eval $(host-autotools-package)) --1.7.1
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 1 line
Vincent
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
Quoted 31 lines · Vicente Olivert Riera
Quoted 21 lines · Arnout Vandecappelle
Quoted 11 lines · Peter Korsgaard
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified thechanges
Quoted 1 line
made by the commit
4268d3967e2d691c151d6b5629e4051deb077b9a. Theproblem
Quoted 3 lines
that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.
Quoted 8 lines
Quoted 2 lines
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
So this basically just reverts Arnouts fix for old automake versions? Do we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?
Quoted 6 lines
I indeed never tested if the issue of 4268d39 was still fixed. I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that fixes up
configure directly, rather than libtool.m4.Hello Arnout,
Quoted 8 lines
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])
I mean, it should work if you change the 1.11.1 by 1.11, but you would be ignoring that security issue. Is that worth to make it working on such old systems like Fedora 10? If Fedora 10 still has automake-1.11 is because there are no updates (at least security updates) for it, and Fedora Project does not provide support for Fedora 10 any more. Is it worth to modify the behaviour of an upstream patch
(http://git.buildroot.net/buildroot/commit/?id=4268d3967e2d691c151d6b5629e4051deb077b9a)
and raise the autobuild failures again just to make it working on such old systems which still have automake-1.11?
Quoted 66 lines
Quoted 64 lines
Regards,
ArnoutQuoted 59 lines
Quoted 6 lines
Signed-off-by Vicente Olivert Riera <[email protected]>--- ...patch => libtool-0001-mips64-n64-linking.patch} | 0 package/libtool/libtool.mk | 13-------------
Quoted 2 lines
2 files changed, 0 insertions(+), 13 deletions(-)rename
package/libtool/{libtool-mips64-n64-linking.post-install-patch => libtool-0001-mips64-n64-linking.patch} (100%)
Quoted 1 line
diff --git
a/package/libtool/libtool-mips64-n64-linking.post-install-patch
b/package/libtool/libtool-0001-mips64-n64-linking.patchQuoted 2 lines
similarity index 100%
rename frompackage/libtool/libtool-mips64-n64-linking.post-install-patch
package/libtool/libtool.mk LIBTOOL_LICENSE_FILES = COPYING · line 16
Quoted 10 lines
rename to
package/libtool/libtool-0001-mips64-n64-linking.patchpackage/libtool/libtool.mk +0
-1@@ -13,19 +13,6 @@ LIBTOOL_LICENSE_FILES = COPYING HOST_LIBTOOL_LIBTOOL_PATCH = NO -# libtool-mips64-n64-linking.post-install-patch is an upstreampatch that
package/libtool/libtool.mk LIBTOOL_LICENSE_FILES = COPYING · line 17
Quoted 1 line
package/libtool/libtool.mk +0
-1-# fixes MIPS64 n64 link failures. However, because the patchtouches an m4
package/libtool/libtool.mk LIBTOOL_LICENSE_FILES = COPYING · line 18
Quoted 1 line
package/libtool/libtool.mk +0
-1-# file, applying it triggers a run of autoconf, automake, etc.This sometimes
package/libtool/libtool.mk LIBTOOL_LICENSE_FILES = COPYING · line 19
Quoted 1 line
package/libtool/libtool.mk +0
-1-# leads to build failures due to incompatible system autotools.We cannot
package/libtool/libtool.mk LIBTOOL_LICENSE_FILES = COPYING · line 20
Quoted 1 line
package/libtool/libtool.mk +0
-1-# simply set HOST_LIBTOOL_AUTORECONF = YES because that wouldcreate a
package/libtool/libtool.mk LIBTOOL_LICENSE_FILES = COPYING · line 21
Quoted 1 line
package/libtool/libtool.mk +0
-1-# circular dependency on host-libtool. Therefore, just apply thepatch
package/libtool/libtool.mk LIBTOOL_LICENSE_FILES = COPYING · line 28
Quoted 4 lines
package/libtool/libtool.mk +0
-4-# 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
Quoted 13 lines
package/libtool/libtool.mk +0
-4-endef -HOST_LIBTOOL_POST_INSTALL_HOOKS += HOST_LIBTOOL_FIXUP_LIBTOOL_M4 - $(eval $(autotools-package)) $(eval $(host-autotools-package)) --1.7.1
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 1 line
Vincent
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
In reply to Vicente Olivert RieraQuoted 31 lines · Vicente Olivert Riera
Quoted 21 lines · Arnout Vandecappelle
Quoted 11 lines · Peter Korsgaard
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified thechanges
Quoted 1 line
made by the commit
4268d3967e2d691c151d6b5629e4051deb077b9a. Theproblem
Quoted 3 lines
that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.
Quoted 8 lines
Quoted 2 lines
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
So this basically just reverts Arnouts fix for old automake versions? Do we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?
Quoted 6 lines
I indeed never tested if the issue of 4268d39 was still fixed. I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that fixes up
configure directly, rather than libtool.m4.Hello Arnout,
Quoted 8 lines
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])
I meant: create a patch that fixes up the configure script directly.
Can you give me a minimal defconfig that shows the problem (preferably
using an external toolchain, e.g. from the autobuilders)? Then I can try to create that patch.
Regards,
Arnout
[snip]
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: revert a commit which re-introduced an already fixed problem
Quoted 41 lines · Arnout Vandecappelle
Quoted 31 lines · Vicente Olivert Riera
Quoted 21 lines · Arnout Vandecappelle
Quoted 11 lines · Peter Korsgaard
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified thechanges
Quoted 1 line
made by the commit
4268d3967e2d691c151d6b5629e4051deb077b9a. Theproblem
Quoted 3 lines
that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.
Quoted 8 lines
Quoted 2 lines
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
So this basically just reverts Arnouts fix for old automake versions? Do we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?
Quoted 6 lines
I indeed never tested if the issue of 4268d39 was still fixed. I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that fixes up
configure directly, rather than libtool.m4.Hello Arnout,
Quoted 8 lines
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])
Quoted 5 lines
I meant: create a patch that fixes up the configure script directly.
Can you give me a minimal defconfig that shows the problem (preferably
using an external toolchain, e.g. from the autobuilders)? Then I can try to create that patch.
Hello Arnout,
unfortunately I don't have a minimal defconfig to reproduce that failure. I use the one in the autobuild:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Regards,
Vincent
Quoted 7 lines
Regards,
Arnout[snip]
Signature · 1 line
Vincent
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
Quoted 51 lines · Vicente Olivert Riera
Quoted 44 lines · Arnout Vandecappelle
Quoted 34 lines · Vicente Olivert Riera
Quoted 23 lines · Arnout Vandecappelle
Quoted 13 lines · Peter Korsgaard
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified thechanges
Quoted 1 line
made by the commit
4268d3967e2d691c151d6b5629e4051deb077b9a. Theproblem
Quoted 6 lines
that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.
Fixes:
Quoted 8 lines
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
So this basically just reverts Arnouts fix for old automake versions? Do
we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?Quoted 7 lines
I indeed never tested if the issue of 4268d39 was still fixed. I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that
fixes up
configure directly, rather than libtool.m4.Hello Arnout,
Quoted 8 lines
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])Quoted 5 lines
I meant: create a patch that fixes up the configure script directly.
Can you give me a minimal defconfig that shows the problem (preferably
using an external toolchain, e.g. from the autobuilders)? Then I can try to create that patch.
Quoted 6 lines
Hello Arnout,
unfortunately I don't have a minimal defconfig to reproduce that failure. I use the one in the autobuild:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Okay, the issue is that that defconfig enables libtool for the target,
and autoreconf adds $(STAGING_DIR)/usr/share/aclocal to the include path. So the unpatched libtool will take precedence.
Patch follows.
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: revert a commit which re-introduced an already fixed problem
Quoted 54 lines · Arnout Vandecappelle
Quoted 53 lines · Vicente Olivert Riera
Quoted 44 lines · Arnout Vandecappelle
Quoted 34 lines · Vicente Olivert Riera
Quoted 23 lines · Arnout Vandecappelle
Quoted 13 lines · Peter Korsgaard
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modified thechanges
Quoted 1 line
made by the commit
4268d3967e2d691c151d6b5629e4051deb077b9a. Theproblem
Quoted 6 lines
that was fixed by the former commit is present again due to those modifications. This patch reverts those modifications to have that problem fixed again.
Fixes:
Quoted 8 lines
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
So this basically just reverts Arnouts fix for old automake versions? Do
we understand why it doesn't work? Can we come up with a solution that both fixes the n64 issue and old automake?Quoted 7 lines
I indeed never tested if the issue of 4268d39 was still fixed. I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that
fixes up
configure directly, rather than libtool.m4.Hello Arnout,
Quoted 8 lines
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])Quoted 5 lines
I meant: create a patch that fixes up the configure script directly.
Can you give me a minimal defconfig that shows the problem (preferably
using an external toolchain, e.g. from the autobuilders)? Then I can try to create that patch.Hello Arnout,
Quoted 8 lines
Quoted 4 lines
unfortunately I don't have a minimal defconfig to reproduce that failure. I use the one in the autobuild:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Okay, the issue is that that defconfig enables libtool for the target,
and autoreconf adds $(STAGING_DIR)/usr/share/aclocal to the include path. So the unpatched libtool will take precedence.
Hello Arnout,
do you mean that enabling only BR2_PACKAGE_LIBTOOL and BR2_PACKAGE_LIBISCSI you can reproduce the failure?
Quoted 6 lines
Patch follows.
Regards,
Arnout
Signature · 1 line
Vincent
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
Quoted 69 lines · Vicente Olivert Riera
Quoted 68 lines · Arnout Vandecappelle
Quoted 66 lines · Vicente Olivert Riera
Quoted 51 lines · Arnout Vandecappelle
Quoted 41 lines · Vicente Olivert Riera
Quoted 29 lines · Arnout Vandecappelle
Quoted 22 lines · Peter Korsgaard
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Vicente" == Vicente Olivert Riera <[email protected]> writes:
The commit
ed73d1d2e3703290e74bb076bc6dd0417aa3ba21modifiedthe
changesQuoted 1 line
made by the commit
4268d3967e2d691c151d6b5629e4051deb077b9a.The
problemQuoted 1 line
that was fixed by the former commit is present again due to
those
Quoted 1 line
modifications. This patch reverts those modifications to
have that
Quoted 4 lines
problem fixed again.
Fixes:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Quoted 5 lines
So this basically just reverts Arnouts fix for old automake versions? Do
we understand why it doesn't work? Can we come up with a solution that
both fixes the n64 issue and old automake?Quoted 8 lines
I indeed never tested if the issue of 4268d39 was still fixed.
I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that
fixes up
configure directly, rather than libtool.m4.Hello Arnout,
Quoted 8 lines
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])Quoted 6 lines
I meant: create a patch that fixes up the configure script directly.
Can you give me a minimal defconfig that shows the problem
(preferably
using an external toolchain, e.g. from the autobuilders)? Then I can try to create that patch.Hello Arnout,
unfortunately I don't have a minimal defconfig to reproduce that failure. I use the one in the autobuild:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Quoted 8 lines
Quoted 3 lines
Okay, the issue is that that defconfig enables libtool for the target,
and autoreconf adds $(STAGING_DIR)/usr/share/aclocal to the include path. So the unpatched libtool will take precedence.Hello Arnout,
do you mean that enabling only
BR2_PACKAGE_LIBTOOLandBR2_PACKAGE_LIBISCSIyou can reproduce the failure?
I haven't tried that specifically, but I think yes.
But actually, I think the easier solution is to just bump libtool to
2.4.2.444. I'm going to run some tests on that and see how far we get.
Regards,
Arnout
Quoted 10 lines
Quoted 8 lines
Patch follows.
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: revert a commit which re-introduced an already fixed problem
Quoted 70 lines · Arnout Vandecappelle
Quoted 69 lines · Vicente Olivert Riera
Quoted 68 lines · Arnout Vandecappelle
Quoted 66 lines · Vicente Olivert Riera
Quoted 51 lines · Arnout Vandecappelle
Quoted 41 lines · Vicente Olivert Riera
Quoted 29 lines · Arnout Vandecappelle
Quoted 22 lines · Peter Korsgaard
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Vicente" == Vicente Olivert Riera <[email protected]>
writes:> The commit ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified the changes > made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a.The
problem
> that was fixed by the former commit is present again due to
those
> modifications. This patch reverts those modifications to
have that
> problem fixed again.> Fixes:
>
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/Quoted 5 lines
So this basically just reverts Arnouts fix for old automake versions? Do
we understand why it doesn't work? Can we come up with a solution that
both fixes the n64 issue and old automake?Quoted 8 lines
I indeed never tested if the issue of 4268d39 was still fixed.
I just
understood from the commit message that it is only relevant for the libtool.m4 that is installed in the host dir, so I made use of that.It should be rather easy to get this right then: a patch that
fixes up
configure directly, rather than libtool.m4.Hello Arnout,
Quoted 8 lines
how do you suggest to do it? Requiring an older automake would not be possible because of this:
dnl These are bootstrap requirements! Once built, libtool may work with dnl much older releases of autoconf and automake. See release notes. dnl 1.11 is needed for color-tests, 1.11.1 fixes a security issue.
AM_INIT_AUTOMAKE([1.11.1 gnu subdir-objects dist-xz color-tests parallel-tests])Quoted 6 lines
I meant: create a patch that fixes up the configure script directly.
Can you give me a minimal defconfig that shows the problem
(preferably
using an external toolchain, e.g. from the autobuilders)? Then I can try to create that patch.Hello Arnout,
unfortunately I don't have a minimal defconfig to reproduce that failure. I use the one in the autobuild:
http://autobuild.buildroot.net/results/b86/b86a83c6549004f226e7255242e54ef4e50c5ec3/
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Okay, the issue is that that defconfig enables libtool for the target,
and autoreconf adds $(STAGING_DIR)/usr/share/aclocal to the include path. So the unpatched libtool will take precedence.Hello Arnout,
do you mean that enabling only
BR2_PACKAGE_LIBTOOLandBR2_PACKAGE_LIBISCSIyou can reproduce the failure?
Hello Arnout,
Quoted 1 line
I haven't tried that specifically, but I think yes.
I have tried it, and the failure is not reproduced with those options only. That's why I used the full config file from the autobuild report.
Quoted 2 lines
But actually, I think the easier solution is to just bump libtool to
2.4.2.444. I'm going to run some tests on that and see how far we get.
I see, you want to bump to a version with the upstream patch already included, so the autoconf won't be triggered because your are not patching the m4 file.
Quoted 15 lines
Regards,
ArnoutQuoted 10 lines
Quoted 8 lines
Patch follows.
Regards,
Arnout
Signature · 1 line
Vincent
PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem
Quoted 3 lines · Vicente Olivert Riera
Quoted 2 lines · Arnout Vandecappelle
Quoted 1 line · Vicente Olivert Riera
On 03/19/2014 01:50 PM, Arnout Vandecappelle wrote:
[snip]
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Okay, the issue is that that defconfig enables libtool for the
target,
and autoreconf adds $(STAGING_DIR)/usr/share/aclocal to the include path.
So the unpatched libtool will take precedence.Hello Arnout,
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
do you mean that enabling only
BR2_PACKAGE_LIBTOOLandBR2_PACKAGE_LIBISCSIyou can reproduce the failure?I haven't tried that specifically, but I think yes.
I have tried it, and the failure is not reproduced with those options only. That's why I used the full config file from the autobuild report.
Yeah, that's because libtool normally comes after iscsi, but in the
autobuild failure gst-plugins-good is built first and that depends on pulseaudio and that depends on libtool.
Quoted 7 lines
Quoted 3 lines
But actually, I think the easier solution is to just bump libtool to
2.4.2.444. I'm going to run some tests on that and see how far we get.I see, you want to bump to a version with the upstream patch already included, so the autoconf won't be triggered because your are not patching the m4 file.
Exactly.
But unfortunately the .444 "release" is just a git snapshot, without
configure script, so that doesn't solve the problem.
Possible approaches:
1. Apply the patch to the libtool.m4 in staging as well.
2. Revert to a normal patch, and avoid reconf by touching the generated files.
3. Ask upstream to create a new release.
I'll send a patch for (2) and do (3) as well.
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