Embedded glibc在裸机或RTOS平台上工作吗？

嵌入式专家，没有重大修改，这是可能的吗

我正在构建的固件既有Linux内核，又有从睡眠中恢复时运行的最小RTO。相同的工具链aarch64 linux gnu用于linux和RTOS代码。RTOS不需要单独的裸机工具链的原因是，供应商有自己的精简C运行时，而不是glibc

但是，制作糟糕的C运行时缺少很多函数，因此我们希望使用功能更全面的函数。我们可以使用newlib，但这需要第二个工具链，这是我们想要避免的

但我找不到任何使用glibc的裸机或RTOS项目。目前，它可以使用glibc构建，但很快就会崩溃，几乎可以肯定，因为我们没有调用glibc初始化代码：

_start
   __libc_start_main  
     __libc_csu_init   (call C++ constructors for global variables)
     main

但看看《自由》杂志，它比《新自由》杂志要复杂得多。似乎这取决于许多不存在的Linux功能：

动态链接_dl_aux_init

pthreads\uu pthread\u initialize\u minimal

从积极的一面来看，glibc确实允许您重写sbrk和write，这两种方法定义得很弱，因此它们可以直接调用设备驱动程序代码，而不是对不存在的内核进行系统调用

更新：为我们工作意味着

1. malloc
2. printf,write to serial port, but not to actual files
3. C++ globals initialized correctly
4. no threading

---

在glibc中，

malloc

依赖于低级分配器，如

sbrk

（或

mmap

）。您可能可以在裸机目标上伪造类似于

sbrk

的东西，但您必须删除所有间接的

malloc

依赖项（包括多线程支持）

glibc

printf

实现与

fopen

实现耦合，后者依赖于

dlopen

加载字符集转换代码（gconv模块）。这甚至适用于静态链接的情况。如果没有一些深远的改变，真的没有办法摆脱动态链接器

C++初始化应该相当容易正确，即使对于裸机目标也是如此。我认为您不需要任何libc来实现这一点，只需要一点点符合目标需要的启动代码。（在某些目标上，在应用程序之前调用magic

\u init

函数就足够了。）glibc也有一些复杂的功能，但它们用于支持动态链接和

dlopen

/

dlclose

。对于静态链接的二进制文件，不需要它们

glibc到非Linux的高质量端口。非GNU操作系统肯定要做很多工作。如果目标是裸机或非POSIX RTO，则可能必须从POSIX垫片层开始。即使这样，结果也不是一个很好的glibc目标，您仍然需要一个单独的工具链

---

最好使用newlib（或现有的RTOS libc），通过和类似的项目获得缺少的libc功能。

glibc需要POSIX操作系统。我认为完全有可能告诉GCC不要链接任何标准库或启动代码，然后显式链接您自己的C库，如Newlib和crt0启动代码。然而，这种安排与大多数独立的GNU工具链没有什么不同。Newlib支持您提到的所有需求，那么为什么您需要glibc呢？我知道Newlib可以工作，更简单，并且已经将其用于STM32开发。固件构建需要aarch64 linux gnu（glibc）工具链来构建用户空间程序。因此，我们试图在RTOS部分重复使用它。否则，我们需要说服硬件供应商使用2个工具链或1个多库工具链[printf]取决于dlopen-aha，这将是一个阻碍。感谢您确认我对动态链接的怀疑。我想这意味着newlib不支持字符集转换。我将放弃使用glibc工具链这一看似权宜之计的解决方案。要清楚，

printf

对

dlopen

的依赖实际上是glibc特有的。其他实现没有这个问题。