单独调用链接器GCC交叉编译结果抛出错误
GCC cross compilation result throws error if the linker is called separately
我正在尝试为运行 openst-linux 发行版的 STM32MP157C-DK2 演示板编译一个简单的 hello-world 程序。我正在使用 Ubuntu-VM 和 OpenEmbedded/Yocto 进行交叉编译。如果我仅使用一行编译和 link 程序，一切正常。但是，如果我将命令拆分为编译并 linking 生成的程序将不起作用。我想拆分这个过程，因为 Ecplise 分别调用编译器和 linker。
我可以使用这一行成功编译程序：
arm-openstlinux_weston-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=[path to sysroot] -o gtk_hello_world_manual src/main.c -O2 -pipe -g -feliminate-unused-debug-types -Wall -pthread -I[long list of include directories] -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0
此结果是一个有效的 gtk_hello_world_manual 程序。我尝试使用同一行来拆分流程，但目标是 main.o 而不是 gtk_hello_world_manual。然后我 link 用这一行 main.o 编辑了结果：
arm-openstlinux_weston-linux-gnueabi-ld --sysroot=[path to sysroot] -o gtk_hello_world_manual -O1 --hash-style=gnu --as-needed -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 main.o
程序编译和 link 两次都没有错误。如果我使用一行compilation/linking，程序在目标板上运行完美。
如果我使用拆分变体，错误消息
"error while loading shared libraries: type: cannot open shared object file: No such file or directory"
出现，程序终止。
[编辑] 找到解决方案：
您必须使用 -c 选项调用编译器，这样 linking 过程就不会完成。这导致以下命令：
arm-openstlinux_weston-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=[path to sysroot] -o main.o -c src/main.c -O2 -pipe -g -feliminate-unused-debug-types -Wall -pthread -I[long list of include directories]
然后使用 gcc 命令间接调用 linker：
arm-openstlinux_weston-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=[path to sysroot] -O2 -pipe -g -feliminate-unused-debug-types -o gtk_helloworld_manual -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 main.o
这会产生一个工作程序文件。有了它，它可以包含在 ecplise makefile 项目中，并在 IDE.
中构建和调试
找到解决方案并添加到原来的post。做了这个答案，所以我可以将其标记为已解决。
我正在尝试为运行 openst-linux 发行版的 STM32MP157C-DK2 演示板编译一个简单的 hello-world 程序。我正在使用 Ubuntu-VM 和 OpenEmbedded/Yocto 进行交叉编译。如果我仅使用一行编译和 link 程序，一切正常。但是，如果我将命令拆分为编译并 linking 生成的程序将不起作用。我想拆分这个过程，因为 Ecplise 分别调用编译器和 linker。
我可以使用这一行成功编译程序：
arm-openstlinux_weston-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=[path to sysroot] -o gtk_hello_world_manual src/main.c -O2 -pipe -g -feliminate-unused-debug-types -Wall -pthread -I[long list of include directories] -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0
此结果是一个有效的 gtk_hello_world_manual 程序。我尝试使用同一行来拆分流程，但目标是 main.o 而不是 gtk_hello_world_manual。然后我 link 用这一行 main.o 编辑了结果：
arm-openstlinux_weston-linux-gnueabi-ld --sysroot=[path to sysroot] -o gtk_hello_world_manual -O1 --hash-style=gnu --as-needed -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 main.o
程序编译和 link 两次都没有错误。如果我使用一行compilation/linking，程序在目标板上运行完美。
如果我使用拆分变体，错误消息
"error while loading shared libraries: type: cannot open shared object file: No such file or directory"
出现，程序终止。
[编辑] 找到解决方案： 您必须使用 -c 选项调用编译器，这样 linking 过程就不会完成。这导致以下命令：
arm-openstlinux_weston-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=[path to sysroot] -o main.o -c src/main.c -O2 -pipe -g -feliminate-unused-debug-types -Wall -pthread -I[long list of include directories]
然后使用 gcc 命令间接调用 linker：
arm-openstlinux_weston-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=[path to sysroot] -O2 -pipe -g -feliminate-unused-debug-types -o gtk_helloworld_manual -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 main.o
这会产生一个工作程序文件。有了它，它可以包含在 ecplise makefile 项目中，并在 IDE.
中构建和调试找到解决方案并添加到原来的post。做了这个答案，所以我可以将其标记为已解决。