On Tue, Aug 23, 2011 at 07:12:39AM +0200, Laurent Bercot wrote:
I understand about static/dynamic linking, but would prefer dynamic to keep
memory usage down
You are falling for a widespread myth.
1. Build a static tcpsvd+httpd busybox with an Aboriginal Linux toolchain.
2. Run it,
On Tue, Aug 23, 2011 at 02:29:58PM +1200, Ian Barnes wrote:
Hopefully I have picked a suitable list for this question, I realise this
isn't strictly a development question - but I couldn't find a better place
to ask.
I have an embedded appliance running linux that I am trying to build a tool
On Sat, Jun 11, 2011 at 11:16:48PM +0200, Laurent Bercot wrote:
Suspecting is a dangerous business. :)
There are many, many more customers of uClibc that do not necessarily
use buildroot or OpenEmbedded. Every company that works with embedded
systems and knows what it's doing (granted,
On Mon, Jun 13, 2011 at 08:42:31PM +0200, Laurent Bercot wrote:
I use uclibc as released, gcc from fsf, linux kernel from kernel.org, etc.
It isn't really that hard to do. Or maybe I am just weird.
http://uclibc.org/FAQ.html#compiling
#toolchain
On Fri, Mar 18, 2011 at 09:29:53AM -0500, Rob Landley wrote:
On 03/18/2011 09:25 AM, Bernhard Reutner-Fischer wrote:
Rob Landley rland...@parallels.com wrote:
On 03/16/2011 02:44 PM, Bernhard Reutner-Fischer wrote: Hi,
I'm happy to announce that we now have a 0.9.32-rc3. This
On Fri, Mar 18, 2011 at 10:57:36AM -0400, Lennart Sorensen wrote:
Perhaps V=0 could show quiet + defines, V=1 could show commands.
That would give the new feature and be backwards compatible.
Certainly completely changing an existing behaviour doesn't seem very
nice.
So for example:
diff
On Mon, May 03, 2010 at 08:14:38AM +0300, Timo Teräs wrote:
Yes, static linking would be more bullet proof. But either the user, or
the package manager needs jump through hoops in this case. There needs to
be the static versions compiled, they need to get installed, then finally
replaced with
On Mon, May 03, 2010 at 05:16:29PM +0200, Natanael Copa wrote:
because you want avoid 10 times bigger binary? (alpine linux's
apk-tools is 90k dynamic and 900k static due to libcrypto for
hashing/signing)
Wow that does sound pretty big.
Yes for upgrade, I'll probably recommend do that with
On Wed, Mar 17, 2010 at 09:24:17AM -0400, Jim Burnett wrote:
Fresh binutils-2.19 build (Just re-ran make install to get /opt/embedded
fresh)
export PATH=/opt/embedded:$PATH
I built binutils with --target=m68k-uclinux. Make sure you match any
prefix option with how you intend to install gcc
On Tue, Mar 16, 2010 at 03:10:48PM -0400, Jim Burnett wrote:
Hey everyone,
I've been working on getting a build environment up for our Coldfire (m68k)
chips for some time now. Today I tried to compile your latest version of
uClib, 0.9.30.3 .
0.9.30.1 compiles for coldfire if you comment out
On Wed, Mar 03, 2010 at 07:01:05PM +0100, Bernhard Reutner-Fischer wrote:
During the weekend I've been pondering to release master as 0.9.31 now
(without NPTL), branch it so we can cleanup master after the NPTL merge.
In my mind this would be the best approach:
.plan is now:
tag 0.9.30.3
On Wed, Mar 03, 2010 at 09:04:11PM +0100, Peter Korsgaard wrote:
Lennart == Lennart Sorensen lsore...@csclub.uwaterloo.ca writes:
Hi,
Lennart Sounds good to me. Certainly as far as coldfire is concerned,
Lennart the master works fine, while the 0.9.30 branch is broken. The
Lennart
On Wed, Mar 03, 2010 at 10:45:18PM +0100, Pirmin Walthert wrote:
Busybox 0.16.0 works great for me with 0.9.30.2 on x86 (Geode LX and
Quad Xeon)
OK, so then it's just m68k having issues. Less of a problem then, and
given the master branch works fine, it probably isn't worth looking
into
On Wed, Mar 03, 2010 at 02:44:38PM -0800, Khem Raj wrote:
Because efforts would be spend on releasing .31 and merging/ creating
another RC immediately after
will divide the efforts.
I would like a release that works on m68k. The current master tree does.
So why wait for NPTL?
Now if NPTL can
On Sat, Feb 20, 2010 at 07:22:28PM +0100, Bernhard Reutner-Fischer wrote:
I'd like to do a maintenance 0.9.30.3 release soon (in a week or so).
If you have patches/fixes that should be backported from master then
please say so now (or push non-controversial fixes right to the branch).
PS:
On Mon, Jan 11, 2010 at 11:24:36PM -0600, Rob Landley wrote:
In the git -devel branch I see an INTERNAL_SYSCALL but no INLINE_SYSCALL.
The final release of uClibc has neither.
0.9.30.1 certainly does not. I guess that is the latest release.
Actually my main problem with looking at what's
On Sat, Dec 19, 2009 at 04:30:15AM +0100, Bernhard Reutner-Fischer wrote:
On Tue, Oct 13, 2009 at 10:14:13AM -0400, Lennart Sorensen wrote:
On Mon, Oct 12, 2009 at 10:16:24PM +0200, Bernhard Reutner-Fischer wrote:
On Mon, Oct 12, 2009 at 08:38:31PM +0200, Stephan Raue wrote:
Hi Bernhard
On Tue, Dec 15, 2009 at 05:16:05PM +0100, Niko Lau wrote:
I want to use the libv4l2 for my arm platform with uclibc cross compiler.
When I link a appl with that lib I get the following error:
arm-linux-uclibc-gcc -Wall -O2 -g -I../libv4l2/include
-L../libv4l2/lib -o capture capture.c -lv4l2
On Tue, Dec 15, 2009 at 05:31:01PM +0100, Niko Lau wrote:
2009/12/15 Lennart Sorensen lsore...@csclub.uwaterloo.ca:
On Tue, Dec 15, 2009 at 05:16:05PM +0100, Niko Lau wrote:
I want to use the libv4l2 for my arm platform with uclibc cross compiler.
When I link a appl with that lib I get
On Mon, Nov 09, 2009 at 10:00:22AM +0100, Peter Lukac wrote:
On Friday 06 November 2009 04:49:53 pm you wrote:
On Fri, Nov 06, 2009 at 04:15:14PM +0100, Peter Lukac wrote:
Hello,
I use uclibc version 0.9.29 on arm.
I think that function printf not work right with precision for string.
On Mon, Oct 12, 2009 at 10:16:24PM +0200, Bernhard Reutner-Fischer wrote:
On Mon, Oct 12, 2009 at 08:38:31PM +0200, Stephan Raue wrote:
Hi Bernhard,
i will trying this branch.
can you include:
http://git.uclibc.org/uClibc/commit/?id=1b6ff11554c7a1fea728167cc814db5440da289c
I'd rather
On Thu, Aug 13, 2009 at 07:00:55AM -0400, Mike Frysinger wrote:
On Tuesday 04 August 2009 15:28:04 Maxim Kuvyrkov wrote:
Maxim Kuvyrkov wrote:
Mike Frysinger wrote:
On Wednesday 22 July 2009 10:49:00 Maxim Kuvyrkov wrote:
As described in thread
On Thu, Jul 09, 2009 at 06:24:54PM -0400, Mike Frysinger wrote:
On Monday 06 July 2009 10:40:35 Lennart Sorensen wrote:
On Sun, Jul 05, 2009 at 06:28:32PM -0400, Mike Frysinger wrote:
On Friday 03 July 2009 16:50:22 Mike Frysinger wrote:
Unify all the common syscall defines in syscalls
On Fri, Jul 03, 2009 at 03:56:54PM -0400, Mike Frysinger wrote:
On Tuesday 14 April 2009 14:13:21 Lennart Sorensen wrote:
Commit 26002 attemps to implement the deamon() call on nommu systems.
It unfortunately did so using INTENAL_SYSCALL which doesn't exist on m68k,
and hence compiles
On Sun, Jul 05, 2009 at 06:28:32PM -0400, Mike Frysinger wrote:
On Friday 03 July 2009 16:50:22 Mike Frysinger wrote:
Unify all the common syscall defines in syscalls-common.h and scrub all
the duplicated code from relevant ports. This should also make converting
existing ports to
On Sun, May 10, 2009 at 11:38:34PM +0200, Christian MICHON wrote:
On Sun, May 10, 2009 at 11:08 PM, Mike Frysinger vap...@gentoo.org wrote:
On Saturday 09 May 2009 20:37:28 Kyle Sallee wrote:
please do not top post
unfortunately the default when using gmail :(
No it isn't. The default
On Mon, May 04, 2009 at 11:11:47AM +0100, Bernd Schmidt wrote:
Lennart Sorensen wrote:
On Mon, Apr 20, 2009 at 02:39:06PM -0400, Lennart Sorensen wrote:
I decided to try the blackfin version of elf2flt entirely, since it also
seems to have a fix for c++ support (not that I have any plans
On Thu, Apr 30, 2009 at 04:08:19PM -0400, Mike Frysinger wrote:
On Saturday 18 April 2009 20:51:04 v...@uclibc.org wrote:
Author: vda
Date: 2009-04-19 00:51:04 + (Sun, 19 Apr 2009)
New Revision: 26155
Log:
Reinstate {drm,mtd,rdma,sound,video} directory installtion
pending some
On Tue, Apr 21, 2009 at 09:47:04AM +1000, David McCullough wrote:
If someone wants to work up a patch for the uclinux.org version that
fixes this (but still has a configure option or something to allow it to
be used for older toolchains with busted CTOR/DTOR support) I will gladly
add it.
On Wed, Apr 22, 2009 at 09:01:48AM +1000, David McCullough wrote:
Originally we had thought about having ld-elf2flt remove the mostly
likely offending .o's from the link line so that elf2flt's CTOR/DTOR
support would always work whether the toolchain included working
CTOR/DTOR support or not.
On Sat, Apr 18, 2009 at 12:46:44PM +0100, Bernd Schmidt wrote:
Lennart Sorensen wrote:
I now wonder if there is a bug in that gcc 4.3 code, or in the linker
messing up the ordering, or possibly in the elf2flt tool.
The mainline version of elf2flt sets __[CD]TOR_LIST__ and
__[CD]TOR_END__
On Mon, Apr 20, 2009 at 12:20:13PM -0400, Robin Getz wrote:
I think this is pretty common with many open source tools. Every distribution
maintainer wants to make a tweak - and not always sends it upstream. When
they do send it upstream - the patch can be rejected by the mainline
maintainer
On Mon, Apr 20, 2009 at 01:00:04PM -0400, Lennart Sorensen wrote:
For example - there is a huge difference between a RedHat kernel, and
kernel.org. Most Debian userspace packages are heavily patched - yeah, it
kind of stinks - but that is what diff is for
No, that's what
On Mon, Apr 20, 2009 at 01:46:50PM -0400, Lennart Sorensen wrote:
Actually I find it interesting to look at blackfin's version of elf2flt.
This particular CTOR/DTOR bug was fixed 2007-08-30, then reintroduced
2008-11-06 because someone grabbed changes from upstream, and then fixed
again 2008
On Thu, Apr 16, 2009 at 05:05:20PM -0400, Lennart Sorensen wrote:
I tried initializing it to 0, and no help.
Now I also treid changing -1 to -3 and that made it no longer blow up
(perhaps because it no longer has anything to call).
The last element should be NULL.
My understanding
On Wed, Apr 15, 2009 at 01:53:01PM -0400, Lennart Sorensen wrote:
I am trying to track down why all my programs terminate with Illegal
instruction.
My test program currently is:
int main() {
return 42;
}
When compiled using gcc 4.3.3+binutils 2.19.1 for m68k-uclinux
On Thu, Apr 16, 2009 at 10:12:26AM -0400, Lennart Sorensen wrote:
On Wed, Apr 15, 2009 at 01:53:01PM -0400, Lennart Sorensen wrote:
I am trying to track down why all my programs terminate with Illegal
instruction.
My test program currently is:
int main() {
return 42
I am trying to track down why all my programs terminate with Illegal
instruction.
My test program currently is:
int main() {
return 42;
}
When compiled using gcc 4.3.3+binutils 2.19.1 for m68k-uclinux with the command:
m68k-uclinux-gcc -mcpu=5271 -msep-data -Wall -o test42 test42.c
I
Commit 26002 attemps to implement the deamon() call on nommu systems.
It unfortunately did so using INTENAL_SYSCALL which doesn't exist on m68k,
and hence compiles of m68k nommu now fail.
I suspect it should be using something similar to _exit.c to access
the clone and exit syscalls, or one of
39 matches
Mail list logo
