From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH,V2 0/6] libtool 2.4 upgrade
Date: Sat, 09 Oct 2010 12:37:25 +0200 [thread overview]
Message-ID: <i8pgl5$8n1$1@dough.gmane.org> (raw)
In-Reply-To: <AANLkTikLT9ZRLbnbGQ17AN5u0TiXdweP7HKH-QuLBH_E@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09-10-10 00:21, Chris Larson wrote:
> On Fri, Oct 8, 2010 at 1:48 PM, Frans Meulenbroeks <
> fransmeulenbroeks@gmail.com> wrote:
>
>> 2010/10/7 Khem Raj <raj.khem@gmail.com>:
>>> On Thu, Oct 7, 2010 at 12:56 AM, Koen Kooi <k.kooi@student.utwente.nl>
>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 07-10-10 03:46, Khem Raj wrote:
>>>>> Hi
>>>>>
>>>>> Following set of patches is v2 of the patches adding support for
>> getting libtool 2.4 into
>>>>> openemebedded. I have so far built minimal-image for two machines
>> successfully using old
>>>>> and new libtool.
>>>>>
>>>>> The libtool sysroot feature knob is added through LIBTOOL_HAS_SYSROOT
>> variable. If this is
>>>>> set to "yes" then you ought to use libtool > 2.4 by default its set to
>> "no" which means
>>>>> the current behavior remains.
>>>>>
>>>>> The big change that libtool 2.4 brings is sysroot support and I have
>> added
>>>>> support to use this feature. It should make our life easier.
>>>>>
>>>>> This needs a lot of testing.
>>>>>
>>>>> Please cherry pick the patch bundle and give it a try in yout
>> environment
>>>>
>>>> Can you apply these to a branch so we can add fixes there if needed?
>>>
>>> I can do that. However now that backward compatibility is left intact I
>> think
>>> it would not be that bad to merge it into master and fix things on
>>> master. the libtool
>>> 2.4 would have DEFAULT_PREFERENCE = "-1" by default it wont be picked by
>> anyone.
>>> with the number of developers we have it will get better testing before
>> we
>>> accumulate too many changes on a branch. Secondly there might be changes
>> like
>>> gnutls one where the patch is only valid for new libtool and should be
>> tested
>>> in old and new way. If there is any breakage introduced in existing build
>> will
>>> be caught quickly. Where as on branch resources might be divided and it
>> may
>>> not progress so well. I am just weighing efforts Vs. risk here and
>>> risk seems low
>>>
>>> Thanks
>>> -Khem
>>>
>>>>
>>
>> Personally I'm in favour of merging into head. That way it gets
>> accepted easier and faster.
>>
>
> Agreed, I am as well. As the new libtool is opt-in, I don't see the harm,
> and it'll ensure that any issues which crop up with the compatibility get
> fixed asap.
Yeah, let's get this in!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFMsEXlMkyGM64RGpERAsjyAKCc6eHVMBOfE27SW20BiCWvs7mdXACfYG6I
1zsti6PHxpCCOGHvqWBw4zI=
=4QWi
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2010-10-09 10:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-07 1:46 [PATCH,V2 0/6] libtool 2.4 upgrade Khem Raj
2010-10-07 1:46 ` [PATCH,V2 1/6] libtool-2.4: Add recipes for libtool 2.4 Khem Raj
2010-10-07 1:46 ` [PATCH,V2 2/6] bitbake.conf: Define LIBTOOL_HAS_SYSROOT Khem Raj
2010-10-07 1:46 ` [PATCH, V2 3/6] autotools.bbclass: Conditionally use autotools_prepackage_lamangler Khem Raj
2010-10-07 1:46 ` [PATCH, V2 4/6] cross.bbclass, staging.bbclass, utils.bbclass: Make sure that .la munging is not done for libtool > 2.4 Khem Raj
2010-10-07 1:46 ` [PATCH, V2 5/6] insane.bbclass: If LIBTOOL_HAS_SYSROOT is set then do not check for la insanity Khem Raj
2010-10-07 1:46 ` [PATCH, V2 6/6] gnutls_2.10.1.bb: Update to libtools 2.4 macros Khem Raj
2010-10-07 7:56 ` [PATCH,V2 0/6] libtool 2.4 upgrade Koen Kooi
2010-10-07 18:31 ` Khem Raj
2010-10-07 22:56 ` Graham Gower
2010-10-07 23:16 ` Graham Gower
2010-10-08 20:48 ` Frans Meulenbroeks
2010-10-08 22:21 ` Chris Larson
2010-10-09 10:37 ` Koen Kooi [this message]
2010-10-09 11:37 ` Martin Jansa
2010-10-09 14:31 ` Khem Raj
2010-10-09 15:15 ` Koen Kooi
2010-10-09 16:45 ` Frans Meulenbroeks
2010-10-11 13:13 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='i8pgl5$8n1$1@dough.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox