Fix in ACPICA tools broke cross compilation of tools/power/acpi

Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

Hi!

Reverting of the commit e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h>
inclusion order issue") fixes the following issue:

  DESCEND  power/acpi
  DESCEND  tools/acpidbg
output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
-I../../../include -I../../../drivers/acpi/acpica -Wall
-Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
-DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
-I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
acpidbg.o acpidbg.c
In file included from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
                 from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
                 from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
                 from ../../../../../include/acpi/platform/acenv.h:365,
                 from ../../../../../include/acpi/acpi.h:56,
                 from acpidbg.c:12:
../../../../../include/linux/types.h:14:26: error: conflicting types
for ‘fd_set’
 typedef __kernel_fd_set  fd_set;
                          ^
In file included from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/types.h:219:0,
                 from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/stdlib.h:198,
                 from ../../../../../include/acpi/platform/acenv.h:357,
                 from ../../../../../include/acpi/acpi.h:56,
                 from acpidbg.c:12:
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/select.h:77:5:
note: previous declaration of ‘fd_set’ was here
   } fd_set;
     ^
In file included from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
                 from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
                 from
output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
                 from ../../../../../include/acpi/platform/acenv.h:365,
                 from ../../../../../include/acpi/acpi.h:56,
                 from acpidbg.c:12:
../../../../../include/linux/types.h:15:25: error: conflicting types for ‘dev_t’
 typedef __kernel_dev_t  dev_t;

And so on...

After revert:

  DESCEND  power/acpi
  DESCEND  tools/acpidbg
output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
-I../../../include -I../../../drivers/acpi/acpica -Wall
-Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
-DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
-I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
acpidbg.o acpidbg.c
  LD       test-topic/acpidbg
/usr/bin/install -c -d output/target/usr/sbin
/usr/bin/install -c test-topic/acpidbg output/target/usr/sbin

Any ideas how to fix this properly?

-- 
With Best Regards,
Andy Shevchenko

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi,

Please try this patch:
https://patchwork.kernel.org/patch/9392155/
Which makes tools/power/acpi build more robust to survive toolchains that are not generated from the current kernel header.

Thanks
Lv

> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Subject: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> Hi!
> 
> Reverting of the commit e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h>
> inclusion order issue") fixes the following issue:
> 
>   DESCEND  power/acpi
>   DESCEND  tools/acpidbg
> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> -I../../../include -I../../../drivers/acpi/acpica -Wall
> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> acpidbg.o acpidbg.c
> In file included from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
>                  from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
>                  from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
>                  from ../../../../../include/acpi/platform/acenv.h:365,
>                  from ../../../../../include/acpi/acpi.h:56,
>                  from acpidbg.c:12:
> ../../../../../include/linux/types.h:14:26: error: conflicting types
> for ‘fd_set’
>  typedef __kernel_fd_set  fd_set;
>                           ^
> In file included from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/types.h:219:0,
>                  from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/stdlib.h:198,
>                  from ../../../../../include/acpi/platform/acenv.h:357,
>                  from ../../../../../include/acpi/acpi.h:56,
>                  from acpidbg.c:12:
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/select.h:77:5:
> note: previous declaration of ‘fd_set’ was here
>    } fd_set;
>      ^
> In file included from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
>                  from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
>                  from
> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
>                  from ../../../../../include/acpi/platform/acenv.h:365,
>                  from ../../../../../include/acpi/acpi.h:56,
>                  from acpidbg.c:12:
> ../../../../../include/linux/types.h:15:25: error: conflicting types for ‘dev_t’
>  typedef __kernel_dev_t  dev_t;
> 
> And so on...
> 
> After revert:
> 
>   DESCEND  power/acpi
>   DESCEND  tools/acpidbg
> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> -I../../../include -I../../../drivers/acpi/acpica -Wall
> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> acpidbg.o acpidbg.c
>   LD       test-topic/acpidbg
> /usr/bin/install -c -d output/target/usr/sbin
> /usr/bin/install -c test-topic/acpidbg output/target/usr/sbin
> 
> Any ideas how to fix this properly?
> 
> --
> With Best Regards,
> Andy Shevchenko

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Sat, Oct 29, 2016 at 3:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi,
>
> Please try this patch:
> https://patchwork.kernel.org/patch/9392155/
> Which makes tools/power/acpi build more robust to survive toolchains that are not generated from the current kernel header.


Better, but no, it doesn't fully fix the issue.

 DESCEND  power/acpi
 DESCEND  tools/acpidbg
output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
-I../../../include -I..
/../../drivers/acpi/acpica -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -O1 -g -DDEBUG -DACPI_APPLICATI
ON -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
-I../../../../../drivers/acpi/acpica -I../../include   -c -o acpidbg.o
acpidbg.c
acpidbg.c:12:23: fatal error: acpi/acpi.h: No such file or directory
#include <acpi/acpi.h>
                      ^
compilation terminated.
<builtin>: recipe for target 'acpidbg.o' failed



>
> Thanks
> Lv
>
>> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
>> Subject: Fix in ACPICA tools broke cross compilation of tools/power/acpi
>>
>> Hi!
>>
>> Reverting of the commit e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h>
>> inclusion order issue") fixes the following issue:
>>
>>   DESCEND  power/acpi
>>   DESCEND  tools/acpidbg
>> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
>> -I../../../include -I../../../drivers/acpi/acpica -Wall
>> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
>> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
>> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
>> acpidbg.o acpidbg.c
>> In file included from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
>>                  from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
>>                  from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
>>                  from ../../../../../include/acpi/platform/acenv.h:365,
>>                  from ../../../../../include/acpi/acpi.h:56,
>>                  from acpidbg.c:12:
>> ../../../../../include/linux/types.h:14:26: error: conflicting types
>> for ‘fd_set’
>>  typedef __kernel_fd_set  fd_set;
>>                           ^
>> In file included from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/types.h:219:0,
>>                  from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/stdlib.h:198,
>>                  from ../../../../../include/acpi/platform/acenv.h:357,
>>                  from ../../../../../include/acpi/acpi.h:56,
>>                  from acpidbg.c:12:
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/select.h:77:5:
>> note: previous declaration of ‘fd_set’ was here
>>    } fd_set;
>>      ^
>> In file included from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
>>                  from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
>>                  from
>> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
>>                  from ../../../../../include/acpi/platform/acenv.h:365,
>>                  from ../../../../../include/acpi/acpi.h:56,
>>                  from acpidbg.c:12:
>> ../../../../../include/linux/types.h:15:25: error: conflicting types for ‘dev_t’
>>  typedef __kernel_dev_t  dev_t;
>>
>> And so on...
>>
>> After revert:
>>
>>   DESCEND  power/acpi
>>   DESCEND  tools/acpidbg
>> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
>> -I../../../include -I../../../drivers/acpi/acpica -Wall
>> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
>> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
>> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
>> acpidbg.o acpidbg.c
>>   LD       test-topic/acpidbg
>> /usr/bin/install -c -d output/target/usr/sbin
>> /usr/bin/install -c test-topic/acpidbg output/target/usr/sbin
>>
>> Any ideas how to fix this properly?
>>
>> --
>> With Best Regards,
>> Andy Shevchenko



-- 
With Best Regards,
Andy Shevchenko

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, 

> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Sat, Oct 29, 2016 at 3:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> > Hi,
> >
> > Please try this patch:
> > https://patchwork.kernel.org/patch/9392155/
> > Which makes tools/power/acpi build more robust to survive toolchains that are not generated from the
> current kernel header.
> 
> 
> Better, but no, it doesn't fully fix the issue.
> 
>  DESCEND  power/acpi
>  DESCEND  tools/acpidbg
> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> -I../../../include -I..
> /../../drivers/acpi/acpica -Wall -Wstrict-prototypes
> -Wdeclaration-after-statement -O1 -g -DDEBUG -DACPI_APPLICATI
> ON -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> -I../../../../../drivers/acpi/acpica -I../../include   -c -o acpidbg.o
> acpidbg.c
> acpidbg.c:12:23: fatal error: acpi/acpi.h: No such file or directory
> #include <acpi/acpi.h>
>                       ^
> compilation terminated.
> <builtin>: recipe for target 'acpidbg.o' failed

If you mean this line is not correct:
+	ln -s ../../../../include/acpi include/acpi
I'll try to improve it.

Thanks
Lv

> 
> 
> 
> >
> > Thanks
> > Lv
> >
> >> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> >> Subject: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> >>
> >> Hi!
> >>
> >> Reverting of the commit e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h>
> >> inclusion order issue") fixes the following issue:
> >>
> >>   DESCEND  power/acpi
> >>   DESCEND  tools/acpidbg
> >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> >> -I../../../include -I../../../drivers/acpi/acpica -Wall
> >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> >> acpidbg.o acpidbg.c
> >> In file included from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
> >>                  from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
> >>                  from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
> >>                  from ../../../../../include/acpi/platform/acenv.h:365,
> >>                  from ../../../../../include/acpi/acpi.h:56,
> >>                  from acpidbg.c:12:
> >> ../../../../../include/linux/types.h:14:26: error: conflicting types
> >> for ‘fd_set’
> >>  typedef __kernel_fd_set  fd_set;
> >>                           ^
> >> In file included from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/types.h:219:0,
> >>                  from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/stdlib.h:198,
> >>                  from ../../../../../include/acpi/platform/acenv.h:357,
> >>                  from ../../../../../include/acpi/acpi.h:56,
> >>                  from acpidbg.c:12:
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/select.h:77:5:
> >> note: previous declaration of ‘fd_set’ was here
> >>    } fd_set;
> >>      ^
> >> In file included from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
> >>                  from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
> >>                  from
> >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
> >>                  from ../../../../../include/acpi/platform/acenv.h:365,
> >>                  from ../../../../../include/acpi/acpi.h:56,
> >>                  from acpidbg.c:12:
> >> ../../../../../include/linux/types.h:15:25: error: conflicting types for ‘dev_t’
> >>  typedef __kernel_dev_t  dev_t;
> >>
> >> And so on...
> >>
> >> After revert:
> >>
> >>   DESCEND  power/acpi
> >>   DESCEND  tools/acpidbg
> >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> >> -I../../../include -I../../../drivers/acpi/acpica -Wall
> >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> >> acpidbg.o acpidbg.c
> >>   LD       test-topic/acpidbg
> >> /usr/bin/install -c -d output/target/usr/sbin
> >> /usr/bin/install -c test-topic/acpidbg output/target/usr/sbin
> >>
> >> Any ideas how to fix this properly?
> >>
> >> --
> >> With Best Regards,
> >> Andy Shevchenko
> 
> 
> 
> --
> With Best Regards,
> Andy Shevchenko

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, Andy

> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Zheng,
> Lv
> Subject: RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> Hi,
> 
> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> >
> > On Sat, Oct 29, 2016 at 3:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> > > Hi,
> > >
> > > Please try this patch:
> > > https://patchwork.kernel.org/patch/9392155/
> > > Which makes tools/power/acpi build more robust to survive toolchains that are not generated from
> the
> > current kernel header.
> >
> >
> > Better, but no, it doesn't fully fix the issue.
> >
> >  DESCEND  power/acpi
> >  DESCEND  tools/acpidbg
> > output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> > -I../../../include -I..
> > /../../drivers/acpi/acpica -Wall -Wstrict-prototypes
> > -Wdeclaration-after-statement -O1 -g -DDEBUG -DACPI_APPLICATI
> > ON -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> > -I../../../../../drivers/acpi/acpica -I../../include   -c -o acpidbg.o
> > acpidbg.c
> > acpidbg.c:12:23: fatal error: acpi/acpi.h: No such file or directory
> > #include <acpi/acpi.h>
> >                       ^

How did you trigger this?
I just tried to cross compile all tools, similar failures can be seen on many other tools.

Could you stay in the kernel srctree, and
# cd tools
# make ARCH=your_arch CROSS_COMPILE=your_compiler-prefix acpi_clean
# make ARCH=your_arch CROSS_COMPILE=your_compiler-prefix acpi
# ls power/acpi/include/acpi

What will be shown then?

Thanks and best regards
Lv

> > compilation terminated.
> > <builtin>: recipe for target 'acpidbg.o' failed
> 
> If you mean this line is not correct:
> +	ln -s ../../../../include/acpi include/acpi
> I'll try to improve it.
> 
> Thanks
> Lv
> 
> >
> >
> >
> > >
> > > Thanks
> > > Lv
> > >
> > >> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > >> Subject: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> > >>
> > >> Hi!
> > >>
> > >> Reverting of the commit e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h>
> > >> inclusion order issue") fixes the following issue:
> > >>
> > >>   DESCEND  power/acpi
> > >>   DESCEND  tools/acpidbg
> > >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> > >> -I../../../include -I../../../drivers/acpi/acpica -Wall
> > >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> > >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> > >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> > >> acpidbg.o acpidbg.c
> > >> In file included from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
> > >>                  from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
> > >>                  from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
> > >>                  from ../../../../../include/acpi/platform/acenv.h:365,
> > >>                  from ../../../../../include/acpi/acpi.h:56,
> > >>                  from acpidbg.c:12:
> > >> ../../../../../include/linux/types.h:14:26: error: conflicting types
> > >> for ‘fd_set’
> > >>  typedef __kernel_fd_set  fd_set;
> > >>                           ^
> > >> In file included from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/types.h:219:0,
> > >>                  from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/stdlib.h:198,
> > >>                  from ../../../../../include/acpi/platform/acenv.h:357,
> > >>                  from ../../../../../include/acpi/acpi.h:56,
> > >>                  from acpidbg.c:12:
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/select.h:77:5:
> > >> note: previous declaration of ‘fd_set’ was here
> > >>    } fd_set;
> > >>      ^
> > >> In file included from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
> > >>                  from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
> > >>                  from
> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
> > >>                  from ../../../../../include/acpi/platform/acenv.h:365,
> > >>                  from ../../../../../include/acpi/acpi.h:56,
> > >>                  from acpidbg.c:12:
> > >> ../../../../../include/linux/types.h:15:25: error: conflicting types for ‘dev_t’
> > >>  typedef __kernel_dev_t  dev_t;
> > >>
> > >> And so on...
> > >>
> > >> After revert:
> > >>
> > >>   DESCEND  power/acpi
> > >>   DESCEND  tools/acpidbg
> > >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> > >> -I../../../include -I../../../drivers/acpi/acpica -Wall
> > >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> > >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> > >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> > >> acpidbg.o acpidbg.c
> > >>   LD       test-topic/acpidbg
> > >> /usr/bin/install -c -d output/target/usr/sbin
> > >> /usr/bin/install -c test-topic/acpidbg output/target/usr/sbin
> > >>
> > >> Any ideas how to fix this properly?
> > >>
> > >> --
> > >> With Best Regards,
> > >> Andy Shevchenko
> >
> >
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> \x13��칻\x1c�&�~�&�\x18��+-��ݶ\x17��w��˛���m�b��Zr����^n�r���z�\x1a��h����&��\x1e�G���h�\x03(�階
> �ݢj"��\x1a�^[m�����z�ޖ���f���h���~�m�

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Sun, Oct 30, 2016 at 9:04 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi, Andy
>
>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Zheng,
>> Lv
>> Subject: RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi
>>
>> Hi,
>>
>> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
>> > Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
>> >
>> > On Sat, Oct 29, 2016 at 3:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
>> > > Hi,
>> > >
>> > > Please try this patch:
>> > > https://patchwork.kernel.org/patch/9392155/
>> > > Which makes tools/power/acpi build more robust to survive toolchains that are not generated from
>> the
>> > current kernel header.
>> >
>> >
>> > Better, but no, it doesn't fully fix the issue.
>> >
>> >  DESCEND  power/acpi
>> >  DESCEND  tools/acpidbg
>> > output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
>> > -I../../../include -I..
>> > /../../drivers/acpi/acpica -Wall -Wstrict-prototypes
>> > -Wdeclaration-after-statement -O1 -g -DDEBUG -DACPI_APPLICATI
>> > ON -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
>> > -I../../../../../drivers/acpi/acpica -I../../include   -c -o acpidbg.o
>> > acpidbg.c
>> > acpidbg.c:12:23: fatal error: acpi/acpi.h: No such file or directory
>> > #include <acpi/acpi.h>
>> >                       ^
>
> How did you trigger this?

I'm compiling it as a package in Buildroot environment which uses
uClibc and cross compiler.

> I just tried to cross compile all tools, similar failures can be seen on many other tools.
>
> Could you stay in the kernel srctree, and

I'm afraid I can't do exactly this one. I'm using make
O=/path/to/kernel/build. But I will try to look what I have there.

> # cd tools
> # make ARCH=your_arch CROSS_COMPILE=your_compiler-prefix acpi_clean
> # make ARCH=your_arch CROSS_COMPILE=your_compiler-prefix acpi
> # ls power/acpi/include/acpi
>
> What will be shown then?

$ ls -l tools/power/acpi/
total 4
drwxr-xr-x 3 andy andy 4096 Oct 29 19:03 tools

There is no include folder.

>
> Thanks and best regards
> Lv
>
>> > compilation terminated.
>> > <builtin>: recipe for target 'acpidbg.o' failed
>>
>> If you mean this line is not correct:
>> +     ln -s ../../../../include/acpi include/acpi
>> I'll try to improve it.
>>
>> Thanks
>> Lv
>>
>> >
>> >
>> >
>> > >
>> > > Thanks
>> > > Lv
>> > >
>> > >> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
>> > >> Subject: Fix in ACPICA tools broke cross compilation of tools/power/acpi
>> > >>
>> > >> Hi!
>> > >>
>> > >> Reverting of the commit e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h>
>> > >> inclusion order issue") fixes the following issue:
>> > >>
>> > >>   DESCEND  power/acpi
>> > >>   DESCEND  tools/acpidbg
>> > >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
>> > >> -I../../../include -I../../../drivers/acpi/acpica -Wall
>> > >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
>> > >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
>> > >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
>> > >> acpidbg.o acpidbg.c
>> > >> In file included from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
>> > >>                  from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
>> > >>                  from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
>> > >>                  from ../../../../../include/acpi/platform/acenv.h:365,
>> > >>                  from ../../../../../include/acpi/acpi.h:56,
>> > >>                  from acpidbg.c:12:
>> > >> ../../../../../include/linux/types.h:14:26: error: conflicting types
>> > >> for ‘fd_set’
>> > >>  typedef __kernel_fd_set  fd_set;
>> > >>                           ^
>> > >> In file included from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/types.h:219:0,
>> > >>                  from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/stdlib.h:198,
>> > >>                  from ../../../../../include/acpi/platform/acenv.h:357,
>> > >>                  from ../../../../../include/acpi/acpi.h:56,
>> > >>                  from acpidbg.c:12:
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/select.h:77:5:
>> > >> note: previous declaration of ‘fd_set’ was here
>> > >>    } fd_set;
>> > >>      ^
>> > >> In file included from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
>> > >>                  from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
>> > >>                  from
>> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
>> > >>                  from ../../../../../include/acpi/platform/acenv.h:365,
>> > >>                  from ../../../../../include/acpi/acpi.h:56,
>> > >>                  from acpidbg.c:12:
>> > >> ../../../../../include/linux/types.h:15:25: error: conflicting types for ‘dev_t’
>> > >>  typedef __kernel_dev_t  dev_t;
>> > >>
>> > >> And so on...
>> > >>
>> > >> After revert:
>> > >>
>> > >>   DESCEND  power/acpi
>> > >>   DESCEND  tools/acpidbg
>> > >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
>> > >> -I../../../include -I../../../drivers/acpi/acpica -Wall
>> > >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
>> > >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
>> > >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
>> > >> acpidbg.o acpidbg.c
>> > >>   LD       test-topic/acpidbg
>> > >> /usr/bin/install -c -d output/target/usr/sbin
>> > >> /usr/bin/install -c test-topic/acpidbg output/target/usr/sbin
>> > >>
>> > >> Any ideas how to fix this properly?
>> > >>
>> > >> --
>> > >> With Best Regards,
>> > >> Andy Shevchenko
>> >
>> >
>> >
>> > --
>> > With Best Regards,
>> > Andy Shevchenko
>>  ��칻 �&�~�&� ��+-��ݶ ��w��˛���m�b��Zr����^n�r���z� ��h����&�� �G���h� (�階
>> �ݢj"�� � m�����z�ޖ���f���h���~�m�



-- 
With Best Regards,
Andy Shevchenko

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi,

> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Sun, Oct 30, 2016 at 9:04 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> > Hi, Andy
> >
> >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Zheng,
> >> Lv
> >> Subject: RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> >>
> >> Hi,
> >>
> >> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> >> > Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> >> >
> >> > On Sat, Oct 29, 2016 at 3:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> >> > > Hi,
> >> > >
> >> > > Please try this patch:
> >> > > https://patchwork.kernel.org/patch/9392155/
> >> > > Which makes tools/power/acpi build more robust to survive toolchains that are not generated
> from
> >> the
> >> > current kernel header.
> >> >
> >> >
> >> > Better, but no, it doesn't fully fix the issue.
> >> >
> >> >  DESCEND  power/acpi
> >> >  DESCEND  tools/acpidbg
> >> > output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> >> > -I../../../include -I..
> >> > /../../drivers/acpi/acpica -Wall -Wstrict-prototypes
> >> > -Wdeclaration-after-statement -O1 -g -DDEBUG -DACPI_APPLICATI
> >> > ON -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> >> > -I../../../../../drivers/acpi/acpica -I../../include   -c -o acpidbg.o
> >> > acpidbg.c
> >> > acpidbg.c:12:23: fatal error: acpi/acpi.h: No such file or directory
> >> > #include <acpi/acpi.h>
> >> >                       ^
> >
> > How did you trigger this?
> 
> I'm compiling it as a package in Buildroot environment which uses
> uClibc and cross compiler.

BuildRoot may have strange steps messing up $srctree.

> 
> > I just tried to cross compile all tools, similar failures can be seen on many other tools.
> >
> > Could you stay in the kernel srctree, and
> 
> I'm afraid I can't do exactly this one. I'm using make
> O=/path/to/kernel/build. But I will try to look what I have there.

I still don't know how it is broken there.
As the new include link is only in $srctree, not in $objtree.

However, I'll revise the change, moving the new include folder to objtree.
You can try the next revision.

Thanks and best regards
Lv

> 
> > # cd tools
> > # make ARCH=your_arch CROSS_COMPILE=your_compiler-prefix acpi_clean
> > # make ARCH=your_arch CROSS_COMPILE=your_compiler-prefix acpi
> > # ls power/acpi/include/acpi
> >
> > What will be shown then?
> 
> $ ls -l tools/power/acpi/
> total 4
> drwxr-xr-x 3 andy andy 4096 Oct 29 19:03 tools
> 
> There is no include folder.
> 
> >
> > Thanks and best regards
> > Lv
> >
> >> > compilation terminated.
> >> > <builtin>: recipe for target 'acpidbg.o' failed
> >>
> >> If you mean this line is not correct:
> >> +     ln -s ../../../../include/acpi include/acpi
> >> I'll try to improve it.
> >>
> >> Thanks
> >> Lv
> >>
> >> >
> >> >
> >> >
> >> > >
> >> > > Thanks
> >> > > Lv
> >> > >
> >> > >> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> >> > >> Subject: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> >> > >>
> >> > >> Hi!
> >> > >>
> >> > >> Reverting of the commit e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h>
> >> > >> inclusion order issue") fixes the following issue:
> >> > >>
> >> > >>   DESCEND  power/acpi
> >> > >>   DESCEND  tools/acpidbg
> >> > >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> >> > >> -I../../../include -I../../../drivers/acpi/acpica -Wall
> >> > >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> >> > >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> >> > >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> >> > >> acpidbg.o acpidbg.c
> >> > >> In file included from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
> >> > >>                  from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
> >> > >>                  from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
> >> > >>                  from ../../../../../include/acpi/platform/acenv.h:365,
> >> > >>                  from ../../../../../include/acpi/acpi.h:56,
> >> > >>                  from acpidbg.c:12:
> >> > >> ../../../../../include/linux/types.h:14:26: error: conflicting types
> >> > >> for ‘fd_set’
> >> > >>  typedef __kernel_fd_set  fd_set;
> >> > >>                           ^
> >> > >> In file included from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/types.h:219:0,
> >> > >>                  from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/stdlib.h:198,
> >> > >>                  from ../../../../../include/acpi/platform/acenv.h:357,
> >> > >>                  from ../../../../../include/acpi/acpi.h:56,
> >> > >>                  from acpidbg.c:12:
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/sys/select.h:77:5:
> >> > >> note: previous declaration of ‘fd_set’ was here
> >> > >>    } fd_set;
> >> > >>      ^
> >> > >> In file included from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/asm/sigcontext.h:18:0,
> >> > >>                  from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/bits/sigcontext.h:30,
> >> > >>                  from
> >> > >> output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/signal.h:335,
> >> > >>                  from ../../../../../include/acpi/platform/acenv.h:365,
> >> > >>                  from ../../../../../include/acpi/acpi.h:56,
> >> > >>                  from acpidbg.c:12:
> >> > >> ../../../../../include/linux/types.h:15:25: error: conflicting types for ‘dev_t’
> >> > >>  typedef __kernel_dev_t  dev_t;
> >> > >>
> >> > >> And so on...
> >> > >>
> >> > >> After revert:
> >> > >>
> >> > >>   DESCEND  power/acpi
> >> > >>   DESCEND  tools/acpidbg
> >> > >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
> >> > >> -I../../../include -I../../../drivers/acpi/acpica -Wall
> >> > >> -Wstrict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> >> > >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
> >> > >> -I../../../../../drivers/acpi/acpica -I../../../../../include   -c -o
> >> > >> acpidbg.o acpidbg.c
> >> > >>   LD       test-topic/acpidbg
> >> > >> /usr/bin/install -c -d output/target/usr/sbin
> >> > >> /usr/bin/install -c test-topic/acpidbg output/target/usr/sbin
> >> > >>
> >> > >> Any ideas how to fix this properly?
> >> > >>
> >> > >> --
> >> > >> With Best Regards,
> >> > >> Andy Shevchenko
> >> >
> >> >
> >> >
> >> > --
> >> > With Best Regards,
> >> > Andy Shevchenko
> >>  ��칻 �&�~�&� ��+-��ݶ ��w��˛���m�b��Zr����^n�r���z� ��h����&�� �G���h� (�階
> >> �ݢj"�� � m�����z�ޖ���f���h���~�m�
> 
> 
> 
> --
> With Best Regards,
> Andy Shevchenko

[PATCH v3] tools/power/acpi: Remove direct kernel source include reference

[Lv Zheng]

ACPICA tools trickily uses integer types, and trickily includes kernel
include directory directly, which breaks tools build for some cross
compilers.
This patch improves ACPICA tools build to make it a bit more robust in such
situation by splitting include/acpi into a separate output directory.

This patch also contains OUTPUT/srctree cleanups in order to make above fix
working for various build environments.

Fixes: e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h> inclusion order issue")
Reported-and-tested-by: Yisheng Xie <xieyisheng1@huawei.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 include/acpi/platform/aclinux.h          |  3 +++
 tools/power/acpi/Makefile.config         | 21 +++++++++--------
 tools/power/acpi/Makefile.rules          | 40 +++++++++++++++++++++-----------
 tools/power/acpi/tools/acpidbg/Makefile  |  4 +---
 tools/power/acpi/tools/acpidbg/acpidbg.c |  8 ++++++-
 tools/power/acpi/tools/acpidump/Makefile | 12 +++++-----
 6 files changed, 55 insertions(+), 33 deletions(-)

diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index a5d98d1..e861a24 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -191,6 +191,9 @@
 #ifndef __init
 #define __init
 #endif
+#ifndef __iomem
+#define __iomem
+#endif
 
 /* Host-dependent types and defines for user-space ACPICA */
 
diff --git a/tools/power/acpi/Makefile.config b/tools/power/acpi/Makefile.config
index a538ff4..8320616 100644
--- a/tools/power/acpi/Makefile.config
+++ b/tools/power/acpi/Makefile.config
@@ -8,18 +8,19 @@
 # as published by the Free Software Foundation; version 2
 # of the License.
 
-include ../../../../scripts/Makefile.include
+ifeq ($(srctree),)
+srctree := $(patsubst %/,%,$(dir $(shell pwd)))
+srctree := $(patsubst %/,%,$(dir $(srctree)))
+#$(info Determined 'srctree' to be $(srctree))
+endif
+
+include $(srctree)/../../scripts/Makefile.include
 
-OUTPUT=./
+OUTPUT=$(srctree)/
 ifeq ("$(origin O)", "command line")
 	OUTPUT := $(O)/
 endif
-
-ifneq ($(OUTPUT),)
-# check that the output directory actually exists
-OUTDIR := $(shell cd $(OUTPUT) && /bin/pwd)
-$(if $(OUTDIR),, $(error output directory "$(OUTPUT)" does not exist))
-endif
+##$(info Determined 'OUTPUT' to be $(OUTPUT))
 
 # --- CONFIGURATION BEGIN ---
 
@@ -70,8 +71,8 @@ WARNINGS := -Wall
 WARNINGS += $(call cc-supports,-Wstrict-prototypes)
 WARNINGS += $(call cc-supports,-Wdeclaration-after-statement)
 
-KERNEL_INCLUDE := ../../../include
-ACPICA_INCLUDE := ../../../drivers/acpi/acpica
+KERNEL_INCLUDE := $(OUTPUT)include
+ACPICA_INCLUDE := $(srctree)/../../../drivers/acpi/acpica
 CFLAGS += -D_LINUX -I$(KERNEL_INCLUDE) -I$(ACPICA_INCLUDE)
 CFLAGS += $(WARNINGS)
 
diff --git a/tools/power/acpi/Makefile.rules b/tools/power/acpi/Makefile.rules
index ec87a9e..51070de 100644
--- a/tools/power/acpi/Makefile.rules
+++ b/tools/power/acpi/Makefile.rules
@@ -8,28 +8,42 @@
 # as published by the Free Software Foundation; version 2
 # of the License.
 
-$(OUTPUT)$(TOOL): $(TOOL_OBJS) FORCE
-	$(ECHO) "  LD      " $@
-	$(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(TOOL_OBJS) -L$(OUTPUT) -o $@
+objdir := $(OUTPUT)tools/$(TOOL)/
+toolobjs := $(addprefix $(objdir),$(TOOL_OBJS))
+$(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
+	$(ECHO) "  LD      " $(subst $(OUTPUT),,$@)
+	$(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(toolobjs) -L$(OUTPUT) -o $@
+	$(ECHO) "  STRIP   " $(subst $(OUTPUT),,$@)
 	$(QUIET) $(STRIPCMD) $@
 
-$(OUTPUT)%.o: %.c
-	$(ECHO) "  CC      " $@
+$(KERNEL_INCLUDE):
+	$(ECHO) "  MKDIR   " $(subst $(OUTPUT),,$@)
+	$(QUIET) mkdir -p $(KERNEL_INCLUDE)
+	$(ECHO) "  CP      " $(subst $(OUTPUT),,$@)
+	$(QUIET) cp -rf $(srctree)/../../../include/acpi $(KERNEL_INCLUDE)/
+
+$(objdir)%.o: %.c
+	$(ECHO) "  CC      " $(subst $(OUTPUT),,$@)
 	$(QUIET) $(CC) -c $(CFLAGS) -o $@ $<
 
 all: $(OUTPUT)$(TOOL)
 clean:
-	-find $(OUTPUT) \( -not -type d \) \
-	-and \( -name '*~' -o -name '*.[oas]' \) \
-	-type f -print \
-	 | xargs rm -f
-	-rm -f $(OUTPUT)$(TOOL)
+	$(ECHO) "  RMOBJ   " $(subst $(OUTPUT),,$(objdir))
+	$(QUIET) find $(objdir) \( -not -type d \)\
+		 -and \( -name '*~' -o -name '*.[oas]' \)\
+		 -type f -print | xargs rm -f
+	$(ECHO) "  RM      " $(TOOL)
+	$(QUIET) rm -f $(OUTPUT)$(TOOL)
+	$(ECHO) "  RMINC   " $(subst $(OUTPUT),,$(KERNEL_INCLUDE))
+	$(QUIET) rm -rf $(KERNEL_INCLUDE)
 
 install-tools:
-	$(INSTALL) -d $(DESTDIR)${sbindir}
-	$(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)${sbindir}
+	$(ECHO) "  INST    " $(TOOL)
+	$(QUIET) $(INSTALL) -d $(DESTDIR)$(sbindir)
+	$(QUIET) $(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)$(sbindir)
 uninstall-tools:
-	- rm -f $(DESTDIR)${sbindir}/$(TOOL)
+	$(ECHO) "  UNINST  " $(TOOL)
+	$(QUIET) rm -f $(DESTDIR)$(sbindir)/$(TOOL)
 
 install: all install-tools $(EXTRA_INSTALL)
 uninstall: uninstall-tools $(EXTRA_UNINSTALL)
diff --git a/tools/power/acpi/tools/acpidbg/Makefile b/tools/power/acpi/tools/acpidbg/Makefile
index 352df4b..f2d06e7 100644
--- a/tools/power/acpi/tools/acpidbg/Makefile
+++ b/tools/power/acpi/tools/acpidbg/Makefile
@@ -17,9 +17,7 @@ vpath %.c \
 	../../os_specific/service_layers\
 	.
 CFLAGS += -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER\
-	-I.\
-	-I../../../../../drivers/acpi/acpica\
-	-I../../../../../include
+	-I.
 LDFLAGS += -lpthread
 TOOL_OBJS = \
 	acpidbg.o
diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c b/tools/power/acpi/tools/acpidbg/acpidbg.c
index a88ac45..4308362 100644
--- a/tools/power/acpi/tools/acpidbg/acpidbg.c
+++ b/tools/power/acpi/tools/acpidbg/acpidbg.c
@@ -12,10 +12,16 @@
 #include <acpi/acpi.h>
 
 /* Headers not included by include/acpi/platform/aclinux.h */
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <error.h>
 #include <stdbool.h>
 #include <fcntl.h>
 #include <assert.h>
-#include <linux/circ_buf.h>
+#include <sys/select.h>
+#include "../../../../../include/linux/circ_buf.h"
 
 #define ACPI_AML_FILE		"/sys/kernel/debug/acpi/acpidbg"
 #define ACPI_AML_SEC_TICK	1
diff --git a/tools/power/acpi/tools/acpidump/Makefile b/tools/power/acpi/tools/acpidump/Makefile
index 04b5db7..f7c7af1 100644
--- a/tools/power/acpi/tools/acpidump/Makefile
+++ b/tools/power/acpi/tools/acpidump/Makefile
@@ -19,9 +19,7 @@ vpath %.c \
 	./\
 	../../common\
 	../../os_specific/service_layers
-CFLAGS += -DACPI_DUMP_APP -I.\
-	-I../../../../../drivers/acpi/acpica\
-	-I../../../../../include
+CFLAGS += -DACPI_DUMP_APP -I.
 TOOL_OBJS = \
 	apdump.o\
 	apfiles.o\
@@ -49,7 +47,9 @@ TOOL_OBJS = \
 
 include ../../Makefile.rules
 
-install-man: ../../man/acpidump.8
-	$(INSTALL_DATA) -D $< $(DESTDIR)${mandir}/man8/acpidump.8
+install-man: $(srctree)/man/acpidump.8
+	$(ECHO) "  INST    " acpidump.8
+	$(QUIET) $(INSTALL_DATA) -D $< $(DESTDIR)$(mandir)/man8/acpidump.8
 uninstall-man:
-	- rm -f $(DESTDIR)${mandir}/man8/acpidump.8
+	$(ECHO) "  UNINST  " acpidump.8
+	$(QUIET) rm -f $(DESTDIR)$(mandir)/man8/acpidump.8
-- 
2.7.4

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Thu, Nov 3, 2016 at 5:04 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
>> On Sun, Oct 30, 2016 at 9:04 AM, Zheng, Lv <lv.zheng@intel.com> wrote:

>> >> > > Please try this patch:
>> >> > > https://patchwork.kernel.org/patch/9392155/
>> >> > > Which makes tools/power/acpi build more robust to survive toolchains that are not generated
>> from
>> >> the
>> >> > current kernel header.
>> >> >
>> >> >
>> >> > Better, but no, it doesn't fully fix the issue.
>> >> >
>> >> >  DESCEND  power/acpi
>> >> >  DESCEND  tools/acpidbg
>> >> > output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -D_LINUX
>> >> > -I../../../include -I..
>> >> > /../../drivers/acpi/acpica -Wall -Wstrict-prototypes
>> >> > -Wdeclaration-after-statement -O1 -g -DDEBUG -DACPI_APPLICATI
>> >> > ON -DACPI_SINGLE_THREAD -DACPI_DEBUGGER -I.
>> >> > -I../../../../../drivers/acpi/acpica -I../../include   -c -o acpidbg.o
>> >> > acpidbg.c
>> >> > acpidbg.c:12:23: fatal error: acpi/acpi.h: No such file or directory
>> >> > #include <acpi/acpi.h>
>> >> >                       ^
>> >

The following fixing the above issue...

--- a/tools/power/acpi/Makefile.rules
+++ b/tools/power/acpi/Makefile.rules
@@ -10,13 +10,13 @@

objdir := $(OUTPUT)tools/$(TOOL)/
toolobjs := $(addprefix $(objdir),$(TOOL_OBJS))
-$(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
+$(OUTPUT)$(TOOL): $(KERNEL_INCLUDE)/acpi $(toolobjs) FORCE
       $(ECHO) "  LD      " $(subst $(OUTPUT),,$@)
       $(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(toolobjs) -L$(OUTPUT) -o $@
       $(ECHO) "  STRIP   " $(subst $(OUTPUT),,$@)
       $(QUIET) $(STRIPCMD) $@

-$(KERNEL_INCLUDE):
+$(KERNEL_INCLUDE)/acpi:
       $(ECHO) "  MKDIR   " $(subst $(OUTPUT),,$@)
       $(QUIET) mkdir -p $(KERNEL_INCLUDE)
       $(ECHO) "  CP      " $(subst $(OUTPUT),,$@)


But reveals another, the output path is broken:

output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
$OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
-Wall -Wst
rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
-DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
Assembler messages:
Fatal error: can't create $OUT/tools/acpidbg/acpidbg.o: No such file
or directory
../../Makefile.rules:26: recipe for target '$OUT/tools/acpidbg/acpidbg.o' failed

$OUT — path to O=
$SRC — path to kernel sources

-- 
With Best Regards,
Andy Shevchenko

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Tue, Nov 15, 2016 at 12:27 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 5:04 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
>>> On Sun, Oct 30, 2016 at 9:04 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
>
>>> >> > > Please try this patch:
>>> >> > > https://patchwork.kernel.org/patch/9392155/
>>> >> > > Which makes tools/power/acpi build more robust to survive toolchains that are not generated
>>> from
>>> >> the
>>> >> > current kernel header.

Okay, I did a totally clean build (latest linux-next kernel and
buildroot) without mention patch and still see the issue described
below:

> But reveals another, the output path is broken:
>
> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
> $OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
> -Wall -Wst
> rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
> ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
> Assembler messages:
> Fatal error: can't create $OUT/tools/acpidbg/acpidbg.o: No such file
> or directory
> ../../Makefile.rules:26: recipe for target '$OUT/tools/acpidbg/acpidbg.o' failed
>
> $OUT — path to O=
> $SRC — path to kernel sources

>From latest run

output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
$OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
-Wall -Wst
rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
-DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c

Of course it fails since proper folder name should be
'tools/power/acpi/tools' instead of 'tools'.

-- 
With Best Regards,
Andy Shevchenko

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Tue, Nov 15, 2016 at 4:23 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Nov 15, 2016 at 12:27 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Thu, Nov 3, 2016 at 5:04 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
>>>> On Sun, Oct 30, 2016 at 9:04 AM, Zheng, Lv <lv.zheng@intel.com> wrote:

>> But reveals another, the output path is broken:
>>
>> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
>> $OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
>> -Wall -Wst
>> rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
>> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
>> ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
>> Assembler messages:
>> Fatal error: can't create $OUT/tools/acpidbg/acpidbg.o: No such file
>> or directory
>> ../../Makefile.rules:26: recipe for target '$OUT/tools/acpidbg/acpidbg.o' failed
>>
>> $OUT — path to O=
>> $SRC — path to kernel sources
>
> From latest run
>
> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
> $OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
> -Wall -Wst
> rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
> ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
>
> Of course it fails since proper folder name should be
> 'tools/power/acpi/tools' instead of 'tools'.

The below + several runs (need to serialize makefile, by default it
races install vs. build)  helped eventually.

--- a/tools/power/acpi/Makefile.rules
+++ b/tools/power/acpi/Makefile.rules
@@ -8,9 +8,9 @@
# as published by the Free Software Foundation; version 2
# of the License.

-objdir := $(OUTPUT)tools/$(TOOL)/
+objdir := $(OUTPUT)tools/power/acpi/tools/$(TOOL)/
toolobjs := $(addprefix $(objdir),$(TOOL_OBJS))
-$(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
+$(objdir)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
       $(ECHO) "  LD      " $(subst $(OUTPUT),,$@)
       $(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(toolobjs) -L$(OUTPUT) -o $@
       $(ECHO) "  STRIP   " $(subst $(OUTPUT),,$@)
@@ -26,21 +26,21 @@ $(objdir)%.o: %.c
       $(ECHO) "  CC      " $(subst $(OUTPUT),,$@)
       $(QUIET) $(CC) -c $(CFLAGS) -o $@ $<

-all: $(OUTPUT)$(TOOL)
+all: $(objdir)$(TOOL)
clean:
       $(ECHO) "  RMOBJ   " $(subst $(OUTPUT),,$(objdir))
       $(QUIET) find $(objdir) \( -not -type d \)\
                -and \( -name '*~' -o -name '*.[oas]' \)\
                -type f -print | xargs rm -f
       $(ECHO) "  RM      " $(TOOL)
-       $(QUIET) rm -f $(OUTPUT)$(TOOL)
+       $(QUIET) rm -f $(objdir)$(TOOL)
       $(ECHO) "  RMINC   " $(subst $(OUTPUT),,$(KERNEL_INCLUDE))
       $(QUIET) rm -rf $(KERNEL_INCLUDE)

install-tools:
       $(ECHO) "  INST    " $(TOOL)
       $(QUIET) $(INSTALL) -d $(DESTDIR)$(sbindir)
-       $(QUIET) $(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)$(sbindir)
+       $(QUIET) $(INSTALL_PROGRAM) $(objdir)$(TOOL) $(DESTDIR)$(sbindir)
uninstall-tools:
       $(ECHO) "  UNINST  " $(TOOL)
       $(QUIET) rm -f $(DESTDIR)$(sbindir)/$(TOOL)


-- 
With Best Regards,
Andy Shevchenko

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Tue, Nov 15, 2016 at 5:01 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:

> The below + several runs (need to serialize makefile, by default it
> races install vs. build)  helped eventually.

Isn't better just to revert patch I mention and continue from working case?

-- 
With Best Regards,
Andy Shevchenko

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Rafael J. Wysocki]

On Tue, Nov 15, 2016 at 4:02 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Nov 15, 2016 at 5:01 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>
>> The below + several runs (need to serialize makefile, by default it
>> races install vs. build)  helped eventually.
>
> Isn't better just to revert patch I mention and continue from working case?

Which one is that, I seem to have lost track of it?

Thanks,
Rafael

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, Andy

> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Tue, Nov 15, 2016 at 5:01 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> 
> > The below + several runs (need to serialize makefile, by default it
> > races install vs. build)  helped eventually.
> 
> Isn't better just to revert patch I mention and continue from working case?

It's not possible to revert that patch.
It contains correct header inclusion cleanups.
While this case is in fact a special case, bugs in tools/Makefile are triggered (about OUT/SRC).

OTOH, this case is actually not a very useful case.
We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
We are just to improve it.

Thanks
Lv

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi,

> From: Zheng, Lv
> Subject: RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> Hi, Andy
> 
> > From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> > Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> >
> > On Tue, Nov 15, 2016 at 5:01 PM, Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> >
> > > The below + several runs (need to serialize makefile, by default it
> > > races install vs. build)  helped eventually.
> >
> > Isn't better just to revert patch I mention and continue from working case?
> 
> It's not possible to revert that patch.
> It contains correct header inclusion cleanups.
> While this case is in fact a special case, bugs in tools/Makefile are triggered (about OUT/SRC).
> 
> OTOH, this case is actually not a very useful case.
> We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
> We are just to improve it.

We can clearly see that:
1. the commit is correct, it can cleanly sort the inclusion orders.
2. tools/power/acpi build is still working, just have issues with cross toolchains.
3. the strict inclusion order (signal.h) itself is a bug - because toolchain issue and ACPICA trick.
4. tools/power/acpi makefiles are not handling OUT/SRC correctly.
So why do we need to revert correct thing to support a buggy behavior?
We are just finding a way to make tools/power/acpi build more robust for such a buggy behavior.

Thanks
Lv

[PATCH v4] tools/power/acpi: Remove direct kernel source include reference

[Lv Zheng]

ACPICA tools trickily uses integer types, and trickily includes kernel
include directory directly, which breaks tools build for some cross
compilers.
This patch improves ACPICA tools build to make it a bit more robust in such
situation by splitting include/acpi into a separate output directory.

This patch also contains OUTPUT/srctree cleanups in order to make above fix
working for various build environments.

Fixes: e323c02dee59 ("ACPICA: MSVC9: Fix <sys/stat.h> inclusion order issue")
Reported-and-tested-by: Yisheng Xie <xieyisheng1@huawei.com>
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
---
 include/acpi/platform/aclinux.h          |  3 +++
 tools/power/acpi/Makefile.config         | 23 +++++++++---------
 tools/power/acpi/Makefile.rules          | 40 +++++++++++++++++++++-----------
 tools/power/acpi/tools/acpidbg/Makefile  |  4 +---
 tools/power/acpi/tools/acpidbg/acpidbg.c |  8 ++++++-
 tools/power/acpi/tools/acpidump/Makefile | 12 +++++-----
 6 files changed, 56 insertions(+), 34 deletions(-)

diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index a5d98d1..e861a24 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -191,6 +191,9 @@
 #ifndef __init
 #define __init
 #endif
+#ifndef __iomem
+#define __iomem
+#endif
 
 /* Host-dependent types and defines for user-space ACPICA */
 
diff --git a/tools/power/acpi/Makefile.config b/tools/power/acpi/Makefile.config
index a538ff4..a1883bb 100644
--- a/tools/power/acpi/Makefile.config
+++ b/tools/power/acpi/Makefile.config
@@ -8,18 +8,19 @@
 # as published by the Free Software Foundation; version 2
 # of the License.
 
-include ../../../../scripts/Makefile.include
-
-OUTPUT=./
-ifeq ("$(origin O)", "command line")
-	OUTPUT := $(O)/
+ifeq ($(srctree),)
+srctree := $(patsubst %/,%,$(dir $(shell pwd)))
+srctree := $(patsubst %/,%,$(dir $(srctree)))
+#$(info Determined 'srctree' to be $(srctree))
 endif
 
-ifneq ($(OUTPUT),)
-# check that the output directory actually exists
-OUTDIR := $(shell cd $(OUTPUT) && /bin/pwd)
-$(if $(OUTDIR),, $(error output directory "$(OUTPUT)" does not exist))
+include $(srctree)/../../scripts/Makefile.include
+
+OUTPUT=$(srctree)/
+ifeq ("$(origin O)", "command line")
+	OUTPUT := $(O)/power/acpi/
 endif
+#$(info Determined 'OUTPUT' to be $(OUTPUT))
 
 # --- CONFIGURATION BEGIN ---
 
@@ -70,8 +71,8 @@ WARNINGS := -Wall
 WARNINGS += $(call cc-supports,-Wstrict-prototypes)
 WARNINGS += $(call cc-supports,-Wdeclaration-after-statement)
 
-KERNEL_INCLUDE := ../../../include
-ACPICA_INCLUDE := ../../../drivers/acpi/acpica
+KERNEL_INCLUDE := $(OUTPUT)include
+ACPICA_INCLUDE := $(srctree)/../../../drivers/acpi/acpica
 CFLAGS += -D_LINUX -I$(KERNEL_INCLUDE) -I$(ACPICA_INCLUDE)
 CFLAGS += $(WARNINGS)
 
diff --git a/tools/power/acpi/Makefile.rules b/tools/power/acpi/Makefile.rules
index ec87a9e..3737383 100644
--- a/tools/power/acpi/Makefile.rules
+++ b/tools/power/acpi/Makefile.rules
@@ -8,28 +8,42 @@
 # as published by the Free Software Foundation; version 2
 # of the License.
 
-$(OUTPUT)$(TOOL): $(TOOL_OBJS) FORCE
-	$(ECHO) "  LD      " $@
-	$(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(TOOL_OBJS) -L$(OUTPUT) -o $@
+objdir := $(OUTPUT)tools/$(TOOL)/
+toolobjs := $(addprefix $(objdir),$(TOOL_OBJS))
+$(OUTPUT)$(TOOL): $(toolobjs) FORCE
+	$(ECHO) "  LD      " $(subst $(OUTPUT),,$@)
+	$(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(toolobjs) -L$(OUTPUT) -o $@
+	$(ECHO) "  STRIP   " $(subst $(OUTPUT),,$@)
 	$(QUIET) $(STRIPCMD) $@
 
-$(OUTPUT)%.o: %.c
-	$(ECHO) "  CC      " $@
+$(KERNEL_INCLUDE):
+	$(ECHO) "  MKDIR   " $(subst $(OUTPUT),,$@)
+	$(QUIET) mkdir -p $(KERNEL_INCLUDE)
+	$(ECHO) "  CP      " $(subst $(OUTPUT),,$@)
+	$(QUIET) cp -rf $(srctree)/../../../include/acpi $(KERNEL_INCLUDE)/
+
+$(objdir)%.o: %.c $(KERNEL_INCLUDE)
+	$(ECHO) "  CC      " $(subst $(OUTPUT),,$@)
 	$(QUIET) $(CC) -c $(CFLAGS) -o $@ $<
 
 all: $(OUTPUT)$(TOOL)
 clean:
-	-find $(OUTPUT) \( -not -type d \) \
-	-and \( -name '*~' -o -name '*.[oas]' \) \
-	-type f -print \
-	 | xargs rm -f
-	-rm -f $(OUTPUT)$(TOOL)
+	$(ECHO) "  RMOBJ   " $(subst $(OUTPUT),,$(objdir))
+	$(QUIET) find $(objdir) \( -not -type d \)\
+		 -and \( -name '*~' -o -name '*.[oas]' \)\
+		 -type f -print | xargs rm -f
+	$(ECHO) "  RM      " $(TOOL)
+	$(QUIET) rm -f $(OUTPUT)$(TOOL)
+	$(ECHO) "  RMINC   " $(subst $(OUTPUT),,$(KERNEL_INCLUDE))
+	$(QUIET) rm -rf $(KERNEL_INCLUDE)
 
 install-tools:
-	$(INSTALL) -d $(DESTDIR)${sbindir}
-	$(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)${sbindir}
+	$(ECHO) "  INST    " $(TOOL)
+	$(QUIET) $(INSTALL) -d $(DESTDIR)$(sbindir)
+	$(QUIET) $(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)$(sbindir)
 uninstall-tools:
-	- rm -f $(DESTDIR)${sbindir}/$(TOOL)
+	$(ECHO) "  UNINST  " $(TOOL)
+	$(QUIET) rm -f $(DESTDIR)$(sbindir)/$(TOOL)
 
 install: all install-tools $(EXTRA_INSTALL)
 uninstall: uninstall-tools $(EXTRA_UNINSTALL)
diff --git a/tools/power/acpi/tools/acpidbg/Makefile b/tools/power/acpi/tools/acpidbg/Makefile
index 352df4b..f2d06e7 100644
--- a/tools/power/acpi/tools/acpidbg/Makefile
+++ b/tools/power/acpi/tools/acpidbg/Makefile
@@ -17,9 +17,7 @@ vpath %.c \
 	../../os_specific/service_layers\
 	.
 CFLAGS += -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER\
-	-I.\
-	-I../../../../../drivers/acpi/acpica\
-	-I../../../../../include
+	-I.
 LDFLAGS += -lpthread
 TOOL_OBJS = \
 	acpidbg.o
diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c b/tools/power/acpi/tools/acpidbg/acpidbg.c
index a88ac45..4308362 100644
--- a/tools/power/acpi/tools/acpidbg/acpidbg.c
+++ b/tools/power/acpi/tools/acpidbg/acpidbg.c
@@ -12,10 +12,16 @@
 #include <acpi/acpi.h>
 
 /* Headers not included by include/acpi/platform/aclinux.h */
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <error.h>
 #include <stdbool.h>
 #include <fcntl.h>
 #include <assert.h>
-#include <linux/circ_buf.h>
+#include <sys/select.h>
+#include "../../../../../include/linux/circ_buf.h"
 
 #define ACPI_AML_FILE		"/sys/kernel/debug/acpi/acpidbg"
 #define ACPI_AML_SEC_TICK	1
diff --git a/tools/power/acpi/tools/acpidump/Makefile b/tools/power/acpi/tools/acpidump/Makefile
index 04b5db7..f7c7af1 100644
--- a/tools/power/acpi/tools/acpidump/Makefile
+++ b/tools/power/acpi/tools/acpidump/Makefile
@@ -19,9 +19,7 @@ vpath %.c \
 	./\
 	../../common\
 	../../os_specific/service_layers
-CFLAGS += -DACPI_DUMP_APP -I.\
-	-I../../../../../drivers/acpi/acpica\
-	-I../../../../../include
+CFLAGS += -DACPI_DUMP_APP -I.
 TOOL_OBJS = \
 	apdump.o\
 	apfiles.o\
@@ -49,7 +47,9 @@ TOOL_OBJS = \
 
 include ../../Makefile.rules
 
-install-man: ../../man/acpidump.8
-	$(INSTALL_DATA) -D $< $(DESTDIR)${mandir}/man8/acpidump.8
+install-man: $(srctree)/man/acpidump.8
+	$(ECHO) "  INST    " acpidump.8
+	$(QUIET) $(INSTALL_DATA) -D $< $(DESTDIR)$(mandir)/man8/acpidump.8
 uninstall-man:
-	- rm -f $(DESTDIR)${mandir}/man8/acpidump.8
+	$(ECHO) "  UNINST  " acpidump.8
+	$(QUIET) rm -f $(DESTDIR)$(mandir)/man8/acpidump.8
-- 
2.7.4

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, Andy

> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Andy
> Shevchenko
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Tue, Nov 15, 2016 at 12:27 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Thu, Nov 3, 2016 at 5:04 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> >>> On Sun, Oct 30, 2016 at 9:04 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> >
> >>> >> > > Please try this patch:
> >>> >> > > https://patchwork.kernel.org/patch/9392155/
> >>> >> > > Which makes tools/power/acpi build more robust to survive toolchains that are not generated
> >>> from
> >>> >> the
> >>> >> > current kernel header.
> 
> Okay, I did a totally clean build (latest linux-next kernel and
> buildroot) without mention patch and still see the issue described
> below:
> 
> > But reveals another, the output path is broken:
> >
> > output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
> > $OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
> > -Wall -Wst
> > rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> > -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
> > ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
> > Assembler messages:
> > Fatal error: can't create $OUT/tools/acpidbg/acpidbg.o: No such file
> > or directory
> > ../../Makefile.rules:26: recipe for target '$OUT/tools/acpidbg/acpidbg.o' failed
> >
> > $OUT — path to O=
> > $SRC — path to kernel sources
> 
> From latest run
> 
> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
> $OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
> -Wall -Wst
> rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
> ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
> 
> Of course it fails since proper folder name should be
> 'tools/power/acpi/tools' instead of 'tools'.

Fixed in v4.
It's my mistake.
Thanks for pointing it out.

Best regards
Lv
> 
> --
> With Best Regards,
> Andy Shevchenko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, Andy

> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Tue, Nov 15, 2016 at 4:23 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Tue, Nov 15, 2016 at 12:27 PM, Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> >> On Thu, Nov 3, 2016 at 5:04 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> >>>> On Sun, Oct 30, 2016 at 9:04 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> 
> >> But reveals another, the output path is broken:
> >>
> >> output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
> >> $OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
> >> -Wall -Wst
> >> rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> >> -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
> >> ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
> >> Assembler messages:
> >> Fatal error: can't create $OUT/tools/acpidbg/acpidbg.o: No such file
> >> or directory
> >> ../../Makefile.rules:26: recipe for target '$OUT/tools/acpidbg/acpidbg.o' failed
> >>
> >> $OUT — path to O=
> >> $SRC — path to kernel sources
> >
> > From latest run
> >
> > output/host/usr/bin/i586-buildroot-linux-uclibc-gcc -c -D_LINUX -I
> > $OUT/include -I $SRC/tools/power/acpi/../../../drivers/acpi/acpica
> > -Wall -Wst
> > rict-prototypes -Wdeclaration-after-statement -O1 -g -DDEBUG
> > -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGG
> > ER -I. -o $OUT/tools/acpidbg/acpidbg.o acpidbg.c
> >
> > Of course it fails since proper folder name should be
> > 'tools/power/acpi/tools' instead of 'tools'.
> 
> The below + several runs (need to serialize makefile, by default it
> races install vs. build)  helped eventually.

I changed dependency in v4.
Please check if it works now.

Thanks and best regards
Lv

> 
> --- a/tools/power/acpi/Makefile.rules
> +++ b/tools/power/acpi/Makefile.rules
> @@ -8,9 +8,9 @@
> # as published by the Free Software Foundation; version 2
> # of the License.
> 
> -objdir := $(OUTPUT)tools/$(TOOL)/
> +objdir := $(OUTPUT)tools/power/acpi/tools/$(TOOL)/
> toolobjs := $(addprefix $(objdir),$(TOOL_OBJS))
> -$(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
> +$(objdir)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
>        $(ECHO) "  LD      " $(subst $(OUTPUT),,$@)
>        $(QUIET) $(LD) $(CFLAGS) $(LDFLAGS) $(toolobjs) -L$(OUTPUT) -o $@
>        $(ECHO) "  STRIP   " $(subst $(OUTPUT),,$@)
> @@ -26,21 +26,21 @@ $(objdir)%.o: %.c
>        $(ECHO) "  CC      " $(subst $(OUTPUT),,$@)
>        $(QUIET) $(CC) -c $(CFLAGS) -o $@ $<
> 
> -all: $(OUTPUT)$(TOOL)
> +all: $(objdir)$(TOOL)
> clean:
>        $(ECHO) "  RMOBJ   " $(subst $(OUTPUT),,$(objdir))
>        $(QUIET) find $(objdir) \( -not -type d \)\
>                 -and \( -name '*~' -o -name '*.[oas]' \)\
>                 -type f -print | xargs rm -f
>        $(ECHO) "  RM      " $(TOOL)
> -       $(QUIET) rm -f $(OUTPUT)$(TOOL)
> +       $(QUIET) rm -f $(objdir)$(TOOL)
>        $(ECHO) "  RMINC   " $(subst $(OUTPUT),,$(KERNEL_INCLUDE))
>        $(QUIET) rm -rf $(KERNEL_INCLUDE)
> 
> install-tools:
>        $(ECHO) "  INST    " $(TOOL)
>        $(QUIET) $(INSTALL) -d $(DESTDIR)$(sbindir)
> -       $(QUIET) $(INSTALL_PROGRAM) $(OUTPUT)$(TOOL) $(DESTDIR)$(sbindir)
> +       $(QUIET) $(INSTALL_PROGRAM) $(objdir)$(TOOL) $(DESTDIR)$(sbindir)
> uninstall-tools:
>        $(ECHO) "  UNINST  " $(TOOL)
>        $(QUIET) rm -f $(DESTDIR)$(sbindir)/$(TOOL)
> 
> 
> --
> With Best Regards,
> Andy Shevchenko

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Rafael J. Wysocki]

On Wed, Nov 16, 2016 at 9:43 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi, Andy
>
>> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
>> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
>>
>> On Tue, Nov 15, 2016 at 5:01 PM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>
>> > The below + several runs (need to serialize makefile, by default it
>> > races install vs. build)  helped eventually.
>>
>> Isn't better just to revert patch I mention and continue from working case?
>
> It's not possible to revert that patch.

It surely is possible to revert things, but it may not be a good idea.
So I think you wanted to say that reverting this particular one would
not be a good idea.

> It contains correct header inclusion cleanups.

Cleanups are not a good enough reason for breaking builds.

> While this case is in fact a special case, bugs in tools/Makefile are triggered (about OUT/SRC).

I'm not sure what you mean.

> OTOH, this case is actually not a very useful case.

In your opinion I guess?

> We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.

I guess the issue is that it was not broken before and it is broken
after your changes.  That's quite a bit of a difference.

> We are just to improve it.

That's nice, but see above.

Thanks,
Rafael

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, Rafael

> From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of Rafael J. Wysocki
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Wed, Nov 16, 2016 at 9:43 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> > Hi, Andy
> >
> >> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> >> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> >>
> >> On Tue, Nov 15, 2016 at 5:01 PM, Andy Shevchenko
> >> <andy.shevchenko@gmail.com> wrote:
> >>
> >> > The below + several runs (need to serialize makefile, by default it
> >> > races install vs. build)  helped eventually.
> >>
> >> Isn't better just to revert patch I mention and continue from working case?
> >
> > It's not possible to revert that patch.
> 
> It surely is possible to revert things, but it may not be a good idea.
> So I think you wanted to say that reverting this particular one would
> not be a good idea.

Yes, it's not a good idea.
The cleanup is correct.

> 
> > It contains correct header inclusion cleanups.
> 
> Cleanups are not a good enough reason for breaking builds.

It doesn't break, build is OK in my environment.

> 
> > While this case is in fact a special case, bugs in tools/Makefile are triggered (about OUT/SRC).
> 
> I'm not sure what you mean.

I'm wrong here.
The only issue triggered is:
The following line in the acenv.h need to be commented out:
#include <signal.h>

> 
> > OTOH, this case is actually not a very useful case.
> 
> In your opinion I guess?

Yes. IMO,
The above breakage looks much more strange than the commit itself.
It's better to make the build successful without commenting this line out.

Such kind of regressions bothered me a lot.
It seems we can easily fell into such old traps.

If I cannot fix the new regression in time, I will sure suggest to revert breakage commit before a better solution can be offered after investigation.
However, for this issue:
1. There is actually no serious breakage (only toolchains built with incompliant kernel headers)
2. We have fixed the issue, but the fix need to be improved.
So reverting the correct commit isn't a good idea.
Reverting it may trigger more serious issues because of wrong header inclusion orders.
Let me improve it.

> 
> > We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
> 
> I guess the issue is that it was not broken before and it is broken
> after your changes.  That's quite a bit of a difference.

IMO, the non-updated toolchains/or ACPICA's sX/uX definitions are actually buggy while the commit isn't.

> 
> > We are just to improve it.
> 
> That's nice, but see above.

Yes, we have fixed it.
And Yisheng Xie has feedback that this issue has been fixed.

However, the v1 fix contains problem:
There is one line dependency not correct:
 acpidbg acpidump ec: include/acpi FORCE
I failed to correct it in v2/v3:
 $(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
Which was criticized by Andy, complaining new breaks for parallel builds.
Now in v4, it is corrected:
 $(objdir)%.o: %.c $(KERNEL_INCLUDE)

However, in v2/v3, I cleaned up OUTPUT related code and changed its behavior of build with "O=".
In v2/v3, build "O=" from tools/power/acpi folder passes, but build from tools folder fails.
In v4, build "O=" from tools folder passes, but build from tools/power/acpi folder fails.

There doesn't seem to be a solution to make both cases working.
Because the "descend" macro in tools/scripts/Makefile.include cannot handle both cases.
Stopping using "descend" macro in tools/power/acpi/Makefile could be the only possible fix...
So we only need one of them working and IMO v4 is suitable for Andy's needs.

As a conclusion, v4 should be OK now.

Thanks and best regards
Lv

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Rafael J. Wysocki]

On Thu, Nov 17, 2016 at 4:10 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi, Rafael
>
>> From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of Rafael J. Wysocki
>> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
>>
>> On Wed, Nov 16, 2016 at 9:43 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
>> > Hi, Andy
>> >
>> >> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
>> >> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
>> >>
>> >> On Tue, Nov 15, 2016 at 5:01 PM, Andy Shevchenko
>> >> <andy.shevchenko@gmail.com> wrote:
>> >>
>> >> > The below + several runs (need to serialize makefile, by default it
>> >> > races install vs. build)  helped eventually.
>> >>
>> >> Isn't better just to revert patch I mention and continue from working case?
>> >
>> > It's not possible to revert that patch.
>>
>> It surely is possible to revert things, but it may not be a good idea.
>> So I think you wanted to say that reverting this particular one would
>> not be a good idea.
>
> Yes, it's not a good idea.
> The cleanup is correct.
>
>>
>> > It contains correct header inclusion cleanups.
>>
>> Cleanups are not a good enough reason for breaking builds.
>
> It doesn't break, build is OK in my environment.
>
>>
>> > While this case is in fact a special case, bugs in tools/Makefile are triggered (about OUT/SRC).
>>
>> I'm not sure what you mean.
>
> I'm wrong here.
> The only issue triggered is:
> The following line in the acenv.h need to be commented out:
> #include <signal.h>
>
>>
>> > OTOH, this case is actually not a very useful case.
>>
>> In your opinion I guess?
>
> Yes. IMO,
> The above breakage looks much more strange than the commit itself.
> It's better to make the build successful without commenting this line out.
>
> Such kind of regressions bothered me a lot.
> It seems we can easily fell into such old traps.
>
> If I cannot fix the new regression in time, I will sure suggest to revert breakage commit before a better solution can be offered after investigation.
> However, for this issue:
> 1. There is actually no serious breakage (only toolchains built with incompliant kernel headers)
> 2. We have fixed the issue, but the fix need to be improved.
> So reverting the correct commit isn't a good idea.
> Reverting it may trigger more serious issues because of wrong header inclusion orders.
> Let me improve it.
>
>>
>> > We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
>>
>> I guess the issue is that it was not broken before and it is broken
>> after your changes.  That's quite a bit of a difference.
>
> IMO, the non-updated toolchains/or ACPICA's sX/uX definitions are actually buggy while the commit isn't.
>
>>
>> > We are just to improve it.
>>
>> That's nice, but see above.
>
> Yes, we have fixed it.
> And Yisheng Xie has feedback that this issue has been fixed.
>
> However, the v1 fix contains problem:
> There is one line dependency not correct:
>  acpidbg acpidump ec: include/acpi FORCE
> I failed to correct it in v2/v3:
>  $(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
> Which was criticized by Andy, complaining new breaks for parallel builds.
> Now in v4, it is corrected:
>  $(objdir)%.o: %.c $(KERNEL_INCLUDE)
>
> However, in v2/v3, I cleaned up OUTPUT related code and changed its behavior of build with "O=".
> In v2/v3, build "O=" from tools/power/acpi folder passes, but build from tools folder fails.
> In v4, build "O=" from tools folder passes, but build from tools/power/acpi folder fails.
>
> There doesn't seem to be a solution to make both cases working.
> Because the "descend" macro in tools/scripts/Makefile.include cannot handle both cases.
> Stopping using "descend" macro in tools/power/acpi/Makefile could be the only possible fix...
> So we only need one of them working and IMO v4 is suitable for Andy's needs.
>
> As a conclusion, v4 should be OK now.

OK, I've queued it up and I'm going to push it for -rc6 tomorrow.

Thanks,
Rafael

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Thu, Nov 17, 2016 at 5:10 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
>>
>> > It contains correct header inclusion cleanups.
>>
>> Cleanups are not a good enough reason for breaking builds.
>
> It doesn't break, build is OK in my environment.

You know, before you did that first clean up for MSVC it worked for me.

Now I got the following

 DESCEND  power/acpi
 DESCEND  tools/acpidbg
 DESCEND  tools/acpidump
 DESCEND  tools/ec
 MKDIR    include
 INST     acpidbg
 MKDIR    include
 INST     ec
 MKDIR    include
 CP       include
 CP       include
/usr/bin/install: cannot stat '.../power/acpi/acpidbg': No such file
or directory
 INST     acpidump
../../Makefile.rules:41: recipe for target 'install-tools' failed
make[6]: *** [install-tools] Error 1
/usr/bin/install: make[6]: *** Waiting for unfinished jobs....
cannot stat '.../power/acpi/ec': No such file or directory
../../Makefile.rules:41: recipe for target 'install-tools' failed
make[6]: *** [install-tools] Error 1
make[6]: *** Waiting for unfinished jobs....
 INST     acpidump.8
 CP       include
Makefile:23: recipe for target 'acpidbg_install' failed
make[5]: *** [acpidbg_install] Error 2
make[5]: *** Waiting for unfinished jobs....
/usr/bin/install: cannot stat '.../power/acpi/acpidump': No such file
or directory
../../Makefile.rules:41: recipe for target 'install-tools' failed
make[6]: *** [install-tools] Error 1
make[6]: *** Waiting for unfinished jobs....
Makefile:23: recipe for target 'ec_install' failed
make[5]: *** [ec_install] Error 2
Makefile:23: recipe for target 'acpidump_install' failed
make[5]: *** [acpidump_install] Error 2
Makefile:95: recipe for target 'acpi_install' failed
make[4]: *** [acpi_install] Error 2

.../Makefile:1613: recipe for target 'tools/acpi_install' failed

>>> Just to notice that above Makefile comes from the source tree not the O= variant
The rest of ... related to O=/my/output/path.

make[3]: *** [tools/acpi_install] Error 2
Makefile:150: recipe for target 'sub-make' failed
make[2]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make[1]: *** [__sub-make] Error 2

So, it doesn't even try to build anything.

> Yes. IMO,
> The above breakage looks much more strange than the commit itself.
> It's better to make the build successful without commenting this line out.
>
> Such kind of regressions bothered me a lot.
> It seems we can easily fell into such old traps.
>
> If I cannot fix the new regression in time, I will sure suggest to revert breakage commit before a better solution can be offered after investigation.
> However, for this issue:
> 1. There is actually no serious breakage (only toolchains built with incompliant kernel headers)
> 2. We have fixed the issue, but the fix need to be improved.
> So reverting the correct commit isn't a good idea.
> Reverting it may trigger more serious issues because of wrong header inclusion orders.
> Let me improve it.
>
>>
>> > We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
>>
>> I guess the issue is that it was not broken before and it is broken
>> after your changes.  That's quite a bit of a difference.
>
> IMO, the non-updated toolchains/or ACPICA's sX/uX definitions are actually buggy while the commit isn't.
>
>>
>> > We are just to improve it.
>>
>> That's nice, but see above.
>
> Yes, we have fixed it.
> And Yisheng Xie has feedback that this issue has been fixed.
>
> However, the v1 fix contains problem:
> There is one line dependency not correct:
>  acpidbg acpidump ec: include/acpi FORCE
> I failed to correct it in v2/v3:
>  $(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
> Which was criticized by Andy, complaining new breaks for parallel builds.
> Now in v4, it is corrected:
>  $(objdir)%.o: %.c $(KERNEL_INCLUDE)
>
> However, in v2/v3, I cleaned up OUTPUT related code and changed its behavior of build with "O=".
> In v2/v3, build "O=" from tools/power/acpi folder passes, but build from tools folder fails.
> In v4, build "O=" from tools folder passes, but build from tools/power/acpi folder fails.
>
> There doesn't seem to be a solution to make both cases working.
> Because the "descend" macro in tools/scripts/Makefile.include cannot handle both cases.
> Stopping using "descend" macro in tools/power/acpi/Makefile could be the only possible fix...
> So we only need one of them working and IMO v4 is suitable for Andy's needs.
>
> As a conclusion, v4 should be OK now.

See above.

This is how make started. $(KERNEL_TOOLS_TARGET) is a list of folders
under tools (for now just "acpi gpio turbostat"). $(1) either
"install" or "clean".
KERNEL_SRC the output folder of kernel build (it might be the same as
sources, but not my case, I used O=). The rest from the list are
compiled and installed nicely. This *was* the case for acpi tools.

+       $(Q)for t in $(KERNEL_TOOLS_TARGET); do                 \
+               $(MAKE) -C $(KERNEL_SRC)                        \
+                       CROSS_COMPILE="$(TARGET_CROSS)"         \
+                       DESTDIR="$(TARGET_DIR)"                 \
+                       tools/$${t}_$(1);                       \
+       done

So. there is no magic here.

Can you add this simple test to your test cases?

-- 
With Best Regards,
Andy Shevchenko

Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Andy Shevchenko]

On Mon, Dec 12, 2016 at 10:58 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Nov 17, 2016 at 5:10 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
>>>
>>> > It contains correct header inclusion cleanups.
>>>
>>> Cleanups are not a good enough reason for breaking builds.
>>
>> It doesn't break, build is OK in my environment.
>
> You know, before you did that first clean up for MSVC it worked for me.
>
> Now I got the following

I serialized make in my example to be make -j1 and got the following

 DESCEND  power/acpi
 DESCEND  tools/acpidbg
 CC       tools/acpidbg/acpidbg.o
Assembler messages:
Fatal error: can't create .../power/acpi/tools/acpidbg/acpidbg.o: No
such file or dir
ectory
../../Makefile.rules:26: recipe for target
'.../power/acpi/tools/acpidbg/acpidbg.o' f
ailed

As you may already notice from the below there is a wrong folder used.
The hierarchy is

% ls -R tools/power/
tools/power/:
acpi  x86

tools/power/acpi:
tools

tools/power/acpi/tools:
acpidbg  acpidump  ec

tools/power/acpi/tools/acpidbg:

tools/power/acpi/tools/acpidump:

tools/power/acpi/tools/ec:

tools/power/x86:
turbostat


>
>  DESCEND  power/acpi
>  DESCEND  tools/acpidbg
>  DESCEND  tools/acpidump
>  DESCEND  tools/ec
>  MKDIR    include
>  INST     acpidbg
>  MKDIR    include
>  INST     ec
>  MKDIR    include
>  CP       include
>  CP       include
> /usr/bin/install: cannot stat '.../power/acpi/acpidbg': No such file
> or directory
>  INST     acpidump
> ../../Makefile.rules:41: recipe for target 'install-tools' failed
> make[6]: *** [install-tools] Error 1
> /usr/bin/install: make[6]: *** Waiting for unfinished jobs....
> cannot stat '.../power/acpi/ec': No such file or directory
> ../../Makefile.rules:41: recipe for target 'install-tools' failed
> make[6]: *** [install-tools] Error 1
> make[6]: *** Waiting for unfinished jobs....
>  INST     acpidump.8
>  CP       include
> Makefile:23: recipe for target 'acpidbg_install' failed
> make[5]: *** [acpidbg_install] Error 2
> make[5]: *** Waiting for unfinished jobs....
> /usr/bin/install: cannot stat '.../power/acpi/acpidump': No such file
> or directory
> ../../Makefile.rules:41: recipe for target 'install-tools' failed
> make[6]: *** [install-tools] Error 1
> make[6]: *** Waiting for unfinished jobs....
> Makefile:23: recipe for target 'ec_install' failed
> make[5]: *** [ec_install] Error 2
> Makefile:23: recipe for target 'acpidump_install' failed
> make[5]: *** [acpidump_install] Error 2
> Makefile:95: recipe for target 'acpi_install' failed
> make[4]: *** [acpi_install] Error 2
>
> .../Makefile:1613: recipe for target 'tools/acpi_install' failed
>
>>>> Just to notice that above Makefile comes from the source tree not the O= variant
> The rest of ... related to O=/my/output/path.
>
> make[3]: *** [tools/acpi_install] Error 2
> Makefile:150: recipe for target 'sub-make' failed
> make[2]: *** [sub-make] Error 2
> Makefile:24: recipe for target '__sub-make' failed
> make[1]: *** [__sub-make] Error 2
>
> So, it doesn't even try to build anything.
>
>> Yes. IMO,
>> The above breakage looks much more strange than the commit itself.
>> It's better to make the build successful without commenting this line out.
>>
>> Such kind of regressions bothered me a lot.
>> It seems we can easily fell into such old traps.
>>
>> If I cannot fix the new regression in time, I will sure suggest to revert breakage commit before a better solution can be offered after investigation.
>> However, for this issue:
>> 1. There is actually no serious breakage (only toolchains built with incompliant kernel headers)
>> 2. We have fixed the issue, but the fix need to be improved.
>> So reverting the correct commit isn't a good idea.
>> Reverting it may trigger more serious issues because of wrong header inclusion orders.
>> Let me improve it.
>>
>>>
>>> > We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
>>>
>>> I guess the issue is that it was not broken before and it is broken
>>> after your changes.  That's quite a bit of a difference.
>>
>> IMO, the non-updated toolchains/or ACPICA's sX/uX definitions are actually buggy while the commit isn't.
>>
>>>
>>> > We are just to improve it.
>>>
>>> That's nice, but see above.
>>
>> Yes, we have fixed it.
>> And Yisheng Xie has feedback that this issue has been fixed.
>>
>> However, the v1 fix contains problem:
>> There is one line dependency not correct:
>>  acpidbg acpidump ec: include/acpi FORCE
>> I failed to correct it in v2/v3:
>>  $(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
>> Which was criticized by Andy, complaining new breaks for parallel builds.
>> Now in v4, it is corrected:
>>  $(objdir)%.o: %.c $(KERNEL_INCLUDE)
>>
>> However, in v2/v3, I cleaned up OUTPUT related code and changed its behavior of build with "O=".
>> In v2/v3, build "O=" from tools/power/acpi folder passes, but build from tools folder fails.
>> In v4, build "O=" from tools folder passes, but build from tools/power/acpi folder fails.
>>
>> There doesn't seem to be a solution to make both cases working.
>> Because the "descend" macro in tools/scripts/Makefile.include cannot handle both cases.
>> Stopping using "descend" macro in tools/power/acpi/Makefile could be the only possible fix...
>> So we only need one of them working and IMO v4 is suitable for Andy's needs.
>>
>> As a conclusion, v4 should be OK now.
>
> See above.
>
> This is how make started. $(KERNEL_TOOLS_TARGET) is a list of folders
> under tools (for now just "acpi gpio turbostat"). $(1) either
> "install" or "clean".
> KERNEL_SRC the output folder of kernel build (it might be the same as
> sources, but not my case, I used O=). The rest from the list are
> compiled and installed nicely. This *was* the case for acpi tools.
>
> +       $(Q)for t in $(KERNEL_TOOLS_TARGET); do                 \
> +               $(MAKE) -C $(KERNEL_SRC)                        \

$(MAKE) is something like make -jXX here

> +                       CROSS_COMPILE="$(TARGET_CROSS)"         \
> +                       DESTDIR="$(TARGET_DIR)"                 \
> +                       tools/$${t}_$(1);                       \
> +       done
>
> So. there is no magic here.
>
> Can you add this simple test to your test cases?


-- 
With Best Regards,
Andy Shevchenko

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, Andy

Good to discuss/synchronize with you in details around this issue.

> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Thu, Nov 17, 2016 at 5:10 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> >>
> >> > It contains correct header inclusion cleanups.
> >>
> >> Cleanups are not a good enough reason for breaking builds.
> >
> > It doesn't break, build is OK in my environment.
> 
> You know, before you did that first clean up for MSVC it worked for me.
> 
> Now I got the following
> 
>  DESCEND  power/acpi
>  DESCEND  tools/acpidbg
>  DESCEND  tools/acpidump
>  DESCEND  tools/ec
>  MKDIR    include
>  INST     acpidbg
>  MKDIR    include
>  INST     ec
>  MKDIR    include
>  CP       include
>  CP       include
> /usr/bin/install: cannot stat '.../power/acpi/acpidbg': No such file
> or directory
>  INST     acpidump
> ../../Makefile.rules:41: recipe for target 'install-tools' failed
> make[6]: *** [install-tools] Error 1
> /usr/bin/install: make[6]: *** Waiting for unfinished jobs....
> cannot stat '.../power/acpi/ec': No such file or directory
> ../../Makefile.rules:41: recipe for target 'install-tools' failed
> make[6]: *** [install-tools] Error 1
> make[6]: *** Waiting for unfinished jobs....
>  INST     acpidump.8
>  CP       include
> Makefile:23: recipe for target 'acpidbg_install' failed
> make[5]: *** [acpidbg_install] Error 2
> make[5]: *** Waiting for unfinished jobs....
> /usr/bin/install: cannot stat '.../power/acpi/acpidump': No such file
> or directory
> ../../Makefile.rules:41: recipe for target 'install-tools' failed
> make[6]: *** [install-tools] Error 1
> make[6]: *** Waiting for unfinished jobs....
> Makefile:23: recipe for target 'ec_install' failed
> make[5]: *** [ec_install] Error 2
> Makefile:23: recipe for target 'acpidump_install' failed
> make[5]: *** [acpidump_install] Error 2
> Makefile:95: recipe for target 'acpi_install' failed
> make[4]: *** [acpi_install] Error 2
> 
> .../Makefile:1613: recipe for target 'tools/acpi_install' failed
> 
> >>> Just to notice that above Makefile comes from the source tree not the O= variant
> The rest of ... related to O=/my/output/path.
> 
> make[3]: *** [tools/acpi_install] Error 2
> Makefile:150: recipe for target 'sub-make' failed
> make[2]: *** [sub-make] Error 2
> Makefile:24: recipe for target '__sub-make' failed
> make[1]: *** [__sub-make] Error 2
> 
> So, it doesn't even try to build anything.

The result depends on where you start your O= command.
In your previous report, you preferred tools folder.
While you reported failures against my old patch which allows O= command from tools/power/acpi
Can you tell me your current directory in this case?

> 
> > Yes. IMO,
> > The above breakage looks much more strange than the commit itself.
> > It's better to make the build successful without commenting this line out.
> >
> > Such kind of regressions bothered me a lot.
> > It seems we can easily fell into such old traps.
> >
> > If I cannot fix the new regression in time, I will sure suggest to revert breakage commit before a
> better solution can be offered after investigation.
> > However, for this issue:
> > 1. There is actually no serious breakage (only toolchains built with incompliant kernel headers)
> > 2. We have fixed the issue, but the fix need to be improved.
> > So reverting the correct commit isn't a good idea.
> > Reverting it may trigger more serious issues because of wrong header inclusion orders.
> > Let me improve it.
> >
> >>
> >> > We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
> >>
> >> I guess the issue is that it was not broken before and it is broken
> >> after your changes.  That's quite a bit of a difference.
> >
> > IMO, the non-updated toolchains/or ACPICA's sX/uX definitions are actually buggy while the commit
> isn't.
> >
> >>
> >> > We are just to improve it.
> >>
> >> That's nice, but see above.
> >
> > Yes, we have fixed it.
> > And Yisheng Xie has feedback that this issue has been fixed.
> >
> > However, the v1 fix contains problem:
> > There is one line dependency not correct:
> >  acpidbg acpidump ec: include/acpi FORCE
> > I failed to correct it in v2/v3:
> >  $(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
> > Which was criticized by Andy, complaining new breaks for parallel builds.
> > Now in v4, it is corrected:
> >  $(objdir)%.o: %.c $(KERNEL_INCLUDE)
> >
> > However, in v2/v3, I cleaned up OUTPUT related code and changed its behavior of build with "O=".
> > In v2/v3, build "O=" from tools/power/acpi folder passes, but build from tools folder fails.
> > In v4, build "O=" from tools folder passes, but build from tools/power/acpi folder fails.
> >
> > There doesn't seem to be a solution to make both cases working.
> > Because the "descend" macro in tools/scripts/Makefile.include cannot handle both cases.
> > Stopping using "descend" macro in tools/power/acpi/Makefile could be the only possible fix...
> > So we only need one of them working and IMO v4 is suitable for Andy's needs.
> >
> > As a conclusion, v4 should be OK now.
> 
> See above.
> 
> This is how make started. $(KERNEL_TOOLS_TARGET) is a list of folders
> under tools (for now just "acpi gpio turbostat"). $(1) either
> "install" or "clean".
> KERNEL_SRC the output folder of kernel build (it might be the same as
> sources, but not my case, I used O=). The rest from the list are
> compiled and installed nicely. This *was* the case for acpi tools.
> 
> +       $(Q)for t in $(KERNEL_TOOLS_TARGET); do                 \
> +               $(MAKE) -C $(KERNEL_SRC)                        \
> +                       CROSS_COMPILE="$(TARGET_CROSS)"         \
> +                       DESTDIR="$(TARGET_DIR)"                 \
> +                       tools/$${t}_$(1);                       \
> +       done
> 
> So. there is no magic here.

So it seems you stay in objtree to do this test.
Which is not handled by the previous commit.
That commit only handles make in "tools" folder.

> 
> Can you add this simple test to your test cases?

The problem is the buggy descend macro, which has some conflicts against the needs of putting the new include folder to objtree.
The descend macro is used in tools/Makefile, and in order to avoid using export (which looks very bad in Makefiles), we reused it in tools/power/acpi/Makefile.
acpidbg acpidump ec: FORCE
	$(call descend,tools/$@,all)
...

It worked previously because we have magic in tools/power/acpi/Makefile to work the descend macro around.
The new acpi makefiles actually uses different output folder from different current directory and different O= assignments.

While we need a stationary directory for the new include folder to be used with -I parameter.
If the new include is in "srctree" folders, there will be no problem, however it pollutes srctree.
(That's why I asked your need - do you want to put the include folder to objtree. But you didn't reply.)
If the new include is in "objtree" folders, I'm not able to find a way to make it stationary because of above magic.

The problem is in tools/scripts/Makefile.include related to objtree:

ifneq ($(O),)
ifeq ($(origin O), command line)
	dummy := $(if $(shell test -d $(O) || echo $(O)),$(error O=$(O) does not exist),)
	ABSOLUTE_O := $(shell cd $(O) ; pwd)
	OUTPUT := $(ABSOLUTE_O)/$(if $(subdir),$(subdir)/)
	COMMAND_O := O=$(ABSOLUTE_O)
ifeq ($(objtree),)
	objtree := $(O)
endif
endif
endif

# check that the output directory actually exists
ifneq ($(OUTPUT),)
OUTDIR := $(shell cd $(OUTPUT) && /bin/pwd)
$(if $(OUTDIR),, $(error output directory "$(OUTPUT)" does not exist))
Endif

1. When we stay in "tools" folder, and O is omit.
   Descend invoked from tools/Makefile causes: objtree=tools.
2. When we stay in "tools" folder, and O is "/tmp".
   Descend invoked from tools/Makefile causes: objtree=/tmp.
3. When we stay in "tools/power/acpi" folder, and O is omit.
   Descend invoked from tools/power/acpi/Makefile causes: objtree=tools/power/acpi.
4. When we stay in "tools/power/acpi" folder, and O is omit.
   Descend invoked from tools/power/acpi/Makefile causes: objtree=/tmp.
5. Now you want to stay in O folder, and O is /tmp.
   Descend invoked from tools/Makefile causes: objtree=/tmp.

So if we want to put the include folder to objtree, what should it be?
For example, if we put include folder in objtree/power/acpi/include, the it probably will fail case 4.
Another example is, if we put include folder in objtree/include, then "make clean" probably will delete the source tree in case 1.

The O= handling in tools/scripts/Makefile.include is the root cause of the issue reported by you, IMO.
Do you have suggestions about how can we get all cases working while still can put include folder in objtree?
I'll also try a different approach to see if the puzzle can be solved.

Thanks and best regards
Lv

RE: Fix in ACPICA tools broke cross compilation of tools/power/acpi

[Zheng, Lv]

Hi, Andy

For parallel build, it should be handled by the previous fix.
The only problem is the O handling IMO.
See my previous reply.
Maybe I should stop using descend in tools/power/acpi/Makefile.

Thanks and best regards
Lv

> From: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> Subject: Re: Fix in ACPICA tools broke cross compilation of tools/power/acpi
> 
> On Mon, Dec 12, 2016 at 10:58 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Thu, Nov 17, 2016 at 5:10 AM, Zheng, Lv <lv.zheng@intel.com> wrote:
> >>>
> >>> > It contains correct header inclusion cleanups.
> >>>
> >>> Cleanups are not a good enough reason for breaking builds.
> >>
> >> It doesn't break, build is OK in my environment.
> >
> > You know, before you did that first clean up for MSVC it worked for me.
> >
> > Now I got the following
> 
> I serialized make in my example to be make -j1 and got the following
> 
>  DESCEND  power/acpi
>  DESCEND  tools/acpidbg
>  CC       tools/acpidbg/acpidbg.o
> Assembler messages:
> Fatal error: can't create .../power/acpi/tools/acpidbg/acpidbg.o: No
> such file or dir
> ectory
> ../../Makefile.rules:26: recipe for target
> '.../power/acpi/tools/acpidbg/acpidbg.o' f
> ailed
> 
> As you may already notice from the below there is a wrong folder used.
> The hierarchy is
> 
> % ls -R tools/power/
> tools/power/:
> acpi  x86
> 
> tools/power/acpi:
> tools
> 
> tools/power/acpi/tools:
> acpidbg  acpidump  ec
> 
> tools/power/acpi/tools/acpidbg:
> 
> tools/power/acpi/tools/acpidump:
> 
> tools/power/acpi/tools/ec:
> 
> tools/power/x86:
> turbostat
> 
> 
> >
> >  DESCEND  power/acpi
> >  DESCEND  tools/acpidbg
> >  DESCEND  tools/acpidump
> >  DESCEND  tools/ec
> >  MKDIR    include
> >  INST     acpidbg
> >  MKDIR    include
> >  INST     ec
> >  MKDIR    include
> >  CP       include
> >  CP       include
> > /usr/bin/install: cannot stat '.../power/acpi/acpidbg': No such file
> > or directory
> >  INST     acpidump
> > ../../Makefile.rules:41: recipe for target 'install-tools' failed
> > make[6]: *** [install-tools] Error 1
> > /usr/bin/install: make[6]: *** Waiting for unfinished jobs....
> > cannot stat '.../power/acpi/ec': No such file or directory
> > ../../Makefile.rules:41: recipe for target 'install-tools' failed
> > make[6]: *** [install-tools] Error 1
> > make[6]: *** Waiting for unfinished jobs....
> >  INST     acpidump.8
> >  CP       include
> > Makefile:23: recipe for target 'acpidbg_install' failed
> > make[5]: *** [acpidbg_install] Error 2
> > make[5]: *** Waiting for unfinished jobs....
> > /usr/bin/install: cannot stat '.../power/acpi/acpidump': No such file
> > or directory
> > ../../Makefile.rules:41: recipe for target 'install-tools' failed
> > make[6]: *** [install-tools] Error 1
> > make[6]: *** Waiting for unfinished jobs....
> > Makefile:23: recipe for target 'ec_install' failed
> > make[5]: *** [ec_install] Error 2
> > Makefile:23: recipe for target 'acpidump_install' failed
> > make[5]: *** [acpidump_install] Error 2
> > Makefile:95: recipe for target 'acpi_install' failed
> > make[4]: *** [acpi_install] Error 2
> >
> > .../Makefile:1613: recipe for target 'tools/acpi_install' failed
> >
> >>>> Just to notice that above Makefile comes from the source tree not the O= variant
> > The rest of ... related to O=/my/output/path.
> >
> > make[3]: *** [tools/acpi_install] Error 2
> > Makefile:150: recipe for target 'sub-make' failed
> > make[2]: *** [sub-make] Error 2
> > Makefile:24: recipe for target '__sub-make' failed
> > make[1]: *** [__sub-make] Error 2
> >
> > So, it doesn't even try to build anything.
> >
> >> Yes. IMO,
> >> The above breakage looks much more strange than the commit itself.
> >> It's better to make the build successful without commenting this line out.
> >>
> >> Such kind of regressions bothered me a lot.
> >> It seems we can easily fell into such old traps.
> >>
> >> If I cannot fix the new regression in time, I will sure suggest to revert breakage commit before a
> better solution can be offered after investigation.
> >> However, for this issue:
> >> 1. There is actually no serious breakage (only toolchains built with incompliant kernel headers)
> >> 2. We have fixed the issue, but the fix need to be improved.
> >> So reverting the correct commit isn't a good idea.
> >> Reverting it may trigger more serious issues because of wrong header inclusion orders.
> >> Let me improve it.
> >>
> >>>
> >>> > We can see many tools build broken for cross-compilers, and tools/power/acpi is not the only one.
> >>>
> >>> I guess the issue is that it was not broken before and it is broken
> >>> after your changes.  That's quite a bit of a difference.
> >>
> >> IMO, the non-updated toolchains/or ACPICA's sX/uX definitions are actually buggy while the commit
> isn't.
> >>
> >>>
> >>> > We are just to improve it.
> >>>
> >>> That's nice, but see above.
> >>
> >> Yes, we have fixed it.
> >> And Yisheng Xie has feedback that this issue has been fixed.
> >>
> >> However, the v1 fix contains problem:
> >> There is one line dependency not correct:
> >>  acpidbg acpidump ec: include/acpi FORCE
> >> I failed to correct it in v2/v3:
> >>  $(OUTPUT)$(TOOL): $(KERNEL_INCLUDE) $(toolobjs) FORCE
> >> Which was criticized by Andy, complaining new breaks for parallel builds.
> >> Now in v4, it is corrected:
> >>  $(objdir)%.o: %.c $(KERNEL_INCLUDE)
> >>
> >> However, in v2/v3, I cleaned up OUTPUT related code and changed its behavior of build with "O=".
> >> In v2/v3, build "O=" from tools/power/acpi folder passes, but build from tools folder fails.
> >> In v4, build "O=" from tools folder passes, but build from tools/power/acpi folder fails.
> >>
> >> There doesn't seem to be a solution to make both cases working.
> >> Because the "descend" macro in tools/scripts/Makefile.include cannot handle both cases.
> >> Stopping using "descend" macro in tools/power/acpi/Makefile could be the only possible fix...
> >> So we only need one of them working and IMO v4 is suitable for Andy's needs.
> >>
> >> As a conclusion, v4 should be OK now.
> >
> > See above.
> >
> > This is how make started. $(KERNEL_TOOLS_TARGET) is a list of folders
> > under tools (for now just "acpi gpio turbostat"). $(1) either
> > "install" or "clean".
> > KERNEL_SRC the output folder of kernel build (it might be the same as
> > sources, but not my case, I used O=). The rest from the list are
> > compiled and installed nicely. This *was* the case for acpi tools.
> >
> > +       $(Q)for t in $(KERNEL_TOOLS_TARGET); do                 \
> > +               $(MAKE) -C $(KERNEL_SRC)                        \
> 
> $(MAKE) is something like make -jXX here
> 
> > +                       CROSS_COMPILE="$(TARGET_CROSS)"         \
> > +                       DESTDIR="$(TARGET_DIR)"                 \
> > +                       tools/$${t}_$(1);                       \
> > +       done
> >
> > So. there is no magic here.
> >
> > Can you add this simple test to your test cases?
> 
> 
> --
> With Best Regards,
> Andy Shevchenko