问题标签 [uclibc]

有这段代码：

当main创建新线程然后执行sleep(100)时，新线程可能在到达pthread_exit之前main到达pthread_join。无论如何，新线程等待并且他的资源在main执行之前不会被释放，pthread_join所以如果我执行ps命令，我将在接下来的 100 秒内看到新线程，对吗？如果我改用，我会得到相同的行为pthread_detach吗pthread_join？我想知道当新线程在线程上执行pthread_exit之前的 main 执行时会发生什么pthread_detach。

I'm building an uClibc i486 cross toolchain for an embedded system. The toolchain is built on Debian Wheezy (x86-64) and consists of the following components:

• Binutils 2.24
• GCC 4.7.3
• Linux 3.2.54
• uClibc 0.9.33.2
• GMP 5.1.3
• MPFR 3.1.2
• MPC 1.0.2

These steps are used to build the toolchain:

Install Linux 3.2.54 headers

This step is successfully completed.

Build Binutils 2.24

Binutils is built in a separate directory as specified in the documentation.

This step is successfully completed.

Build GMP 5.1.3

This step is successfully completed.

Build MPFR 3.1.2

This step is successfully completed.

Build MPC 1.0.2

This step is successfully completed.

Build static GCC 4.7.3

GCC is built in a separate directory as specified in the documentation.

This step is successfully completed.

Build uClibc 0.9.33.2

The configuration file for uClibc is default with following options enabled:

TARGET_i386=y
CONFIG_486=y

UCLIBC_HAS_FENV=y
LINUXTHREADS_OLD=y

This step is successfully completed.

Build final GCC 4.7.3

GCC is built in a separate directory as specified in the documentation.

This step fails with the following errors:

I check the linker search path:

The path is correct, so I search for the allegedly missing files in the directory:

All the files are found in the directory.

Can someone tell me what I'm doing wrong?

谁知道.L_ X'%ebx = 1的意思，我在AS doc中没有找到这句话的语法，这句话是用来赋值的？.L _X'%ebx 不是一个有效的符号名称，我猜这是否意味着一个特殊的变量导致当展开“bpushl .L_ X'%k2, %k2\n\t”时，我们需要展开.L _X'% k2，那么扩展的结果是什么，有人可以帮助我吗名字，谢谢！

我尝试使用 buildroot (2014.02) 为 mips 生成 ucLibc(0.9.33.2) 工具链，但它不会在 output/build/uclibc-0.9.33.2/ 或 output/host 文件夹上生成 spawn.h 和其他 spawn 相关文件，我确认 UCLIBC_HAS_ADVANCED_REALTIME 和 UCLIBC_HAS_REALTIME 在 uCLibc Config.in 中都设置为 'y'，我还在 ./output/build/host-m4-1.4.17 上找到了 spawn.h，但它们从未进入工具链。有人可以帮忙提示如何做吗？谢谢

昨天我在stackoverflow上问了一个问题，但是我没有描述清楚，所以我改变了问的方式，也许把问题说清楚了。首先，我修改了klee提供的例子get_sign.c，我将其包含unistd.h在程序中，并调用函数sleep()使线程暂停，如下

我使用“ llvm-gcc”编译get_sign.c，然后使用klee get_sign.o执行objectfile，线程不暂停，表示sleep()不工作。所以我在执行get_sign.o时添加了一个参数，像这样klee --libc=uclibc get_sign.o，不幸的是，线程仍然没有挂起，而且klee报告错误，

我能做些什么来解决这个问题？谢谢你！

我使用下面的测试代码减少了我的问题，

主文件

2.cc

1.cc

将 1.cc 编译成 lib1.so 并将 2.cc 编译成 lib2.so 如下所示，

以上步骤将生成 lib1.so、lib2.so 和 a.out。这里的问题是在运行可执行文件 a.out 时，使用 dlsym(RTLD_NEXT) 时无法查找原始的“fread”符号。

输出是，

但是如果改变 lib2.so 的链接过程（如下所示），它似乎正在工作

输出：

谁能解释一下后台发生了什么？提前致谢。

我正在尝试为带有运行 uClinux 的 ARM 处理器的嵌入式系统编译“hello world”C 应用程序。我正在使用这个工具链

当我使用 -static 编译标志编译 C 应用程序时，应用程序工作正常。当我删除 -static 标志时 - 我收到一个错误：can't load library 'libc.so.6'

目标上不存在 libc.so.6，进入目标设备上的 /lib 文件夹，符号链接 libc.so.0 指向 libuClibc-0.9.33.2.so

我如何“告诉”编译器与 libc.so.0 链接？

我正在使用 uClibc 为 Linux 编译一个静态链接的 i386 二进制文件。用于生成地址堆栈跟踪的回溯库函数不可用。我需要一个替代品。

http://code.metager.de/source/xref/lib/eglibc/libc/sysdeps/i386/backtrace.c和https://github.com/hwoarang/uClibc/blob/master-metag/libubacktrace/backtrace _ .c似乎从.c 加载函数_Unwind_Backtracelibgcc_c.so.1。但是，libgcc_so.1在我的工具链中不可用，当我尝试直接使用_Unwind_backtrace时，我得到的堆栈跟踪只有 1 帧（最上面的一个，来自调用_Unwind_Backtrace的函数。

我需要在我的静态链接的 i386 Linux 可执行文件中使用backtrace或_Unwind_Backtrace的有效替换，与 uClibc 链接，而不加载任何 .so 文件（例如libgcc_c.so.1），这可以生成完整的堆栈跟踪（仅指令指针）。这样的实现在哪里可用？

仅供参考 gcc__builtin_return_address生成如下代码：

这只是盲目地沿着框架链走，没有任何边界检查或健全性检查。我想使用比这更安全的东西。

请注意，即使 glibc backtrace(3)也不会在使用gcc -fomit-frame-pointer编译的函数中显示帧，我决定不需要它。

我正在尝试实现一个liblog.so将在 i386 控制器上运行的动态库（）。

当我编译它时，Host Machine (Ubuntu Machine)它会成功编译并生成.so文件。 liblog.so是放在/usr/lib目标机器下的文件。

在主机上输出。

目标机器上的输出：

当我将它发送到目标机器（目前在 VMware 中）时，当我运行它时.\log_client它显示can't load library 'libc.so.6' 是我编译log_client链接liblog.so

编译命令

生成liblog.so

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -c log.c -o liblog.o

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -shared -o liblog.so liblog.o -rdynamic -lcrypto -lssl

生成log_client

cp liblog.so ../../../../build/i386/buildroot-2011.11/output/target/usr/lib

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log_client.c

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -o log_client log_client.o -llog -rdynamic -lcrypto -lssl

我正在对另一个正在工作的代码使用相同的过程，尽管该代码不使用此自定义库（liblog.so），但也有警告，但我没有在此处发布。请帮助我，我很沮丧！

------------已编辑----------

file输出

------------更新----------

有人建议我--sysroot在编译文件时使用，但即使这样也没有帮助我。同样的错误出来。:(

我已经把sysroot路径放到目标机器的 GCC 的 sysroot 路径

生成liblog.so

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log.c -o liblog.o --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -shared -o liblog.so liblog.o -rdynamic -lcrypto -lssl --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

生成log_client

cp liblog.so ../../../../build/i386/buildroot-2011.11/output/target/usr/lib

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log_client.c --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -o log_client log_client.o -llog -rdynamic -lcrypto -lssl --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

更新

运行 objdump 后这是输出。

我正在为我的OpenWrt路由器用C 语言编写一个自定义 HTTP 服务器。它利用了uclibc库。我只使用一个静态缓冲区，我非常小心不要溢出，并且不涉及多线程。它不包含任何复杂的数据结构，它的作用是：

• 它在套接字上侦听（）
• 在accept()之后读取请求
• 通过向预定义的远程服务器（不是代理）发送 http 请求来获取 html 页面
• 通过接受的连接发送结果，并关闭两者。

该程序会在一段时间后停止运行（它可以在收到第一个请求时，或者在重压下工作超过 2 小时后）。我没有通过控制台或任何东西收到错误消息，程序只是停止了。我看过它，正如预期的那样，它在运行时不会消耗越来越多的内存......

• 如果内核认为它滥用CPU，它是否有可能停止它？我该如何克服呢？
• 在 C 中的套接字编程中是否存在一些已知会导致此类崩溃的怪癖？
• 使用 OpenWrt 的 Barrier Bracker (bleeding edge) 分支是否会导致稳定性问题？虽然路由器本身永远不会停止工作......

我从哪里开始寻找问题的根源？