[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Vicente Olivert Riera]

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 <Vincent.Riera@imgtec.com>
---
 ...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%)

diff --git a/package/libtool/libtool-mips64-n64-linking.post-install-patch b/package/libtool/libtool-0001-mips64-n64-linking.patch
similarity index 100%
rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
rename to package/libtool/libtool-0001-mips64-n64-linking.patch
diff --git a/package/libtool/libtool.mk b/package/libtool/libtool.mk
index 603f1f1..2f6ea7c 100644
--- a/package/libtool/libtool.mk
+++ b/package/libtool/libtool.mk
@@ -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] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Peter Korsgaard]

>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> 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?


 > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
 > ---
 >  ...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%)

 > diff --git a/package/libtool/libtool-mips64-n64-linking.post-install-patch b/package/libtool/libtool-0001-mips64-n64-linking.patch
 > similarity index 100%
 > rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
 > rename to package/libtool/libtool-0001-mips64-n64-linking.patch
 > diff --git a/package/libtool/libtool.mk b/package/libtool/libtool.mk
 > index 603f1f1..2f6ea7c 100644
 > --- a/package/libtool/libtool.mk
 > +++ b/package/libtool/libtool.mk
 > @@ -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


-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Arnout Vandecappelle]

On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> 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?

 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

> 
> 
>  > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>  > ---
>  >  ...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%)
> 
>  > diff --git a/package/libtool/libtool-mips64-n64-linking.post-install-patch b/package/libtool/libtool-0001-mips64-n64-linking.patch
>  > similarity index 100%
>  > rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
>  > rename to package/libtool/libtool-0001-mips64-n64-linking.patch
>  > diff --git a/package/libtool/libtool.mk b/package/libtool/libtool.mk
>  > index 603f1f1..2f6ea7c 100644
>  > --- a/package/libtool/libtool.mk
>  > +++ b/package/libtool/libtool.mk
>  > @@ -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
> 
> 


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

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Vicente Olivert Riera]

On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> 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?
>
>   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])


>   Regards,
>   Arnout
>
>>
>>
>>   > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>   > ---
>>   >  ...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%)
>>
>>   > diff --git a/package/libtool/libtool-mips64-n64-linking.post-install-patch b/package/libtool/libtool-0001-mips64-n64-linking.patch
>>   > similarity index 100%
>>   > rename from package/libtool/libtool-mips64-n64-linking.post-install-patch
>>   > rename to package/libtool/libtool-0001-mips64-n64-linking.patch
>>   > diff --git a/package/libtool/libtool.mk b/package/libtool/libtool.mk
>>   > index 603f1f1..2f6ea7c 100644
>>   > --- a/package/libtool/libtool.mk
>>   > +++ b/package/libtool/libtool.mk
>>   > @@ -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
>>
>>
>
>


-- 
Vincent

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Vicente Olivert Riera]

On 03/18/2014 10:44 AM, Vicente Olivert Riera wrote:
> On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
>> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>>>>>> 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?
>>
>>   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])

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?

>>   Regards,
>>   Arnout
>>
>>>
>>>
>>>   > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>   > ---
>>>   >  ...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%)
>>>
>>>   > diff --git
>>> a/package/libtool/libtool-mips64-n64-linking.post-install-patch
>>> b/package/libtool/libtool-0001-mips64-n64-linking.patch
>>>   > similarity index 100%
>>>   > rename from
>>> package/libtool/libtool-mips64-n64-linking.post-install-patch
>>>   > rename to package/libtool/libtool-0001-mips64-n64-linking.patch
>>>   > diff --git a/package/libtool/libtool.mk b/package/libtool/libtool.mk
>>>   > index 603f1f1..2f6ea7c 100644
>>>   > --- a/package/libtool/libtool.mk
>>>   > +++ b/package/libtool/libtool.mk
>>>   > @@ -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
>>>
>>>
>>
>>
>
>


-- 
Vincent

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Arnout Vandecappelle]

On 03/18/14 11:44, Vicente Olivert Riera wrote:
> On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
>> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>>>>>> 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?
>>
>>   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])

 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]


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

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Vicente Olivert Riera]

On 03/19/2014 07:54 AM, Arnout Vandecappelle wrote:
> On 03/18/14 11:44, Vicente Olivert Riera wrote:
>> On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
>>> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>>>>>>> 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?
>>>
>>>    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])
>
>   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

>   Regards,
>   Arnout
>
>
> [snip]
>
>


-- 
Vincent

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Arnout Vandecappelle]

On 19/03/14 10:40, Vicente Olivert Riera wrote:
> On 03/19/2014 07:54 AM, Arnout Vandecappelle wrote:
>> On 03/18/14 11:44, Vicente Olivert Riera wrote:
>>> On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
>>>> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>>>>>>>> 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?
>>>>
>>>>    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])
>>
>>   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/

 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


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

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Vicente Olivert Riera]

On 03/19/2014 01:50 PM, Arnout Vandecappelle wrote:
> On 19/03/14 10:40, Vicente Olivert Riera wrote:
>> On 03/19/2014 07:54 AM, Arnout Vandecappelle wrote:
>>> On 03/18/14 11:44, Vicente Olivert Riera wrote:
>>>> On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
>>>>> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>>>>>>>>> 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?
>>>>>
>>>>>     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])
>>>
>>>    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/
>
>   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?


>   Patch follows.
>
>   Regards,
>   Arnout
>
>


-- 
Vincent

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Arnout Vandecappelle]

On 19/03/14 15:41, Vicente Olivert Riera wrote:
> On 03/19/2014 01:50 PM, Arnout Vandecappelle wrote:
>> On 19/03/14 10:40, Vicente Olivert Riera wrote:
>>> On 03/19/2014 07:54 AM, Arnout Vandecappelle wrote:
>>>> On 03/18/14 11:44, Vicente Olivert Riera wrote:
>>>>> On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
>>>>>> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>>>>>>>>>> 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?
>>>>>>
>>>>>>     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])
>>>>
>>>>    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/
>>>
>>
>>   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

> 
> 
>>   Patch follows.
>>
>>   Regards,
>>   Arnout
>>
>>
> 
> 


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

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Vicente Olivert Riera]

On 03/19/2014 03:02 PM, Arnout Vandecappelle wrote:
> On 19/03/14 15:41, Vicente Olivert Riera wrote:
>> On 03/19/2014 01:50 PM, Arnout Vandecappelle wrote:
>>> On 19/03/14 10:40, Vicente Olivert Riera wrote:
>>>> On 03/19/2014 07:54 AM, Arnout Vandecappelle wrote:
>>>>> On 03/18/14 11:44, Vicente Olivert Riera wrote:
>>>>>> On 03/18/2014 07:46 AM, Arnout Vandecappelle wrote:
>>>>>>> On 03/17/14 23:08, Peter Korsgaard wrote:
>>>>>>>>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>>>>>>>>>>>>> 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?
>>>>>>>
>>>>>>>      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])
>>>>>
>>>>>     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/
>>>>
>>>
>>>    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,

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

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

>   Regards,
>   Arnout
>
>>
>>
>>>    Patch follows.
>>>
>>>    Regards,
>>>    Arnout
>>>
>>>
>>
>>
>
>


-- 
Vincent

[Buildroot] [PATCH] libtool: revert a commit which re-introduced an already fixed problem

[Arnout Vandecappelle]

On 19/03/14 16:07, Vicente Olivert Riera wrote:
> On 03/19/2014 03:02 PM, Arnout Vandecappelle wrote:
>> On 19/03/14 15:41, Vicente Olivert Riera wrote:
>>> On 03/19/2014 01:50 PM, Arnout Vandecappelle wrote:
[snip]
>>>>    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.
> 
> 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.


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



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