[Buildroot] Depending on uClibc configuration variables

[Buildroot] Depending on uClibc configuration variables

[Daniel Mack]

Is there a clever way to depend on variables set in the uClibc
configuration directly in package Config.in files? Something like
UCLIBC_HAS_EPOLL for example?


Daniel

[Buildroot] Depending on uClibc configuration variables

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <zonque@gmail.com> writes:

 Daniel> Is there a clever way to depend on variables set in the uClibc
 Daniel> configuration directly in package Config.in files? Something like
 Daniel> UCLIBC_HAS_EPOLL for example?

Unfortunately not. We have tweaked the default uClibc config so that all
packages should build (or patched packages where needed), so it normally
shouldn't be needed.

I consider using a custom uClibc configuration an advanced feature,
where the user is supposed to know what they are doing (tm).

-- 
Bye, Peter Korsgaard

[Buildroot] Depending on uClibc configuration variables

[Daniel Mack]

On Wed, Jul 13, 2011 at 9:12 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Daniel" == Daniel Mack <zonque@gmail.com> writes:
>
> ?Daniel> Is there a clever way to depend on variables set in the uClibc
> ?Daniel> configuration directly in package Config.in files? Something like
> ?Daniel> UCLIBC_HAS_EPOLL for example?
>
> Unfortunately not. We have tweaked the default uClibc config so that all
> packages should build (or patched packages where needed), so it normally
> shouldn't be needed.
>
> I consider using a custom uClibc configuration an advanced feature,
> where the user is supposed to know what they are doing (tm).

The thing is that I have been teaching new DNS lookup functions to
libuClibc which will be built depending on a new config variable
switch. The puropose for this is to make connman build in buildroot,
and I have it running here already. However, to prevent breakage, I
would like to depend on this new uClibc configuration directive, so
people can't select the new package unless they have a recent uClibc
with this new option selected. How would I do this?


Thanks,
Daniel

[Buildroot] Depending on uClibc configuration variables

[Thomas Petazzoni]

Le Wed, 13 Jul 2011 16:26:22 +0200,
Daniel Mack <zonque@gmail.com> a ?crit :

> The thing is that I have been teaching new DNS lookup functions to
> libuClibc which will be built depending on a new config variable
> switch. The puropose for this is to make connman build in buildroot,
> and I have it running here already. However, to prevent breakage, I
> would like to depend on this new uClibc configuration directive, so
> people can't select the new package unless they have a recent uClibc
> with this new option selected. How would I do this?

Either we decide that this option doesn't add too much overhead to
uClibc, and we integrate it to the default uClibc configuration we
ship. Or, we create yet another toolchain config knob that connman can
depend on, and which would tune the uClibc configuration when enabled.

What is the binary size impact of having your option enabled in uClibc ?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Depending on uClibc configuration variables

[Daniel Mack]

On Wed, Jul 13, 2011 at 4:31 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Le Wed, 13 Jul 2011 16:26:22 +0200,
> Daniel Mack <zonque@gmail.com> a ?crit :
>
>> The thing is that I have been teaching new DNS lookup functions to
>> libuClibc which will be built depending on a new config variable
>> switch. The puropose for this is to make connman build in buildroot,
>> and I have it running here already. However, to prevent breakage, I
>> would like to depend on this new uClibc configuration directive, so
>> people can't select the new package unless they have a recent uClibc
>> with this new option selected. How would I do this?
>
> Either we decide that this option doesn't add too much overhead to
> uClibc, and we integrate it to the default uClibc configuration we
> ship. Or, we create yet another toolchain config knob that connman can
> depend on, and which would tune the uClibc configuration when enabled.
>
> What is the binary size impact of having your option enabled in uClibc ?

It adds ~5kb.

Daniel

[Buildroot] Depending on uClibc configuration variables

[Thomas Petazzoni]

Le Wed, 13 Jul 2011 16:36:28 +0200,
Daniel Mack <daniel@zonque.org> a ?crit :

> > What is the binary size impact of having your option enabled in uClibc ?
> 
> It adds ~5kb.

Then I would say that we can include the feature in our default uClibc
configuration.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Depending on uClibc configuration variables

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Le Wed, 13 Jul 2011 16:36:28 +0200,
 Thomas> Daniel Mack <daniel@zonque.org> a ?crit :

 >> > What is the binary size impact of having your option enabled in uClibc ?
 >> 
 >> It adds ~5kb.

 Thomas> Then I would say that we can include the feature in our default uClibc
 Thomas> configuration.

But it's the uClibc patches Daniel recently posted, isn't it? Those
afaik aren't integrated in uClibc git yet.

-- 
Bye, Peter Korsgaard

[Buildroot] Depending on uClibc configuration variables

[Daniel Mack]

On Wed, Jul 13, 2011 at 6:31 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> ?Thomas> Le Wed, 13 Jul 2011 16:36:28 +0200,
> ?Thomas> Daniel Mack <daniel@zonque.org> a ?crit :
>
> ?>> > What is the binary size impact of having your option enabled in uClibc ?
> ?>>
> ?>> It adds ~5kb.
>
> ?Thomas> Then I would say that we can include the feature in our default uClibc
> ?Thomas> configuration.

Ok, that's easy then.

> But it's the uClibc patches Daniel recently posted, isn't it? Those
> afaik aren't integrated in uClibc git yet.

No, I'm still waiting for review and it probably needs one or more
cycles to make it happen.

I'm just preparing patches for buildroot in parallel, and came across
this problem. So for the first shot, we would depend on a BR2
snapshot, and once a new release is ready, add this as dependency
option. Correct?

Daniel

[Buildroot] Depending on uClibc configuration variables

[Peter Korsgaard]

>>>>> "Daniel" == Daniel Mack <daniel@zonque.org> writes:

Hi,

 Daniel> No, I'm still waiting for review and it probably needs one or
 Daniel> more cycles to make it happen.

 Daniel> I'm just preparing patches for buildroot in parallel, and came
 Daniel> across this problem. So for the first shot, we would depend on
 Daniel> a BR2 snapshot, and once a new release is ready, add this as
 Daniel> dependency option. Correct?

Either that or backport it to 0.9.32.

-- 
Bye, Peter Korsgaard