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
2010/5/3 Lennart Sorensen lsore...@csclub.uwaterloo.ca:
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,
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
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)
So what? libcrypto obviously wasn't designed for embedded
environments. In fact, it's probably the most bloated free crypto
library around. If the
On 05/02/2010 12:45 PM, Roman I Khimov wrote:
Temporary file name template passed to __gen_tempname had no XX in it,
so __gen_tempname returned EINVAL which led to sem_open failure.
Thanks, applied.
-Austin
___
uClibc mailing list
On 04/30/2010 07:18 AM, Roman I Khimov wrote:
They were present in sources, but not compiled in. Generic routines are
broken badly on x86_64, even basic threading test like pthread/ex1 didn't
work with them.
Signed-off-by: Roman I Khimov khi...@altell.ru
Applied thanks
-Austin
On 04/30/2010 07:18 AM, Roman I Khimov wrote:
Generic ones were broken on x86_64, pthread/ex2 test failed while pthread/ex5
worked fine. So use arch-specific functions and fix linkage failure with
__pthread_mutex_cond_lock_adjust.
Signed-off-by: Roman I Khimov khi...@altell.ru
Applied
