构建用于 Nordic SDK 程序的静态 Rust 库时对 `memset' 的多重定义
[英]multiple definition of `memset' when building static rust library to be used for Nordic SDK program
问题描述
Note: I do not see that this is a duplicate of the other question.
注意：我没有看到这是另一个问题的重复。 It's in my question, that I checked the suggetion provided there and this doesn't help here (as shown below).
That's way I wrote this question to ask for additional suggestions what I can test or where I could search for additional solutions.
I know that this question is a long one.
I try to build a static library in Rust, that I want to use in an embedded program, that runs on a Nordic nRF52832 bluetooth low energy micro controller.我尝试在 Rust 中构建一个静态库，我想在嵌入式程序中使用它，该程序在 Nordic nRF52832 蓝牙低功耗微控制器上运行。
The problem is that the static library that Rust generates contains symbols, that are also defined by libc_nano:问题是 Rust 生成的静态库包含符号，这些符号也是由 libc_nano 定义的：
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: ../../modem/target/thumbv7em-none-eabihf/release/libtbmodem.a(compiler_builtins-ace0cbd4c713eeda.compiler_builtins.8gdoevk6-cgu.12.rcgu.o): in function `memset':
/checkout/src/rustc/compiler_builtins_shim/../../libcompiler_builtins/src/mem.rs:47: multiple definition of `memset'; /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc_nano.a(lib_a-memset.o):/build/newlib-4qXI0C/newlib-3.0.0.20180802/build_nano/arm-none-eabi/thumb/v7e-m/fpv4-sp/hard/newlib/libc/string/../../../../../../../../../newlib/libc/string/memset.c:41: first defined here
collect2: error: ld returned 1 exit status
Looking at the output of nm is see, that indeed the library compiled by rust does define memset and some other typical libc functions:查看nm的输出可以看到，rust 编译的库确实定义了memset和其他一些典型的 libc 函数：
$ nm target/thumbv7em-none-eabihf/release/libtbmodem.a|grep mem
U __aeabi_memclr
U __aeabi_memcpy
U __aeabi_memclr
U __aeabi_memcpy
U __aeabi_memcpy
U __aeabi_memmove
U __aeabi_memcpy
U __aeabi_memcpy
U __aeabi_memmove
U __aeabi_memcpy
U memcmp
U __aeabi_memcpy
00000000 T memcmp
00000000 T memcpy
00000000 T memmove
00000000 T memset
00000000 W __aeabi_memclr
00000000 W __aeabi_memclr4
00000000 W __aeabi_memclr8
00000000 W __aeabi_memcpy
00000000 W __aeabi_memcpy4
00000000 W __aeabi_memcpy8
00000000 W __aeabi_memmove
00000000 W __aeabi_memmove4
00000000 W __aeabi_memmove8
00000000 W __aeabi_memset
00000000 W __aeabi_memset4
00000000 W __aeabi_memset8
U memcmp
00000000 T _ZN4core5slice6memchr6memchr17h3803f373e8c2e0b4E
00000000 T _ZN4core5slice6memchr7memrchr17hed16b4d75d82bdf8E
U __aeabi_memcpy
U memcmp
U _ZN4core5slice6memchr6memchr17h3803f373e8c2e0b4E
U __aeabi_memclr4
U __aeabi_memcpy4
U memcmp
U __aeabi_memcpy
U __aeabi_memset
U memcmp
U _ZN4core5slice6memchr6memchr17h3803f373e8c2e0b4E
U __aeabi_memclr4
U __aeabi_memcpy4
U __aeabi_memset
U __aeabi_memclr4
U __aeabi_memcpy4
U memcmp
Interestingly these colliding symbols aren't generated by Rust, when I compile for my host architecture x86_64-unknown-linux-gnu :有趣的是，当我为我的主机架构x86_64-unknown-linux-gnu编译时，这些碰撞符号不是由 Rust 生成的：
$ nm target/x86_64-unknown-linux-gnu/release/libtbmodem.a |grep mem
U memcpy
U memset
U memcpy
U memset
U memcpy
U memmove
U memcpy
U memcpy
U memmove
U memcmp
U memcpy
U memcpy
0000000000000000 T _ZN17compiler_builtins3mem6memcmp17hd848cdf5fbc51bd1E
0000000000000000 T _ZN17compiler_builtins3mem6memcpy17he0a8277ca9da5208E
0000000000000000 T _ZN17compiler_builtins3mem6memset17h0fcc19dd786ae994E
0000000000000000 T _ZN17compiler_builtins3mem7memmove17h75c47f31c61a641fE
0000000000000000 T _ZN4core5slice6memchr6memchr17h3803f373e8c2e0b4E
0000000000000000 T _ZN4core5slice6memchr7memrchr17hed16b4d75d82bdf8E
U memcmp
U memcpy
U _ZN4core5slice6memchr6memchr17h3803f373e8c2e0b4E
U memcmp
U memcpy
U memset
U memcmp
U memcpy
U _ZN4core5slice6memchr6memchr17h3803f373e8c2e0b4E
U memcpy
U memset
U memcmp
U memcpy
What is the reason for Rust to define these symbols when compiling for ARM but not when compiling for x86_64? Rust 在为 ARM 编译时定义这些符号而不是在为 x86_64 编译时定义这些符号的原因是什么？
I know, that the same error is also discussed in "multiple definition of `memcmp" error when linking Rust staticlib with embedded C program , but the solution provided there doesn't work for me.我知道， 在将 Rust staticlib 与嵌入式 C 程序链接时，“memcmp 的多重定义”错误中也讨论了相同的错误，但那里提供的解决方案对我不起作用。 Actually I already have the static library produced by rust as the last argument to the linker call:实际上，我已经将 rust 生成的静态库作为链接器调用的最后一个参数：
arm-none-eabi-gcc -DBUILD=\\"
date +%F\\" -DBUILDY=date +%Y-DBUILDM=date +%-m-DBUILDD=date +%-d-mcpu=cortex-m4 -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin --short-enums -Iconfig -std=c99 -DNRF52 -DNRF52832_XXAA -DBOARD_CUSTOM -DBLE_STACK_SUPPORT_REQD -DNRF_SD_BLE_API_VERSION=6 -DNRF_DFU_SVCI_ENABLED -DNRF_DFU_TRANSPORT_BLE=1 -DS132 -DSOFTDEVICE_PRESENT -DSWI_DISABLE0 -Wall -Werror -DFLOAT_ABI_HARD -DCONFIG_GPIO_AS_PINRESET -DNRF52_PAN_74 -I/home/matthias/source/tbblue/libtrailer/src @sdk_include_paths -Og -g3 -DDEBUG -DDEBUG_NRF -mthumb -mabi=aapcs -mcpu=cortex-m4 -Wl,--gc-sections --specs=nano.specs -lc -lnosys -lm -Wl,-Map=tbplatform.map,--wrap,_sbrk -L/home/matthias/source/tbblue/libtrailer/src -L /home/matthias/source/tbblue/nRF5_SDK//components/toolchain/gcc -T tbplatform.ld -o tbplatform .sdk/modules/nrfx/mdk/gcc_startup_nrf52.o nrfplatform.o base64.o bleinithelper.o ble_dfu_service.o broadcast.date +%F\\" -DBUILDY=date +%Y-DBUILDM=date +%-m-DBUILDD=date +%-d-mcpu=cortex-m4 -mthumb - mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin --short-enums -Iconfig -std=c99 -DNRF52 -DNRF52832_XXAA -DBOARD_CUSTOM -DBLE_STACK_SUPPORT_REQD -DNRF_SD_BLE_API_VERSION = 6 -DNRF_DFU_SVCI_ENABLED -DNRF_DFU_TRANSPORT_BLE = 1 -DS132 -DSOFTDEVICE_PRESENT -DSWI_DISABLE0 -Wall -Werror -DFLOAT_ABI_HARD -DCONFIG_GPIO_AS_PINRESET -DNRF52_PAN_74 -I /家/马提亚/源极/ tbblue / libtrailer / SRC @sdk_include_paths -OG -g3 -DDEBUG -DDEBUG_NRF -mthumb -mabi=aapcs -mcpu=cortex-m4 -Wl,--gc-sections --specs=nano.specs -lc -lnosys -lm -Wl,-Map=tbplatform.map,--wrap ,_sbrk -L/home/matthias/source/tbblue/libtrailer/src -L /home/matthias/source/tbblue/nRF5_SDK//components/toolchain/gcc -T tbplatform.ld -o tbplatform .sdk/modules/nrfx/ mdk/gcc_startup_nrf52.o nrfplatform.o base64.o bleinithelper.o ble_dfu_service.o 广播。 o config_service.o fw_version.o main.o mac_address.o modem.o nrf_ble_qwrs.o on_board_flash.o service.o system.o compartment_util.o saved_config.o temperature_util.o tick_util.o digitalinput/digital.o spi/spi.o spi/can/can_controller.o spi/can/can_interrupt.o spi/can/can_timer.o spi/can/can.o spi/uart/spi_uart.o uart/datacold500_uart.o uart/datacold600_uart.o uart/euroscan_uart.o uart/ibox_uart.o uart/uart.o .sdk/components/ble/ble_advertising/ble_advertising.o .sdk/components/ble/ble_services/ble_dfu/ble_dfu.o .sdk/components/ble/ble_services/ble_dfu/ble_dfu_unbonded.o .sdk/components/ble/common/ble_advdata.o .sdk/components/ble/common/ble_conn_params.o .sdk/components/ble/common/ble_conn_state.o .sdk/components/ble/common/ble_srv_common.o .sdk/components/ble/nrf_ble_gatt/nrf_ble_gatt.o .sdk/components/ble/peer_manager/gatt_cache_manager.o .sdk/components/ble/peer_manager/gatts_cache_manager.o .sdk/components/ble/peer_manager/id_manager.o .sdk/components/ble/peer_manager/peer_database.
(It's the file libtbmodem.a .) （这是文件libtbmodem.a 。）
What else can I do to get the library linked?我还能做些什么来链接图书馆？
1 个解决方案
解决方案1
0 2020-10-23 17:45:37
I had the same problem as you today and I can offer a possible answer (it works in my case) and a partial response why this works:我今天遇到了和你一样的问题，我可以提供一个可能的答案（它适用于我的情况）以及为什么它有效的部分回应：
TL;DR: My solution was to place my Rust library before libc on the linker line. TL;DR：我的解决方案是将 Rust 库放在链接器行上的libc之前。 In your case, this would mean to change your call to:在您的情况下，这意味着将您的电话更改为：
arm-none-eabi-gcc [...] specs=nano.specs -ltbmodem -lc -lnosys [...]
Explanation: Examining my Rust library shows, as in your case, that symbols for memcpy , memset and so forth are exported from my static library.说明：检查我的 Rust 库显示，与您的情况一样， memcpy 、 memset等符号是从我的静态库中导出的。 Note that those are contained in an object with several other memory related functions:请注意，这些包含在具有其他几个与内存相关的功能的对象中：
$ nm librustlib.a
[...]
compiler_builtins-17b2875688712538.compiler_builtins.eth5fjl6-cgu.100.rcgu.o:
00000000 T bcmp
00000000 T memcmp
00000000 T memcpy
00000000 T memmove
00000000 T memset
00000000 T _ZN17compiler_builtins3mem40__llvm_memcpy_element_unordered_atomic_117h2c6de8c0ed769de1E
[... seven "compiler_builtins" functions more omitted ...]
00000000 T _ZN17compiler_builtins3mem41__llvm_memmove_element_unordered_atomic_417h971099a5edfec01eE
[...]
Some of those functions are also exported from libc , for example:其中一些函数也从libc导出，例如：
$ nm /usr/arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc_nano.a
[...]
lib_a-memcpy.o:
lib_a-memcpy-stub.o:
00000000 t $t
00000001 T memcpy
[...]
Specifically, the five functions without name-mangling (the functions with normal names) can be found in libc_nano.a .具体来说，可以在libc_nano.a找到没有名称修改的五个函数（具有正常名称的函数）。
To understand if link order makes a difference here, I have read Library Order in Static Linking which contains the following interesting section:要了解链接顺序在这里是否有所不同，我阅读了静态链接中的库顺序，其中包含以下有趣的部分：
When the linker encounters a new library, things are a bit more interesting.
- If any of the symbols it exports are on the undefined list, the object is added to the link and the next step is executed.
- If the object has been added to the link, it's treated as described above - its undefined and exported symbols get added to the symbol table.
- Finally, if any of the objects in the library has been included in the link, the library is rescanned again - it's possible that symbols imported by the included object can be found in other objects within the same library.
So when the linker scans a library, every contained object is handled separately and can be used or be omitted from the final result, depending on whether it seems to be required to the linker, ie whether it defines a symbol that is still undefined.因此，当链接器扫描一个库时，每个包含的对象都被单独处理，可以使用或从最终结果中省略，这取决于链接器是否需要它，即它是否定义了一个仍未定义的符号。 In the article above, this is stated as:在上面的文章中，这是这样表述的：
Also note that when a library is examined, an object file within it can be left out of the link if it does not provide symbols that the symbol table needs.
For linking my Rust library with C code (and thus libc ) this means specifically:为了将我的 Rust 库与 C 代码（以及libc ）链接，这特别意味着：
- If the Rust library is placed earlier than
libcon the command-line, the "compiler_builtins"-object defining the memory-related functions will be linked in the final result.如果 Rust 库在命令行中比libc更早放置，则定义内存相关函数的“compiler_builtins”对象将在最终结果中链接。 Whenlibcis examined afterwards, the memory-related functions are already defined so that the corresponding objects fromlibcwill be omitted.之后检查libc，已经定义了与内存相关的函数，因此将省略libc中的相应对象。 - If the Rust library is placed later on the command-line, the memory-related functions from
libcwill be used.如果稍后将 Rust 库放在命令行中，则将使用libc与内存相关的函数。 Then, the linker also uses the object from the Rust library, most probably because of the name-mangled functions are required.然后，链接器还使用 Rust 库中的对象，很可能是因为需要名称修饰函数。 This leaves us with having memcpyand the like defined twice which is an error.这让我们不得不将memcpy等定义两次，这是一个错误。
I hope this information is still helpful or can be helpful to anyone who stumbles upon the same problem in the future.我希望这些信息仍然有用，或者可以对将来偶然发现相同问题的任何人有所帮助。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.