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

[Vicente Olivert Riera <Vincent.Riera@imgtec.com>]

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