Hello,
On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote:
> This commit enables getpt() support in ARC defconfigs as some packages
> need it. E.g. we need this to be able to build xterm package as it uses
> getpt().
>
> As an example I can refer to buildroot autobuilds where xterm build is
On 03/01/2017 07:25 AM, Thomas Petazzoni wrote:
> Hello,
>
> On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote:
>> This commit enables getpt() support in ARC defconfigs as some packages
>> need it. E.g. we need this to be able to build xterm package as it uses
>> getpt().
>>
>> As an example
Hi Vineet,
On Wed, 2017-03-01 at 10:00 -0800, Vineet Gupta wrote:
> On 03/01/2017 07:25 AM, Thomas Petazzoni wrote:
> >
> > Hello,
> >
> > On Tue, 28 Feb 2017 22:02:27 +0300, Vlad Zakharov wrote:
> > >
> > > This commit enables getpt() support in ARC defconfigs as some packages
> > > need it. E
On 03/01/2017 10:25 AM, Alexey Brodkin wrote:
>> That was
>> a fair requirement on their part but it kept bloating uClibc for our typical
>> embedded use. But this idea of minimal vs. full featured is exactly what we
>> need.
>> @Alexey / @vlad can we take this up please !
> Probably Waldemar's op
Hi everyone,
> > > That's more of a question for Waldemar: does it really makes sense
> > > to have defconfigs for each architecture? I mean how do they differ
> > > between each other?
> > >
> > > For example, the ARC arcv2_defconfig and defconfig only differ by
> > > the option CONFIG_ARC_CPU_HS
On 03/01/2017 10:57 AM, Anton Kolesov wrote:
>> That means for building of our toolchain we'll need to have separately stored
>> "defconfigs" in some form. Let's see what Anton says on that :)
But why is that - as long as buildroot (or other build systems) pass the right
cpu
flags - why do you ne
The newer prlimit64 syscall provides all the functionality provided by
the getrlimit and setrlimit syscalls and adds the pid of target process,
so future architectures won't need to include getrlimit and setrlimit.
Therefore drop getrlimit and setrlimit syscalls from the generic syscall
list unles
Hi,
Vineet Gupta wrote,
> On 03/01/2017 10:57 AM, Anton Kolesov wrote:
> >> That means for building of our toolchain we'll need to have separately
> >> stored
> >> "defconfigs" in some form. Let's see what Anton says on that :)
>
> But why is that - as long as buildroot (or other build systems)
Hello,
On Wed, 1 Mar 2017 18:25:35 +, Alexey Brodkin wrote:
> That means for building of our toolchain we'll need to have
> separately stored "defconfigs" in some form. Let's see what Anton says on
> that :)
>
> And regardless of what mr Anton says having off-the-tree defconfigs is not
> t
Hi Thomas,
On Wed, 2017-03-01 at 21:25 +0100, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 1 Mar 2017 18:25:35 +, Alexey Brodkin wrote:
>
> >
> > That means for building of our toolchain we'll need to have
> > separately stored "defconfigs" in some form. Let's see what Anton says on
> > th
Hello,
On Wed, 1 Mar 2017 21:30:31 +, Alexey Brodkin wrote:
> Speaking of "defconfigs" I really meant something that we may use
> for building our toolchain outside of Buildroot if we want something that
> differs from uClibc's defaults/defconfig - and most probably we'll need
> something
>
11 matches
Mail list logo
