[v6,18/28] package/cmake: Fix for using -O in top-level make
diff mbox series

Message ID 20200217212350.29750-19-anaumann@ultratronik.de
State Changes Requested
Headers show
Series
  • Qt5 qmake infra and per-package compatibility
Related show

Commit Message

Andreas Naumann Feb. 17, 2020, 9:23 p.m. UTC
Setting -O in top level make somehow interferes with the explicit setting of
-jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure
case.

Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>
---
 package/cmake/cmake.mk | 1 +
 1 file changed, 1 insertion(+)

Comments

Thomas Petazzoni March 11, 2020, 10:25 p.m. UTC | #1
Hello,

Let's add Arnout in the loop, for the make sorcery.

On Mon, 17 Feb 2020 22:23:40 +0100
Andreas Naumann <anaumann@ultratronik.de> wrote:

> Setting -O in top level make somehow interferes with the explicit setting of
> -jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure
> case.
> 
> Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>

This commit log was a bit vague on what the issue was. If I understand
correctly, what you see is that the "make" process running to build
host-cmake is constantly entering/leaving its build directory, like
this:

make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
[ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o
make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
[ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o
make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
[ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o
make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'

Reading
https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html,
it seems like it is expected for -Otarget to behave like this. However,
if you use -Orecurse, it works as expected: the entire output of the
sub-make is buffered, and output in one-go when the make target at the
Buildroot level completes.

So I'm not sure we want to prevent -Otarget from doing what it does: we
should probably instead use -Orecurse.

Best regards,

Thomas
Arnout Vandecappelle March 12, 2020, 1 p.m. UTC | #2
On 11/03/2020 23:25, Thomas Petazzoni wrote:
> Hello,
> 
> Let's add Arnout in the loop, for the make sorcery.

 Not much sorcery going on here...

> On Mon, 17 Feb 2020 22:23:40 +0100
> Andreas Naumann <anaumann@ultratronik.de> wrote:
> 
>> Setting -O in top level make somehow interferes with the explicit setting of
>> -jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure
>> case.
>>
>> Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>
> 
> This commit log was a bit vague on what the issue was. If I understand
> correctly, what you see is that the "make" process running to build
> host-cmake is constantly entering/leaving its build directory, like
> this:
> 
> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o
> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o
> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o
> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
> 
> Reading
> https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html,
> it seems like it is expected for -Otarget to behave like this.

Indeed, looks exactly like expected.

> However,
> if you use -Orecurse, it works as expected: the entire output of the
> sub-make is buffered, and output in one-go when the make target at the
> Buildroot level completes.
> 
> So I'm not sure we want to prevent -Otarget from doing what it does: we
> should probably instead use -Orecurse.


 Where do we pass -Otarget to begin with?

 There could be something to be set for globall resetting MAKEFLAGS and taking
control over the make flags entirely from Buildroot infra when calling into
package build systems. However, this is a bit complicated in make, and I'm not
entirely convinced we really want that...

 Regards,
 Arnout
Thomas Petazzoni March 12, 2020, 1:22 p.m. UTC | #3
On Thu, 12 Mar 2020 14:00:24 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

> > Reading
> > https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html,
> > it seems like it is expected for -Otarget to behave like this.  
> 
> Indeed, looks exactly like expected.
> 
> > However,
> > if you use -Orecurse, it works as expected: the entire output of the
> > sub-make is buffered, and output in one-go when the make target at the
> > Buildroot level completes.
> > 
> > So I'm not sure we want to prevent -Otarget from doing what it does: we
> > should probably instead use -Orecurse.  
> 
> 
>  Where do we pass -Otarget to begin with?

We don't. But I guess Andreas is using "make -Otarget" as it is
using/testing top-level parallel build and it doesn't want messed up
build log.

>  There could be something to be set for globall resetting MAKEFLAGS and taking
> control over the make flags entirely from Buildroot infra when calling into
> package build systems. However, this is a bit complicated in make, and I'm not
> entirely convinced we really want that...

And I assume we wouldn't want to solve on that on a per-package basis,
but rather more globally for all packages.

Best regards,

Thomas
Andreas Naumann March 16, 2020, 10:15 p.m. UTC | #4
Hi,

On 12.03.20 14:00, Arnout Vandecappelle wrote:
> 
> 
> On 11/03/2020 23:25, Thomas Petazzoni wrote:
>> Hello,
>>
>> Let's add Arnout in the loop, for the make sorcery.
> 
>   Not much sorcery going on here...
> 
>> On Mon, 17 Feb 2020 22:23:40 +0100
>> Andreas Naumann <anaumann@ultratronik.de> wrote:
>>
>>> Setting -O in top level make somehow interferes with the explicit setting of
>>> -jX in the cmake bootstrap script. Avoid passing down MAKEFLAGS in the configure
>>> case.
>>>
>>> Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>
>>
>> This commit log was a bit vague on what the issue was. If I understand

The issue was that the cmake configure step stopped with an error if I 
used the -O option. I dont think it was related to which output strategy 
was used.

>> correctly, what you see is that the "make" process running to build
>> host-cmake is constantly entering/leaving its build directory, like
>> this:
>>
>> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
>> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_rpm.c.o
>> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
>> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
>> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_none.c.o
>> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
>> make[3]: Entering directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
>> [ 50%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read_support_filter_program.c.o
>> make[3]: Leaving directory '/home/thomas/projets/buildroot/output/build/host-cmake-3.15.5'
>>
>> Reading
>> https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html,
>> it seems like it is expected for -Otarget to behave like this.
> 
> Indeed, looks exactly like expected. >
>> However,
>> if you use -Orecurse, it works as expected: the entire output of the
>> sub-make is buffered, and output in one-go when the make target at the
>> Buildroot level completes.

I dont mind the entering/leaving info. Rather I thought -Orecurse would 
buffer everything to the end of the buildroot process, which is not what 
I wanted.

>>
>> So I'm not sure we want to prevent -Otarget from doing what it does: we
>> should probably instead use -Orecurse.
> 
> 
>   Where do we pass -Otarget to begin with?

I did after brmake.

> 
>   There could be something to be set for globall resetting MAKEFLAGS and taking
> control over the make flags entirely from Buildroot infra when calling into
> package build systems. However, this is a bit complicated in make, and I'm not
> entirely convinced we really want that...

Hmm, I have not seen problems anywhere else with the -O option. Just in 
this case the configure step died. After some fiddling I found out it's 
connected to what the bootstrap script does with the option 
--parallel=$(PARALLEL_JOBS). If the --parallel option was not used then 
-Oxxx was not a problem, but of course, the build used one core only.


regards,
Andreas




> 
>   Regards,
>   Arnout
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Thomas Petazzoni March 17, 2020, 6:08 a.m. UTC | #5
Hello,

On Mon, 16 Mar 2020 23:15:24 +0100
Andreas Naumann <dev@andin.de> wrote:

> >> This commit log was a bit vague on what the issue was. If I understand  
> 
> The issue was that the cmake configure step stopped with an error if I 
> used the -O option. I dont think it was related to which output strategy 
> was used.

I have not been able to reproduce the CMake configure step failure
then. Are you still able to reproduce this? If so, could you provide
more details about the setup: make version being, exact command line,
Buildroot version, etc ?

Best regards,

Thomas
Asaf Kahlon March 17, 2020, 7:02 p.m. UTC | #6
Hello,

On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello,
>
> On Mon, 16 Mar 2020 23:15:24 +0100
> Andreas Naumann <dev@andin.de> wrote:
>
> > >> This commit log was a bit vague on what the issue was. If I understand
> >
> > The issue was that the cmake configure step stopped with an error if I
> > used the -O option. I dont think it was related to which output strategy
> > was used.
>
> I have not been able to reproduce the CMake configure step failure
> then. Are you still able to reproduce this? If so, could you provide
> more details about the setup: make version being, exact command line,
> Buildroot version, etc ?

I had this problem too, but currently I can't reproduce it.
I'm still trying to reproduce and will update, but for the meantime:
* My Buildroot version is 2020.02
* The command I used was: make -j9 --output-sync=target
* The CMake configure step failed. On the CMake log I saw the following message:
   ccache: invalid option -- 'O'
It seems like somehow the -O flag (==output-sync) was passed directly to ccache.

>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Regards,
Asaf.
Andreas Naumann March 18, 2020, 3:35 p.m. UTC | #7
Hi,

On 17.03.20 20:02, Asaf Kahlon wrote:
> Hello,
> 
> On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
>>
>> Hello,
>>
>> On Mon, 16 Mar 2020 23:15:24 +0100
>> Andreas Naumann <dev@andin.de> wrote:
>>
>>>>> This commit log was a bit vague on what the issue was. If I understand
>>>
>>> The issue was that the cmake configure step stopped with an error if I
>>> used the -O option. I dont think it was related to which output strategy
>>> was used.
>>
>> I have not been able to reproduce the CMake configure step failure
>> then. Are you still able to reproduce this? If so, could you provide
>> more details about the setup: make version being, exact command line,
>> Buildroot version, etc ?
> 
> I had this problem too, but currently I can't reproduce it.
> I'm still trying to reproduce and will update, but for the meantime:
> * My Buildroot version is 2020.02
> * The command I used was: make -j9 --output-sync=target
> * The CMake configure step failed. On the CMake log I saw the following message:
>     ccache: invalid option -- 'O'
> It seems like somehow the -O flag (==output-sync) was passed directly to ccache.

I'm not using ccache at the moment and I dont get a sensible error 
message. But seeing your error message I recognize it because probably I 
used ccache back when I made the patch.

Now after testing again with master (0f0868a) I can state the following:

Build breaks during configure (bootstrap) phase when running
*  make -j2 -Oline host-cmake
*  make -j2 -Otarget host-cmake
with
   Error when bootstrapping CMake:
   Problem while running make
   ---------------------------------------------
   Log of errors: 
/home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log

Looking at the logfile I cant figure out what the problem is.

The build succeeds with
*  make -j2 host-cmake
*  make -j2 -Onone host-cmake
*  make -j2 -Orecurse host-cmake

My assumption is that the problem lies in passing certain MAKEFLAGS for 
a parallel build while not passing -jxxx itself but using the 
--parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow 
reassembles the -jxxx option and certain ${cmake_make_flags} in an 
incompatible way (at least for -Oline and -Otarget).

I use GNU Make 4.1.

best regards,
Andreas


> 
>>
>> Best regards,
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>> _______________________________________________
>> buildroot mailing list
>> buildroot@busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> Regards,
> Asaf.
>
Asaf Kahlon March 18, 2020, 6:59 p.m. UTC | #8
Hello,

On Wed, Mar 18, 2020 at 5:35 PM Andreas Naumann <dev@andin.de> wrote:
>
> Hi,
>
> On 17.03.20 20:02, Asaf Kahlon wrote:
> > Hello,
> >
> > On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni
> > <thomas.petazzoni@bootlin.com> wrote:
> >>
> >> Hello,
> >>
> >> On Mon, 16 Mar 2020 23:15:24 +0100
> >> Andreas Naumann <dev@andin.de> wrote:
> >>
> >>>>> This commit log was a bit vague on what the issue was. If I understand
> >>>
> >>> The issue was that the cmake configure step stopped with an error if I
> >>> used the -O option. I dont think it was related to which output strategy
> >>> was used.
> >>
> >> I have not been able to reproduce the CMake configure step failure
> >> then. Are you still able to reproduce this? If so, could you provide
> >> more details about the setup: make version being, exact command line,
> >> Buildroot version, etc ?
> >
> > I had this problem too, but currently I can't reproduce it.
> > I'm still trying to reproduce and will update, but for the meantime:
> > * My Buildroot version is 2020.02
> > * The command I used was: make -j9 --output-sync=target
> > * The CMake configure step failed. On the CMake log I saw the following message:
> >     ccache: invalid option -- 'O'
> > It seems like somehow the -O flag (==output-sync) was passed directly to ccache.
>
> I'm not using ccache at the moment and I dont get a sensible error
> message. But seeing your error message I recognize it because probably I
> used ccache back when I made the patch.
>
> Now after testing again with master (0f0868a) I can state the following:
>
> Build breaks during configure (bootstrap) phase when running
> *  make -j2 -Oline host-cmake
> *  make -j2 -Otarget host-cmake
> with
>    Error when bootstrapping CMake:
>    Problem while running make
>    ---------------------------------------------
>    Log of errors:
> /home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log
>
> Looking at the logfile I cant figure out what the problem is.
>
> The build succeeds with
> *  make -j2 host-cmake
> *  make -j2 -Onone host-cmake
> *  make -j2 -Orecurse host-cmake
>
> My assumption is that the problem lies in passing certain MAKEFLAGS for
> a parallel build while not passing -jxxx itself but using the
> --parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow
> reassembles the -jxxx option and certain ${cmake_make_flags} in an
> incompatible way (at least for -Oline and -Otarget).
>
> I use GNU Make 4.1.

This line made me suspect the make version.
I use make 4.2.1 and it always works for me.
I tried to reproduce it on a docker with make 4.1 and it instantly reproduced.
When I installed on the docker container Make 4.2.1 - it worked.
Can this be a bug in Make?

>
> best regards,
> Andreas
>
>
> >
> >>
> >> Best regards,
> >>
> >> Thomas
> >> --
> >> Thomas Petazzoni, CTO, Bootlin
> >> Embedded Linux and Kernel engineering
> >> https://bootlin.com
> >> _______________________________________________
> >> buildroot mailing list
> >> buildroot@busybox.net
> >> http://lists.busybox.net/mailman/listinfo/buildroot
> >
> > Regards,
> > Asaf.
> >

Regards,
Asaf.
Andreas Naumann March 18, 2020, 9:03 p.m. UTC | #9
Hi,

On 18.03.20 19:59, Asaf Kahlon wrote:
> Hello,
> 
> On Wed, Mar 18, 2020 at 5:35 PM Andreas Naumann <dev@andin.de> wrote:
>>
>> Hi,
>>
>> On 17.03.20 20:02, Asaf Kahlon wrote:
>>> Hello,
>>>
>>> On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni
>>> <thomas.petazzoni@bootlin.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> On Mon, 16 Mar 2020 23:15:24 +0100
>>>> Andreas Naumann <dev@andin.de> wrote:
>>>>
>>>>>>> This commit log was a bit vague on what the issue was. If I understand
>>>>>
>>>>> The issue was that the cmake configure step stopped with an error if I
>>>>> used the -O option. I dont think it was related to which output strategy
>>>>> was used.
>>>>
>>>> I have not been able to reproduce the CMake configure step failure
>>>> then. Are you still able to reproduce this? If so, could you provide
>>>> more details about the setup: make version being, exact command line,
>>>> Buildroot version, etc ?
>>>
>>> I had this problem too, but currently I can't reproduce it.
>>> I'm still trying to reproduce and will update, but for the meantime:
>>> * My Buildroot version is 2020.02
>>> * The command I used was: make -j9 --output-sync=target
>>> * The CMake configure step failed. On the CMake log I saw the following message:
>>>      ccache: invalid option -- 'O'
>>> It seems like somehow the -O flag (==output-sync) was passed directly to ccache.
>>
>> I'm not using ccache at the moment and I dont get a sensible error
>> message. But seeing your error message I recognize it because probably I
>> used ccache back when I made the patch.
>>
>> Now after testing again with master (0f0868a) I can state the following:
>>
>> Build breaks during configure (bootstrap) phase when running
>> *  make -j2 -Oline host-cmake
>> *  make -j2 -Otarget host-cmake
>> with
>>     Error when bootstrapping CMake:
>>     Problem while running make
>>     ---------------------------------------------
>>     Log of errors:
>> /home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log
>>
>> Looking at the logfile I cant figure out what the problem is.
>>
>> The build succeeds with
>> *  make -j2 host-cmake
>> *  make -j2 -Onone host-cmake
>> *  make -j2 -Orecurse host-cmake
>>
>> My assumption is that the problem lies in passing certain MAKEFLAGS for
>> a parallel build while not passing -jxxx itself but using the
>> --parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow
>> reassembles the -jxxx option and certain ${cmake_make_flags} in an
>> incompatible way (at least for -Oline and -Otarget).
>>
>> I use GNU Make 4.1.
> 
> This line made me suspect the make version.
> I use make 4.2.1 and it always works for me.
> I tried to reproduce it on a docker with make 4.1 and it instantly reproduced.
> When I installed on the docker container Make 4.2.1 - it worked.
> Can this be a bug in Make?

I tried 4.2.1 as well and the issue is gone. In the changelog for 4.2 at 
https://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013.html I found:
* main.c(main): Disable output sync without parallel builds.
To me it seems like this could be the culprit. The question is, what 
should we do with this? Check for Make version < 4.2 && -j && -O and 
give a warning? Maybe this is a bit too much.

regards,
Andreas

> 
>>
>> best regards,
>> Andreas
>>
>>
>>>
>>>>
>>>> Best regards,
>>>>
>>>> Thomas
>>>> --
>>>> Thomas Petazzoni, CTO, Bootlin
>>>> Embedded Linux and Kernel engineering
>>>> https://bootlin.com
>>>> _______________________________________________
>>>> buildroot mailing list
>>>> buildroot@busybox.net
>>>> http://lists.busybox.net/mailman/listinfo/buildroot
>>>
>>> Regards,
>>> Asaf.
>>>
> 
> Regards,
> Asaf.
>
Asaf Kahlon March 19, 2020, 11:40 a.m. UTC | #10
Hi,

On Wed, Mar 18, 2020 at 11:03 PM Andreas Naumann <dev@andin.de> wrote:
>
> Hi,
>
> On 18.03.20 19:59, Asaf Kahlon wrote:
> > Hello,
> >
> > On Wed, Mar 18, 2020 at 5:35 PM Andreas Naumann <dev@andin.de> wrote:
> >>
> >> Hi,
> >>
> >> On 17.03.20 20:02, Asaf Kahlon wrote:
> >>> Hello,
> >>>
> >>> On Tue, Mar 17, 2020 at 8:08 AM Thomas Petazzoni
> >>> <thomas.petazzoni@bootlin.com> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> On Mon, 16 Mar 2020 23:15:24 +0100
> >>>> Andreas Naumann <dev@andin.de> wrote:
> >>>>
> >>>>>>> This commit log was a bit vague on what the issue was. If I understand
> >>>>>
> >>>>> The issue was that the cmake configure step stopped with an error if I
> >>>>> used the -O option. I dont think it was related to which output strategy
> >>>>> was used.
> >>>>
> >>>> I have not been able to reproduce the CMake configure step failure
> >>>> then. Are you still able to reproduce this? If so, could you provide
> >>>> more details about the setup: make version being, exact command line,
> >>>> Buildroot version, etc ?
> >>>
> >>> I had this problem too, but currently I can't reproduce it.
> >>> I'm still trying to reproduce and will update, but for the meantime:
> >>> * My Buildroot version is 2020.02
> >>> * The command I used was: make -j9 --output-sync=target
> >>> * The CMake configure step failed. On the CMake log I saw the following message:
> >>>      ccache: invalid option -- 'O'
> >>> It seems like somehow the -O flag (==output-sync) was passed directly to ccache.
> >>
> >> I'm not using ccache at the moment and I dont get a sensible error
> >> message. But seeing your error message I recognize it because probably I
> >> used ccache back when I made the patch.
> >>
> >> Now after testing again with master (0f0868a) I can state the following:
> >>
> >> Build breaks during configure (bootstrap) phase when running
> >> *  make -j2 -Oline host-cmake
> >> *  make -j2 -Otarget host-cmake
> >> with
> >>     Error when bootstrapping CMake:
> >>     Problem while running make
> >>     ---------------------------------------------
> >>     Log of errors:
> >> /home/yocto/anaumann/buildroot-qmake-v6/output/build/host-cmake-3.15.5/Bootstrap.cmk/cmake_bootstrap.log
> >>
> >> Looking at the logfile I cant figure out what the problem is.
> >>
> >> The build succeeds with
> >> *  make -j2 host-cmake
> >> *  make -j2 -Onone host-cmake
> >> *  make -j2 -Orecurse host-cmake
> >>
> >> My assumption is that the problem lies in passing certain MAKEFLAGS for
> >> a parallel build while not passing -jxxx itself but using the
> >> --parallel=$(PARALLEL_JOBS) option. The bootstrap script then somehow
> >> reassembles the -jxxx option and certain ${cmake_make_flags} in an
> >> incompatible way (at least for -Oline and -Otarget).
> >>
> >> I use GNU Make 4.1.
> >
> > This line made me suspect the make version.
> > I use make 4.2.1 and it always works for me.
> > I tried to reproduce it on a docker with make 4.1 and it instantly reproduced.
> > When I installed on the docker container Make 4.2.1 - it worked.
> > Can this be a bug in Make?
>
> I tried 4.2.1 as well and the issue is gone. In the changelog for 4.2 at
> https://lists.gnu.org/archive/html/info-gnu/2016-05/msg00013.html I found:
> * main.c(main): Disable output sync without parallel builds.
Actually, this commit was not the one which fixes the bug (although I
also suspected it
because of the commit title).
I did a git-bisect from 4.1 to 4.2 and found out the commit was fb7a7ad
(Extract jobserver implementation into OS-specific files.)

> To me it seems like this could be the culprit. The question is, what
> should we do with this? Check for Make version < 4.2 && -j && -O and
> give a warning? Maybe this is a bit too much.
We now check for make>4.0. Do we want to bump it?
Maybe some of the core Buildroot maintainers can give their advice here.

>
> regards,
> Andreas
>
> >
> >>
> >> best regards,
> >> Andreas
> >>
> >>
> >>>
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Thomas
> >>>> --
> >>>> Thomas Petazzoni, CTO, Bootlin
> >>>> Embedded Linux and Kernel engineering
> >>>> https://bootlin.com
> >>>> _______________________________________________
> >>>> buildroot mailing list
> >>>> buildroot@busybox.net
> >>>> http://lists.busybox.net/mailman/listinfo/buildroot
> >>>
> >>> Regards,
> >>> Asaf.
> >>>
> >
> > Regards,
> > Asaf.
> >
Regards,
Asaf.
Thomas Petazzoni March 19, 2020, 12:49 p.m. UTC | #11
On Thu, 19 Mar 2020 13:40:36 +0200
Asaf Kahlon <asafka7@gmail.com> wrote:

> > To me it seems like this could be the culprit. The question is, what
> > should we do with this? Check for Make version < 4.2 && -j && -O and
> > give a warning? Maybe this is a bit too much.  
> We now check for make>4.0. Do we want to bump it?
> Maybe some of the core Buildroot maintainers can give their advice here.

We don't require make 4.0, we only require make 3.81.

The logic in support/dependencies/check-host-make.mk to check for make
4.0 is only for those few packages that do need make >= 4.0. For such
packages, if the version of make installed system-wide is < 4.0, then
we build our own host-make. But the overall Buildroot build is still
executed by the system-wide make, which may be < 4.0.

Requiring make > 4.0 on the host system is too strict, especially
considering that the issue we have here only happens in very specific
conditions: ccache support enabled, and passing of custom -O flags that
are only useful for top-level parallel build, which is itself an
experimental feature.

Best regards,

Thomas
Asaf Kahlon March 19, 2020, 1:53 p.m. UTC | #12
Hello,

On Thu, Mar 19, 2020 at 2:49 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Thu, 19 Mar 2020 13:40:36 +0200
> Asaf Kahlon <asafka7@gmail.com> wrote:
>
> > > To me it seems like this could be the culprit. The question is, what
> > > should we do with this? Check for Make version < 4.2 && -j && -O and
> > > give a warning? Maybe this is a bit too much.
> > We now check for make>4.0. Do we want to bump it?
> > Maybe some of the core Buildroot maintainers can give their advice here.
>
> We don't require make 4.0, we only require make 3.81.
>
> The logic in support/dependencies/check-host-make.mk to check for make
> 4.0 is only for those few packages that do need make >= 4.0. For such
> packages, if the version of make installed system-wide is < 4.0, then
> we build our own host-make. But the overall Buildroot build is still
> executed by the system-wide make, which may be < 4.0.

You're right, thanks for the correction.

>
> Requiring make > 4.0 on the host system is too strict, especially
> considering that the issue we have here only happens in very specific
> conditions: ccache support enabled, and passing of custom -O flags that
> are only useful for top-level parallel build, which is itself an
> experimental feature.

Just as a side note - the problem isn't related to ccache. We
reproduced it with -O
and top-level parallel build.
In addition, if you have any suggestion how to address that case -
I'll be more than happy
to help.

>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Asaf.
Thomas Petazzoni March 19, 2020, 2 p.m. UTC | #13
On Thu, 19 Mar 2020 15:53:23 +0200
Asaf Kahlon <asafka7@gmail.com> wrote:

> > Requiring make > 4.0 on the host system is too strict, especially
> > considering that the issue we have here only happens in very specific
> > conditions: ccache support enabled, and passing of custom -O flags that
> > are only useful for top-level parallel build, which is itself an
> > experimental feature.  
> 
> Just as a side note - the problem isn't related to ccache. We
> reproduced it with -O and top-level parallel build.

Sorry, I mixed things up, and thought it was ccache related.

> In addition, if you have any suggestion how to address that case -
> I'll be more than happy to help.

I don't have any really good suggestion. But it's really a corner case:
only happens with make 4.1 if I understand correctly, and only when you
pass some variants of the -O option.

The "make -Orecurse" option, which is the most relevant for top-level
parallel build, does not exhibit the issue.

So essentially I simply wouldn't fix the problem. If you really want to
fix it, maybe we can have some fancy logic in the main Makefile to
detect that one of the problematic -O option is passed, and the make
version is not appropriate, and then error out.

Thomas
Andreas Naumann March 22, 2020, 8:46 p.m. UTC | #14
Hi,

On 19.03.20 15:00, Thomas Petazzoni wrote:
> On Thu, 19 Mar 2020 15:53:23 +0200
> Asaf Kahlon <asafka7@gmail.com> wrote:
> 
>>> Requiring make > 4.0 on the host system is too strict, especially
>>> considering that the issue we have here only happens in very specific
>>> conditions: ccache support enabled, and passing of custom -O flags that
>>> are only useful for top-level parallel build, which is itself an
>>> experimental feature.
>>
>> Just as a side note - the problem isn't related to ccache. We
>> reproduced it with -O and top-level parallel build.
> 
> Sorry, I mixed things up, and thought it was ccache related.
> 
>> In addition, if you have any suggestion how to address that case -
>> I'll be more than happy to help.
> 
> I don't have any really good suggestion. But it's really a corner case:
> only happens with make 4.1 if I understand correctly, and only when you
> pass some variants of the -O option.
> 
> The "make -Orecurse" option, which is the most relevant for top-level
> parallel build, does not exhibit the issue.
> 
> So essentially I simply wouldn't fix the problem. If you really want to

That's ok for me since it really is a corner case.


regards,
Andreas



> fix it, maybe we can have some fancy logic in the main Makefile to
> detect that one of the problematic -O option is passed, and the make
> version is not appropriate, and then error out.
> 
> Thomas
>

Patch
diff mbox series

diff --git a/package/cmake/cmake.mk b/package/cmake/cmake.mk
index 1f30736023..690603b09c 100644
--- a/package/cmake/cmake.mk
+++ b/package/cmake/cmake.mk
@@ -41,6 +41,7 @@  define HOST_CMAKE_CONFIGURE_CMDS
 	(cd $(@D); \
 		$(HOST_CONFIGURE_OPTS) \
 		CFLAGS="$(HOST_CMAKE_CFLAGS)" \
+		MAKEFLAGS= \
 		./bootstrap --prefix=$(HOST_DIR) \
 			--parallel=$(PARALLEL_JOBS) -- \
 			-DCMAKE_C_FLAGS="$(HOST_CMAKE_CFLAGS)" \