gpt4 book ai didi

python - 在 Linux x86_64 for PowerPC 上交叉编译 Python 的 greenlet 和 gevent

转载 作者:太空狗 更新时间:2023-10-29 12:06:08 29 4
gpt4 key购买 nike

在我的 Linux x86_64 主机上,我正在尝试为我的 PowerPC 目标交叉编译一些额外的 Python 模块,特别是 greenlet , gevent , 和 gevent-websockets .目前,我只是试图交叉构建 greenlet 模块。

使用本网站的信息:

http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html

我能够使用此设置为我的构建环境交叉编译 Python 2.7.2

# Undo variables for cross-compile environment
unset ROOT
unset SDKDIR
unset KLIBDIR
unset NFSDIR
unset CONFIG
unset CONFIGURED
unset ARCH
unset OS
unset TOOLCHAIN_BASE
unset TOOLCHAIN_BIN
unset CROSS_COMPILE
unset c
unset KERNEL_DIR
unset AS
unset LD
unset CC
unset AR
unset STRIP
unset SSTRIP
unset OBJCOPY
unset OBJDUMP
unset MAKE
unset CFLAGS

# Set cross-compile variables:
export TOOLCHAIN=/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-
export CC=${TOOLCHAIN}gcc
export CXX=${TOOLCHAIN}g++
export AR=${TOOLCHAIN}ar
export RANLIB=${TOOLCHAIN}ranlib
export BLDSHARED="${TOOLCHAIN}gcc -shared"
export LDSHARED="${TOOLCHAIN}gcc -shared"
export RFS="../../ltib/rootfs"
export CFLAGS="-save-temps -Wall -I${RFS}/usr/include -I${RFS}/include/python2.7 -L${RFS}/usr/lib -L${RFS}/lib"
export LDFLAGS="-I${RFS}/usr/include -I${RFS}/include/python2.7 -L${RFS}/usr/lib -L${RFS}/lib"
export CROSS_COMPILE=ppc-linux
export CROSS_COMPILE_TARGET=yes
export HOSTARCH=ppc-linux
export BUILDARCH=x86_64-linux-gnu

使用上述脚本配置我的环境,然后尝试构建 greenlet 模块:

$ python ./setup.py build
running build
running build_ext
building 'greenlet' extension
creating build
creating build/temp.linux-x86_64-2.7
/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc -I../../../ltib/rootfs/usr/include -L../../../ltib/rootfs/usr/lib -L../../../ltib/rootfs/lib -fPIC -I/usr/include/python2.7 -c greenlet.c -o build/temp.linux-x86_64-2.7/greenlet.o
In file included from /usr/include/python2.7/Python.h:58,
from greenlet.h:8,
from greenlet.c:5:
/usr/include/python2.7/pyport.h:849:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
error: command '/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc' failed with exit status 1

为什么 setup.py 从我的主机系统上的 /usr/include/python2.7 拉取?我在我的目标上找不到那个目录。如何为我的目标创建它?

有什么建议吗?

谢谢!

特雷弗

更新#1:

我对主机的目标 rootfs 副本的相对引用不正确。更正它并重新运行产量:

$ python ./setup.py build
running build
running build_ext
building 'greenlet' extension
creating build
creating build/temp.linux-x86_64-2.7
/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc -save-temps -Wall -I../../ltib/rootfs/usr/include -I../../ltib/rootfs/include/python2.7 -L../../ltib/rootfs/usr/lib -L../../ltib/rootfs/lib -fPIC -I/usr/include/python2.7 -c greenlet.c -o build/temp.linux-x86_64-2.7/greenlet.o
greenlet.s: Assembler messages:
greenlet.s:832: Error: syntax error; found `(' but expected `,'
greenlet.s:832: Error: junk at end of line: `(31),1'
error: command '/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc' failed with exit status 1

至少它找到了我目标的更多包含库,但现在我真的很困惑! :(

还有什么建议吗?

谢谢!

更新#2:

通过向编译器添加 -save-temps 标志(更新了上面的错误),我能够保存并检查上面错误消息中提到的中间汇编代码。虚线是:

#APP
# 52 "platform/switch_ppc_linux.h" 1
mr 8(31), 1
# 0 "" 2

MR(移动寄存器)操作相当简单,只接受 2 个参数(mr to-reg, from-reg)。我不知道带有附加寄存器号的括号是如何添加的。 FWIW,这是上面头文件中引用的宏:

#define STACK_REFPLUS 1

#ifdef SLP_EVAL

#define STACK_MAGIC 3

/* !!!!WARNING!!!! need to add "r31" in the next line if this header file
* is meant to be compiled non-dynamically!
*/
#define REGS_TO_SAVE "r13", "r14", "r15", "r16", "r17", "r18", "r19", "r20", \
"r21", "r22", "r23", "r24", "r25", "r26", "r27", "r28", "r29", \
"cr2", "cr3", "cr4"
static int
slp_switch(void)
{
register int *stackref, stsizediff;
__asm__ volatile ("" : : : REGS_TO_SAVE);
__asm__ ("mr %0, 1" : "=g" (stackref) : );
{
SLP_SAVE_STATE(stackref, stsizediff);
__asm__ volatile (
"mr 11, %0\n"
"add 1, 1, 11\n"
"add 30, 30, 11\n"
: /* no outputs */
: "g" (stsizediff)
: "11"
);
SLP_RESTORE_STATE();
}
__asm__ volatile ("" : : : REGS_TO_SAVE);
return 0;
}

#endif

我开始怀疑这是否是编译器中的错误,因为宏看起来很简单!有什么建议么? ...谢谢!

最佳答案

也许你应该问一个新问题,因为这里确实(至少)有两个完全独立的问题。但是,看看你的第二个问题:

__asm__ ("mr %0, 1" : "=g" (stackref) : );

这是错误的。我将在下面解释原因,但首先,以下更改可能会修复它:

__asm__ ("mr %0, 1" : "=r" (stackref) : );

您可能还需要将下面的 "g"(stsizediff) 更改为 "r"(stsizediff)

那么,现有版本有什么问题?首先看一下stackref是怎么定义的:

register int *stackref, stsizediff;

register 是对编译器的提示,表示您认为如果它为 stackref 分配一个寄存器而不是使用堆栈位置,它可能会使事情变得更快或更好,不是要求。如果 stackref 以 R12 结尾,那很好;如果它最终进入堆栈帧 8 个字节,那也很好。只要不违反任何约束,两者都是完全合法的。

那么,stackref 有哪些限制?唯一的一个是在上面引用的那个 asm block 中。您将 "=g"(stackref) 作为输出操作数。 = 表示它是只写约束,g 表示它必须在寄存器、内存位置或立即值中。

所以编译器没有做错任何事。它从堆栈中分配 stackref 8 个字节,这与约束相匹配(这是一个内存位置),然后用该值代替 "%0",您得到:

mr 8(31), 1

这并没有错——直到您尝试对其进行汇编,并且汇编程序注意到您正在尝试将 8(31) 与仅采用寄存器的操作码一起使用。但问题不在于编译器或汇编器,而在于代码。你要求它使用 stackref 作为 mr 的操作数,并且没有强制 stackref 成为寄存器,所以你得到了你所要求的为。

无论如何,将 "=g" 更改为 "=r" 会将约束从“任何寄存器、内存位置或立即值”更改为“任何通用寄存器” ”。这意味着编译器必须将 stackref 放在通用寄存器中。或者,如果由于某种原因它不能,它会失败并告诉您原因,而不是生成不会组装的程序集。

那么,为什么这对原作者有效?好吧,他可能很幸运,stackref 被分配给了,比如说,R12,而不是堆栈帧中的 8 个字节,所以他最终得到了 mr 12, 1,组装得很好。

或者,还有一种可能。查看 git 树,看起来代码是在 Mac OS X 上开发的,然后在十年前移植到 AIX(主要是 Mac 开发人员),然后逐字从 AIX 复制到 linux(甚至留下描述“Port for AIX on PowerPC"),此后就没有太大的变化了。当时 OS X 和 AIX 都只有 gcc 3。所以,也许这就是当时它对每个人都有效但对你不起作用的原因。也许只需要一个较旧的交叉编译器就可以解决您的问题。但我会先尝试修复代码。

关于python - 在 Linux x86_64 for PowerPC 上交叉编译 Python 的 greenlet 和 gevent,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11587635/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com