uclibc

Cross compile PHP with UCLIBC

由 微笑、不失礼 提交于 2019-12-08 16:05:02
问题 THIS IS A REPOST, PREVIOUS POST GOT CLOSED, MOVED TO SERVERFAULT AND CLOSED AGAIN. I think this post is a valid stackoverflow problem because i think its caused by some automake/compile/linking error. This is a programming problem not a server admin problem. Cross compile PHP https://serverfault.com/questions/418521/cross-compile-php Start of post I have downloaded the PHP 5.4.0 source, extracted it and moved into the source folder. I do a configure with: ./configure --build=x86_64-unknown

Aliasing of symbol using GCC/binutils works intermittently

由 一个人想着一个人 提交于 2019-12-07 13:02:54
问题 I'm working on some software which for a limited time runs bare-metal until the Linux port is ready for prime time. The software is being linked against uClibc which provides implementations of malloc, clock_gettime etc, but the problem is that they all rely on syscalls which will just trap the hardware since we don't have a kernel to handle them yet. I have been using aliasing to override the functions that we need, i.e. our_mem.c: void* our_malloc(size_t size) { .. } void* malloc(size_t

Can GHC link binaries against a libc implementation such as uclibc (used in OpenWrt by default)?

由 ε祈祈猫儿з 提交于 2019-12-05 17:59:21
问题 I am using Debian/MIPS+QEMU to build MIPS ports of PortFusion (a TCP tunneling solution). The resulting binaries are linked against GNU libc. Thus, they cannot be just copied over and used on vanilla OpenWrt which ships with uclibc instead of eglibc (which seems binary-compatible with GNU libc). Is there a way to link Haskell/GHC binaries on Debian/MIPS against uclibc instead of eglibc ? Can OpenWrt's using uclibc be really the reason why PortFusion binaries copied over from Debian fail to

Can GHC link binaries against a libc implementation such as uclibc (used in OpenWrt by default)?

由 拈花ヽ惹草 提交于 2019-12-04 02:59:46
I am using Debian/MIPS+QEMU to build MIPS ports of PortFusion (a TCP tunneling solution). The resulting binaries are linked against GNU libc. Thus, they cannot be just copied over and used on vanilla OpenWrt which ships with uclibc instead of eglibc (which seems binary-compatible with GNU libc). Is there a way to link Haskell/GHC binaries on Debian/MIPS against uclibc instead of eglibc ? Can OpenWrt's using uclibc be really the reason why PortFusion binaries copied over from Debian fail to run with -ash: binary not found or can this message be due to something entirely else? See https://github

Any porting available of backtrace for uclibc?

由 情到浓时终转凉″ 提交于 2019-11-29 02:02:19
We are running the uclibc linux on ARM 9. The problem is uclibc doesn't support backtrace. When a core dump happens, I cannot grab the call stack. Does anyone have a good solution for that? For example, an existing porting of backtrace for uclibc, or any good method to grab the call stack when a core dump happens (uclibc+ARM+Linux)? Update: It seems that a patch was created to support backtrace() on uclibc for x86 and ARM (XScale) and it makes use of the __libc_stack_end symbol. Original Answer: I worked on a project where the version of glibc we were using did not provide a functional

Any porting available of backtrace for uclibc?

由 浪尽此生 提交于 2019-11-27 21:51:05
问题 We are running the uclibc linux on ARM 9. The problem is uclibc doesn't support backtrace. When a core dump happens, I cannot grab the call stack. Does anyone have a good solution for that? For example, an existing porting of backtrace for uclibc, or any good method to grab the call stack when a core dump happens (uclibc+ARM+Linux)? 回答1: Update: It seems that a patch was created to support backtrace() on uclibc for x86 and ARM (XScale) and it makes use of the __libc_stack_end symbol. Original
订阅 uclibc