[OE-core] [PATCH 1/1] autotools: do more cleanup when in do_configure

ChenQi Qi.Chen at windriver.com
Tue Sep 11 01:30:16 UTC 2018


On 09/10/2018 06:24 PM, Burton, Ross wrote:
> On 10 September 2018 at 11:02, Chen Qi <Qi.Chen at windriver.com> wrote:
>> I met the following error when compiling some projects.
>>
>> | configure: error: `LDFLAGS' has changed since the previous run:
>> | configure:   former value:  `-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed'
>> | configure:   current value: `-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now'
>> [snip]
>> | configure: error: changes in the environment can compromise the build
>> | configure: error: run `make distclean' and/or `rm .././config.cache' and start over
>>
>> I think when some recipe inherits autotools-brokensep, it should try to
>> do more cleanups before configure. So also do 'make distclean' and remove
>> config.cache just as what the error message told us.
> Does just removing config.cache work for your problem?
I guess it should, but I haven't checked.
>    I'm concerned
> about running a distclean because some upstreams abuse that target and
> then can't rebuild.
Hmm... I hold the opposite opinion.
I suspect that just doing a `make clean' is more likely to break rebuild 
while doing a `make distclean' should reduce the possibility.

Conceptually, `make clean' is followed by `make' while `make distclean' 
is followed by `configure & make'.
At rebuild, we are doing `configure & make'; so we should use `make 
distclean', in theory.

I'll revisit this issue later and do more investigation.
> Also obviously the proper fix is to not use autotools-brokensep in the
> recipe in the first place.
You are right.
The recipe is cyrus-sasl and the newly updated version has fixed to use 
autotools instead of autotools-brokensep.

To summarize, ideally we should have no recipe inheriting 
autotools-brokensep. But in reality, it's almost not possible.
I sent out this patch because I thought it would be helpful for such 
recipes.

Best Regards,
Chen Qi

> Ross
>




More information about the Openembedded-core mailing list