我正在将一个大型（古老）程序转换为新的操作系统和驱动程序。程序和驱动程序在64位操作系统上运行32位。我试图打开驱动程序时遇到了一些困难。
经过一些测试后，我确定我正在转换的程序认为某个结构是19412字节，而驱动程序认为结构是19416字节。当驱动程序试图将传递给它的结构的内容归零时，这反过来导致覆盖指针的内容，导致我的其余问题。
我正在试图找出驱动程序和程序在结构大小上存在分歧的原因。
驱动程序Makefile看起来像这样（由于连接问题而手动重新输入，所以原谅错别字）：
cc -g -m32 -c -fPIC -I../inc -D_UNIX -D_LINX -D_EEEI -D_FILE_OFFSET_BITS=64 ../lib/icelib.c
cc -g -pthread -m32 -shared -lm -o ../lib/libice.so icelib.o
ar -rcs ../lib/libice.a icelib.o
cc -g -m32 -I../inc -D_UNIX -D_LINX -D_EEEI -lm -o ice ice.c ../lib/libice.so
运行它的程序有点复杂。当二进制文件动态加载一个SO，后者又调用libice.so驱动程序，而So是使用多个对象和.a文件构建的。实际调用驱动程序的代码包含在PICbrd.o文件中：
g++ -Dpthread -D_REENTRANT -DINC_TYPEDEFS -DLINUX -DICEPIC -D__FILENAME__=\"PIC6brd.cpp\" -c -g -DDEBUG -pg -m32 -Wall -D__linux__ -D__BUILD_VERS__='"3.1"' -D__BUILD_NUMBER__="'3.8"' -D__BUILD_TIME__''""' -D__cplusplus -Dcsp_SHARED -03 c/src/PIC6brd.cpp -o c/obj/PIC6brd.o
上面还有很多-I包括，我不包括因为它使命令的大小增加三倍。 include包括指向用于构建icelib.so的同一个lib
仅仅为了进行健全性测试，我尝试在icelib.so构建脚本中用G ++替换CC。我得到了更多警告，但它没有改变SO中结构的大小。
什么可能导致两个二进制文件具有不同的结构大小？
编辑： 有问题的结构是在这里包含大的方法，并在内部引用了许多其他结构。虽然它主要包含int_4和int_1但它确实包含一些浮点数和双精度数，它们的大小取决于体系结构。但是我使用64位构建脚本编译了驱动程序，并检查了那里的结构的大小，它显着更大（我相信19782）。似乎32位到64位转换的问题会导致4位差异。我还在所有似乎相关的二进制文件上运行'file'命令，它们都报告为32位。