Re: [Crash-utility] [PATCH makedumpfile v2 0/4] LZO Compression Support
Hello Kumagai-san,
From: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile v2 0/4] LZO Compression Support
Date: Wed, 28 Mar 2012 14:18:09 +0900
Hello Hatayama-san,
On Fri, 23 Mar 2012 17:26:08 +0900 ( )
HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> BTW, I have a question about future build option of LZO library. You
> said previously you're going to introduce autotools. Then, do you
> consider default enable if LZO library is present on the environment?
I'm afraid I decide not to introduce autotools for the following reasons.
It's OK if you don't have plan to use autotools.
First, because autotools cannot know whether LZO library is prepared
in
2nd kernel environment, it cannot decide whether it should link LZO library
dynamically even if LINKTYPE=dynamic is specified.
Yes, I of course agree with the fact that makedumpfile for kdump 2nd
kernel should always be built in statically linked way.
But I think two problems are different, that is, the problem making
users easily able to choose build option by autotools, and the problem
guranteeing that the makedumpfile for kdump 2nd kernel be built always
statically.
Second, if autotools behaves differently depending on LINKTYPE, it is
difficult
for users to understand.
If autotools were introduced, then I think we would no longer use
LINKTYPE and we would choose building option through autotools
features. For example, through new options in configure script such as
--enable-lzo-{static,dynamic} for example?
So, I think that current method is simpler and better than autotools.
I agree. I think simpler one is better if it's enough for the purpose.
Thanks.
HATAYAMA, Daisuke