libtool: revert a commit which re-introduced an already fixed problem

PATCH New Vicente Olivert Riera 3 participants 12 messages Mar 17, 2014 – Mar 19, 2014

Share & tools

Vicente Olivert Riera

author

2014-03-17 17:40 UTC #0 lore raw

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/

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 -0

similarity index 100%
rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
rename to package/libtool/libtool-0001-mips64-n64-linking.patch

package/libtool/libtool.mk +0 ~~-13~~

index 603f1f1..2f6ea7c 100644
@@ -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

Peter Korsgaard

2014-03-17 22:08 UTC #1 lore raw

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 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/

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 -0

similarity index 100%
rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
rename to package/libtool/libtool-0001-mips64-n64-linking.patch

package/libtool/libtool.mk +0 ~~-13~~

index 603f1f1..2f6ea7c 100644
@@ -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

Arnout Vandecappelle

2014-03-18 07:46 UTC #2 lore raw

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 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.

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 -0

similarity index 100%
rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
rename to package/libtool/libtool-0001-mips64-n64-linking.patch

package/libtool/libtool.mk +0 ~~-13~~

index 603f1f1..2f6ea7c 100644
@@ -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

Vicente Olivert Riera

author

2014-03-18 10:44 UTC #3 lore raw

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 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.
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,
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 -0

similarity index 100%
rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
rename to package/libtool/libtool-0001-mips64-n64-linking.patch

package/libtool/libtool.mk +0 ~~-14~~

index 603f1f1..2f6ea7c 100644
@@ -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

Vicente Olivert Riera

author

2014-03-18 10:55 UTC #4 lore raw

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 ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified the
changes
Quoted 1 line
made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a. The
problem
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,
Arnout
Quoted 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.patch
Quoted 2 lines
similarity index 100%
rename from
package/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.patch
package/libtool/libtool.mk +0 -1
index 603f1f1..2f6ea7c 100644
@@ -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
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 patch
touches 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 would
create 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 the
patch
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

Arnout Vandecappelle

2014-03-19 07:54 UTC #5 lore raw

PATCH 1/1 libtool: revert a commit which re-introduced an already fixed problem

In reply to Vicente Olivert Riera

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 ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified the
changes
Quoted 1 line
made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a. The
problem
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

Vicente Olivert Riera

author

2014-03-19 09:40 UTC #6 lore raw

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 ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified the
changes
Quoted 1 line
made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a. The
problem
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

Arnout Vandecappelle

2014-03-19 13:50 UTC #7 lore raw

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 ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified the
changes
Quoted 1 line
made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a. The
problem
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

Vicente Olivert Riera

author

2014-03-19 14:41 UTC #8 lore raw

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 ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified the
changes
Quoted 1 line
made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a. The
problem
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

Arnout Vandecappelle

2014-03-19 15:02 UTC #9 lore raw

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 ed73d1d2e3703290e74bb076bc6dd0417aa3ba21 modified
the
changes
Quoted 1 line
made by the commit 4268d3967e2d691c151d6b5629e4051deb077b9a.
The
problem
Quoted 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_LIBTOOL and BR2_PACKAGE_LIBISCSI you 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

Vicente Olivert Riera

author

2014-03-19 15:07 UTC #10 lore raw

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_LIBTOOL and BR2_PACKAGE_LIBISCSI you 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,
Arnout
Quoted 10 lines
Quoted 8 lines
Patch follows.
Regards,
Arnout

Signature · 1 line

Vincent

Arnout Vandecappelle

2014-03-19 16:23 UTC #11 lore raw

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_LIBTOOL and BR2_PACKAGE_LIBISCSI you 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