Issues with Static Libraries and gcc-arm-none-eabi Compiler

[haydenridd]

Hello all! I am having an issue that's been driving me absolutely insane the last couple days.

In fact, so much so that I made an entire example repo just for it here:

• https://github.com/haydenridd/meson-static-library-debug

I describe the issue in detail in the repo, but a summary here:

• I'm cross compiling for an MCU target (STM32F750N8) using gcc-arm-none-eabi toolchain
• While messing around with the capabilities of meson, I tried to make a small static library for the HAL (hardware abstraction library) provided by ST Micro
• To my surprise, things didn't work when I compiled it as a static library, but did when I instead declared a dependency using the sources/includes
• Since I'm coming from CMake originally, as a sanity check I created a tiny test app (see repo above), and confirmed that a static library of the exact same code works fine when built with CMake (ninja as a backend for both)
• I dug into this for hours, and the best info I was able to get was by diffing the output of: arm-none-eabi-objdump -x for both the CMake .elf file, and the meson .elf file
• The meson .elf appears to be putting symbols for things at slightly different locations, which would make sense since the ISR routines are what appear to be broken when using the static library method with meson

My eyes are bleeding from looking at ninja logs all day, and I don't have much to show for it, so I am incredibly hopeful a low level compiler/linker guru on here can point out what could be going on.

As an aside, I don't necessarily care about making the HAL a static library, but this is the one sticking point I've had with meson I would love to get resolved. Since many open source projects using meson distribute themselves as a static library, figuring this out would unlock a lot. For instance, unity has meson support, but currently because of whatever is going on it fails spectacularly when run on target. I had to make the same hack (ditch static library, include the sources in a dependency manually) to get it running.

[mitchgrout]

Haven't had a chance to fully look over your example yet, but have some experience with cross-compiling for embedded targets in a similar fashion. In your cross-file, are you setting b_staticpic to false?

[haydenridd]

Dang! That looked super promising, I was not setting that to false. Still getting the same behavior when I set it to true though, here are 3 different outputs from objdump:
objdump_meson_source_dependency_working.txt
objdump_cmake.txt
objdump_meson_static_library_dependency_broken.txt

You can see objdump_cmake.txt and objdump_meson_source_dependency_working.txt have identical layouts, but objdump_meson_static_library_dependency_broken.txt is... not quite right.

[haydenridd]

Got rid of my previous comments because false alarm, neither b_staticpic=false nor b_asneeded=false fixed it :( Will keep digging today

[haydenridd]

Closing this because I've confirmed it's not a Meson specific issue, but just an issue I need to figure out w/ the arm-none-eabi compiler in regards to static libraries. Turns out the way I was compiling w/ CMake (using PUBLIC for my static library sources) was "sidestepping" the issue by still manually linking in the individual source object files into my final .elf. Changing my target_sources call to use the PRIVATE keyword produces the same behavior (and an identical .map file) as the behavior with Meson.

[haydenridd]

For anyone who stumbles upon this with a similar issue, what ended up being my issue (not an issue w/ Meson):

• Beware weakly defined functions in regards to static libraries
• I won't give an exhaustive definition of why, but this ended up being my exact issue, and in the comments provides some good resources on explanations for what's happening
• Basically, the default weak definition of a function was getting picked by my linker over my user-supplied definition