hmm.. I compiled busybox 1.3.2 and turned on libbusybox option.
After that, the libbusybox.so cannot be found.
Colin
- Original Message -
From: "Denys Vlasenko" <[EMAIL PROTECTED]>
To:
Cc: "colin" <[EMAIL PROTECTED]>
Sent: Thursday, September 13, 2007 11:44 PM
Subject: Re: Is libbusyb
Denys Vlasenko wrote:
> On Wednesday 12 September 2007 22:18, Nathan Angelacos wrote:
> I have a question about busybox httpd and its cgi environment: Is there
> a way to setup and/or access environment variables other than the
> variables that are defined by the common gateway interfa
On Thursday 13 September 2007 17:28, Stephane Cerveau wrote:
> Hi,
>
> I'm using busybox 1.1.0 and encounter a problem with a kernel thread in
> a char driver.
> I have a char driver using a kernel thread awaken(it reads data in a
> registry) when it receive an interrupt signal.
> When I insert
Hi,
I'm using busybox 1.1.0 and encounter a problem with a kernel thread in
a char driver.
I have a char driver using a kernel thread awaken(it reads data in a
registry) when it receive an interrupt signal.
When I insert the driver (insmod) and read data in the dev file
(/dev/toto:name of my dev
On Wednesday 12 September 2007 22:18, Nathan Angelacos wrote:
> >>> I have a question about busybox httpd and its cgi environment: Is there
> >>> a way to setup and/or access environment variables other than the
> >>> variables that are defined by the common gateway interface?
> >> CGI cannot "set
On Thursday 13 September 2007 08:28, colin wrote:
>
> Hi all,
> Our platform is with low cpu power and an application using "system" api too
> many times will draw down cpu performance.
> These statements are like system("/bin/mkdir ..."), system("/bin/touch
> ..."), ... and system("/bin/rm ...").
This toolchain was made by tool call ltib from bitshrine.org. Changing
the toolchain mid project is not an option for us. Probably before the
next I will.
thanks,
Pb
Brian Austin wrote:
did you make that toolchain yourself?
I would suggest using a 4.x with a 2.3.4 of higher c library
Hi,
Attatched is a patch that fixes the annoying bug in ash prmpt expansion.
Currently the default PS1='\w \$ ' will always show a '$' as prompt
while PS1='\w \\$ ' will show a '#' if effective user is root and '$'
otherwise.
The problem is that the prompt string is expanded as a normal double
q
On Thu, Sep 13, 2007 at 03:28:50PM +0800, colin wrote:
>
>Hi all,
>Our platform is with low cpu power and an application using "system" api too
>many times will draw down cpu performance.
>These statements are like system("/bin/mkdir ..."), system("/bin/touch
>..."), ... and system("/bin/rm ...").
Those are all file system call operations,... which will be supported
by whichever C library you are using on you're devices.
>From my reading of the matter libbusybox.so would be more suited to
writing additional utilities that need to directly at an API level
interact with Busybox and its applet
Sorry, I meant between 1.5 and 1.6. The 1.5 and 1.4 have
essentially the same run_parts.c
cheers,
Tommi
Tommi Kyntola wrote:
> I tried searching the mailing list briefly about this, but
> couldn't find anything about the lexicographical sort order
> having been changed in run-parts, but it seems
Hi all,
Our platform is with low cpu power and an application using "system" api too
many times will draw down cpu performance.
These statements are like system("/bin/mkdir ..."), system("/bin/touch
..."), ... and system("/bin/rm ...").
I am thinking if the application is linked with libbusybox.so
I tried searching the mailing list briefly about this, but
couldn't find anything about the lexicographical sort order
having been changed in run-parts, but it seems like it has.
Scripts used to be run in sorted order, but that's no longer the case.
The change took place between 1.4.2 to 1.5.0 w
13 matches
Mail list logo
