* [Buildroot] Depending on uClibc configuration variables @ 2011-07-12 23:05 Daniel Mack 2011-07-13 7:12 ` Peter Korsgaard 0 siblings, 1 reply; 9+ messages in thread From: Daniel Mack @ 2011-07-12 23:05 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-12 23:05 [Buildroot] Depending on uClibc configuration variables Daniel Mack @ 2011-07-13 7:12 ` Peter Korsgaard 2011-07-13 14:26 ` Daniel Mack 0 siblings, 1 reply; 9+ messages in thread From: Peter Korsgaard @ 2011-07-13 7:12 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-13 7:12 ` Peter Korsgaard @ 2011-07-13 14:26 ` Daniel Mack 2011-07-13 14:31 ` Thomas Petazzoni 0 siblings, 1 reply; 9+ messages in thread From: Daniel Mack @ 2011-07-13 14:26 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-13 14:26 ` Daniel Mack @ 2011-07-13 14:31 ` Thomas Petazzoni 2011-07-13 14:36 ` Daniel Mack 0 siblings, 1 reply; 9+ messages in thread From: Thomas Petazzoni @ 2011-07-13 14:31 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-13 14:31 ` Thomas Petazzoni @ 2011-07-13 14:36 ` Daniel Mack 2011-07-13 16:24 ` Thomas Petazzoni 0 siblings, 1 reply; 9+ messages in thread From: Daniel Mack @ 2011-07-13 14:36 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-13 14:36 ` Daniel Mack @ 2011-07-13 16:24 ` Thomas Petazzoni 2011-07-13 16:31 ` Peter Korsgaard 0 siblings, 1 reply; 9+ messages in thread From: Thomas Petazzoni @ 2011-07-13 16:24 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-13 16:24 ` Thomas Petazzoni @ 2011-07-13 16:31 ` Peter Korsgaard 2011-07-13 16:36 ` Daniel Mack 0 siblings, 1 reply; 9+ messages in thread From: Peter Korsgaard @ 2011-07-13 16:31 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-13 16:31 ` Peter Korsgaard @ 2011-07-13 16:36 ` Daniel Mack 2011-07-13 17:15 ` Peter Korsgaard 0 siblings, 1 reply; 9+ messages in thread From: Daniel Mack @ 2011-07-13 16:36 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Buildroot] Depending on uClibc configuration variables 2011-07-13 16:36 ` Daniel Mack @ 2011-07-13 17:15 ` Peter Korsgaard 0 siblings, 0 replies; 9+ messages in thread From: Peter Korsgaard @ 2011-07-13 17:15 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-07-13 17:15 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-12 23:05 [Buildroot] Depending on uClibc configuration variables Daniel Mack 2011-07-13 7:12 ` Peter Korsgaard 2011-07-13 14:26 ` Daniel Mack 2011-07-13 14:31 ` Thomas Petazzoni 2011-07-13 14:36 ` Daniel Mack 2011-07-13 16:24 ` Thomas Petazzoni 2011-07-13 16:31 ` Peter Korsgaard 2011-07-13 16:36 ` Daniel Mack 2011-07-13 17:15 ` Peter Korsgaard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.