嘿，我之前也踩过类似跨GLIBC版本+Qt静态链接的坑，结合你的场景，信号槽失效大概率是memcpy wrap的实现有问题，或者静态链接时Qt的元对象系统被干扰了。给你几个具体的排查和解决步骤：

1. 先把memcpy-Wrap的实现捋顺 #

你贴的代码里__wrap_memcpy没写完，首先得确保它的行为完全和GLIBC 2.2.5的memcpy一致——千万别自己手动实现memcpy逻辑，很容易踩内存对齐或者边界处理的坑，反而干扰Qt内部的操作。正确的做法是通过弱引用调用指定版本的原生memcpy：

__asm__(".symver memcpy, memcpy@GLIBC_2.2.5");
extern "C" {
// 声明弱引用的原生memcpy，让链接器找到指定版本
void *memcpy(void *dest, const void *src, size_t n) __attribute__((weak));

void *__wrap_memcpy(void *dest, const void *src, size_t n) {
    // 直接转发到原生GLIBC 2.2.5的memcpy
    return memcpy(dest, src, n);
}
}

这样既满足了GLIBC版本兼容的需求，又不会破坏memcpy的标准行为。

2. 检查Qt静态链接的配置细节 #

静态链接Qt时，元对象系统（MOC）很容易因为配置问题“罢工”，你得确认：

• qmake的.pro文件里加了CONFIG += static，确保是静态编译模式
• 运行qmake后，打开生成的Makefile，检查是否包含了libQtCore.a等所有必要的Qt静态库
• 编译链接时一定要加-Wl,--wrap=memcpy选项，确保wrap机制正确生效，别漏了这个关键参数

3. 验证Qt元对象系统是否正常工作 #

信号槽全靠元对象系统撑着，静态链接时经常会出现MOC代码没被正确包含的情况：

• 检查所有带signals/slots的类，对应的moc_*.cpp文件有没有生成，并且被编译链接到最终程序里（比如Makefile里有没有列出这些文件）
• 加几行调试代码，看看元对象系统是不是真的初始化了：

#include <QMetaObject>
#include <QDebug>

int main(int argc, char *argv[]) {
    QCoreApplication app(argc, argv);
    // 打印元对象系统状态
    qDebug() << "Meta object system initialized:" << QMetaObject::isInitialized();
    qDebug() << "QThread meta object address:" << &QThread::staticMetaObject;
    
    // 你的业务代码...
    return app.exec();
}

如果输出显示未初始化，那说明Qt的初始化逻辑没跑起来，得检查是不是静态库链接不全，或者main函数里的QCoreApplication初始化有问题。

4. 换个姿势：用LD_PRELOAD替换memcpy（更安全） #

静态链接时用--wrap会替换整个程序（包括Qt静态库内部）的memcpy调用，这很可能干扰Qt的核心逻辑。不如改用LD_PRELOAD动态替换的方式，只替换你自己代码和动态依赖库的memcpy，不碰Qt静态库内部的调用：

1. 单独写一个memcpy替换的动态库：

// memcpy_wrap.c
#include <dlfcn.h>

void *memcpy(void *dest, const void *src, size_t n) {
    static void *(*real_memcpy)(void*, const void*, size_t) = NULL;
    if (!real_memcpy) {
        // 加载GLIBC 2.2.5版本的memcpy
        real_memcpy = dlsym(RTLD_NEXT, "memcpy@GLIBC_2.2.5");
    }
    return real_memcpy(dest, src, n);
}

编译成动态库：gcc -shared -fPIC -ldl memcpy_wrap.c -o libmemcpy_wrap.so
2. 在Scientific Linux 6.7上运行程序时，用LD_PRELOAD加载这个库：

LD_PRELOAD=./libmemcpy_wrap.so ./your_static_program

这种方式隔离性更好，不会影响Qt内部的内存操作，大概率能解决信号槽的问题。

5. 最后确认GLIBC依赖是否真的解决了 #

可以在Scientific Linux 6.7上用readelf -d your_program检查程序的动态依赖，确保没有依赖GLIBC 2.4以上的版本——有时候依赖问题会间接导致Qt初始化失败，看起来像是信号槽的问题，其实根源是库加载失败。

内容的提问来源于stack exchange，提问作者Tobias