On Tuesday 21 July 2009 19:24, Bernhard Reutner-Fischer wrote:
> On Tue, Jul 21, 2009 at 07:07:54PM +0200, Denys Vlasenko wrote:
>
> >> In my POV this is a configuration issue and not libc's business.
> >
> >Then why do we have KERNEL_HEADERS?
>
> So add the hunks that CFLAGS+=-I$(KERNEL_HEADERS)
I accidentally wandered into sparc arch and noticed this:
int
__libc_sigaction (int sig, __const struct sigaction *act, struct sigaction
*oact)
{
int ret;
struct old_kernel_sigaction kact, koact;
unsigned long stub = 0;
int saved_errno = errno;
if (act)
{
kact.k_s
On Wednesday 22 July 2009 00:26, Bernhard Reutner-Fischer wrote:
> On Tue, Jul 21, 2009 at 03:36:03PM +0200, Denys Vlasenko wrote:
> >On Tue, Jul 21, 2009 at 4:01 AM, Mike Frysinger wrote:
> >>> Please try attached patch. For me it compiles. Resulting code
> >>> from memchr(buffer, '\n', pending):
On Mon, Jul 20, 2009 at 04:49:00PM -0400, Mike Frysinger wrote:
>seems to build for me ... any comments before i commit ?
looks ok at a glance, please install.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
On Tuesday 21 July 2009 23:04, Mike Frysinger wrote:
> On Tuesday 21 July 2009 11:21:59 Denys Vlasenko wrote:
> > I remember I fixed it by introducing and using install_kernel_headers.
> >
> > I check the git log and the last commit regarding that is:
> >
> > commit 56ecf3ceca20ba5b1f41f9deba013411
On Tue, Jul 21, 2009 at 03:36:03PM +0200, Denys Vlasenko wrote:
>On Tue, Jul 21, 2009 at 4:01 AM, Mike Frysinger wrote:
>>> Please try attached patch. For me it compiles. Resulting code
>>> from memchr(buffer, '\n', pending):
>>
>> fixes building for me, but please unify the branches before committ
On Tue, Jul 21, 2009 at 10:16:54PM +0100, Ed W wrote:
> Denys Vlasenko wrote:
>> On Monday 20 July 2009 22:23, Ed W wrote:
>>
>>> Ed W wrote:
>>>
>>>
>>> Below is the backtrace from the crash - can anyone please help
>>> interpret? Looks like an issue with getaddrinfo and the
>>> SUPPOR
Denys Vlasenko wrote:
On Monday 20 July 2009 22:23, Ed W wrote:
Ed W wrote:
Below is the backtrace from the crash - can anyone please help
interpret? Looks like an issue with getaddrinfo and the
SUPPORT_AI_ADDRECONFIG option?
It appears in __check_pf() getifaddrs() returned inc
On Tuesday 21 July 2009 11:21:59 Denys Vlasenko wrote:
> I remember I fixed it by introducing and using install_kernel_headers.
>
> I check the git log and the last commit regarding that is:
>
> commit 56ecf3ceca20ba5b1f41f9deba0134112b59f961
> Author: Denis Vlasenko
> Date: Sat Apr 18 23:45:13
On Tuesday 21 July 2009 15:39:57 Denys Vlasenko wrote:
> On Tuesday 21 July 2009 18:59, Ron wrote:
> > On Tue, Jul 21, 2009 at 06:17:02PM +0200, Denys Vlasenko wrote:
> > > On Tue, Jul 21, 2009 at 5:31 PM, Bernhard Reutner-Fischer wrote:
> > > > Mike removed it since it's not libc's business to ins
On Tuesday 21 July 2009 13:07:54 Denys Vlasenko wrote:
> On Tue, Jul 21, 2009 at 7:07 PM, Bernhard Reutner-Fischer wrote:
> >>Yes. I want to do that. I set up KERNEL_HEADERS so that uclibc
> >>build machinery should know where it is. The proof is that
> >>"make" succeeds.
> >>
> >>So uclibc does no
On Tuesday 21 July 2009 18:59, Ron wrote:
> On Tue, Jul 21, 2009 at 06:17:02PM +0200, Denys Vlasenko wrote:
> > On Tue, Jul 21, 2009 at 5:31 PM, Bernhard
> > Reutner-Fischer wrote:
> >
> > > Mike removed it since it's not libc's business to install kernel
> > > headers (and i agree with him, fwiw)
On Tue, Jul 21, 2009 at 07:07:54PM +0200, Denys Vlasenko wrote:
>> In my POV this is a configuration issue and not libc's business.
>
>Then why do we have KERNEL_HEADERS?
So add the hunks that CFLAGS+=-I$(KERNEL_HEADERS) from Rules.mk to
the shadow-copy in test/
__
On Tue, Jul 21, 2009 at 7:07 PM, Bernhard
Reutner-Fischer wrote:
>>Yes. I want to do that. I set up KERNEL_HEADERS so that uclibc
>>build machinery should know where it is. The proof is that
>>"make" succeeds.
>>
>>So uclibc does not require kernel headers to be installed
>>into any particular dire
On Tue, Jul 21, 2009 at 06:17:02PM +0200, Denys Vlasenko wrote:
> On Tue, Jul 21, 2009 at 5:31 PM, Bernhard
> Reutner-Fischer wrote:
>
> > Mike removed it since it's not libc's business to install kernel
> > headers (and i agree with him, fwiw).
I'll agree with that too while we're at it :)
> Ok
On Tue, Jul 21, 2009 at 06:48:08PM +0200, Denys Vlasenko wrote:
>On Tue, Jul 21, 2009 at 6:34 PM, Bernhard
>Reutner-Fischer wrote:
>> On Tue, Jul 21, 2009 at 06:17:02PM +0200, Denys Vlasenko wrote:
You have to have a properly installed set of kernel-headers before
you build the libc, real
On Tue, Jul 21, 2009 at 06:51:15PM +0200, Denys Vlasenko wrote:
>Hi,
>
>This patch undoes my old mistake. I added UCLIBC_INTERNAL define,
>but later I realized _LIBC is doing exactly the same thing.
>
>This patch converts all usages of UCLIBC_INTERNAL to _LIBC,
>removing all instances of UCLIBC_INT
Hi,
This patch undoes my old mistake. I added UCLIBC_INTERNAL define,
but later I realized _LIBC is doing exactly the same thing.
This patch converts all usages of UCLIBC_INTERNAL to _LIBC,
removing all instances of UCLIBC_INTERNAL.
Please review.
--
vda
3.patch
Description: Binary data
__
On Tue, Jul 21, 2009 at 06:17:02PM +0200, Denys Vlasenko wrote:
>> Mike removed it since it's not libc's business to install kernel
>> headers (and i agree with him, fwiw).
>
>Ok, then how can I test uclibc _before_ I install it?
>I can build it becuase I have correctly set up KERNEL_HEADERS="xxx",
On Tue, Jul 21, 2009 at 5:31 PM, Bernhard
Reutner-Fischer wrote:
> On Tue, Jul 21, 2009 at 05:21:59PM +0200, Denys Vlasenko wrote:
>>I am trying to run the testsuite.
>
> $ make help | grep testsuite
> check - run testsuite
> test_compile - compile testsuite binaries
# m
On Tue, Jul 21, 2009 at 05:21:59PM +0200, Denys Vlasenko wrote:
>I am trying to run the testsuite.
$ make help | grep testsuite
check - run testsuite
test_compile - compile testsuite binaries
>
># make compile
>...
>...
>make[1]: Nothing to be done for `compile'.
> T
I am trying to run the testsuite.
# make compile
...
...
make[1]: Nothing to be done for `compile'.
TEST_LINK assert/ assert
In file included from ../../install_dir/usr/include/signal.h:354,
from assert.c:14:
../../install_dir/usr/include/bits/sigcontext.h:31:29: error:
asm/sigc
On Mon, Jul 20, 2009 at 10:10 AM, Mike Frysinger wrote:
> On Friday 24 October 2008 11:00:19 Hamish Guthrie wrote:
>> I have been scratching through the trunk code and mailing lists to no
>> avail - has anyone implemented openat and family of functions?
>
> if it isnt in the source code, then no on
On Tue, Jul 21, 2009 at 4:01 AM, Mike Frysinger wrote:
>> Please try attached patch. For me it compiles. Resulting code
>> from memchr(buffer, '\n', pending):
>
> fixes building for me, but please unify the branches before committing
Sorry. What does it mean "unify the branches"?
--
vda
__
24 matches
Mail list logo
