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