embeddedartistry / libmemory

Embedded systems memory management library. Implementations for malloc(), free(), and other useful memory management functions
https://embeddedartistry.com
MIT License
216 stars 44 forks source link

Cross-specific flags are ignored by meson #77

Closed stefanct closed 2 years ago

stefanct commented 2 years ago

Hi,

I was trying to build libmemory for arm (cortex m4) on top of your libc instead of newlib. To that end, I was editing the cortex m4 configuration file to add the necessary -I directories and add the -nostdlib linker flag for the libc. To build I have used meson buildresults --cross-file build/cross/arm.txt --cross-file build/cross/cortex-m4_hardfloat.txt and make. However, this does not work correctly as can be observed by the output of arm-none-eabi-nm buildresults/src/libmemory.a or trying to use the library in a project w/o newlib. The resulting library depends on __assert_func from newlib instead of artistry's __assert_fail.

I then tried to find out what's going on (which took quite a while due to meson, which has officially replaced autotools as my most hated build system by now ;)) and stumbled about a series of bug reports in meson related to this one and I have concluded that this is the problem. In fact, all the settings to cpp_args etc. in the cross files are completely ignored. This is visible when building with meson compile --verbose that prints the command lines.

Eventually, I was successful by directly supplying the required flags as environment variables like so (assuming libc and libmemory are checked out at the same directory level):

CFLAGS="-march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 -I$(realpath ../libc/include) -I$(realpath ../libc/arch/arm/include) -I$(realpath ../libc/printf)" LDFLAGS="-L$(realpath ../libc/buildresults/src/)" meson buildresults --cross-file build/cross/arm.txt --cross-file build/cross/cortex-m4_hardfloat.txt

All of this is with up to date repos, meson 0.61.2 and gcc version 7.3.1 20180622 (both from Debian repos).

phillipjohnston commented 2 years ago

I don't have the experience of the cross flags being ignored, and I just checked and all the specified cross flags are present with 0.58.1 and 0.61.2

I upgraded the build submodule to the latest commit, you can build against our libc with:

meson buildresults --cross-file build/cross/arm.txt --cross-file build/cross/cortex-m4_hardfloat.txt --cross-file build/cross/libc.txt

Or

make CROSS=arm:cortex-m4_hardfloat:libc
$ arm-none-eabi-nm libmemory_freelist.a

aligned_malloc.c.o:
00000000 r .LC0
00000018 r .LC1
00000000 r .LC2
         U __assert_fail
00000000 r __func__.0
00000000 r __func__.1
00000000 T aligned_free
00000000 T aligned_malloc
         U free
         U malloc

Output:

  {
    "directory": "/Users/phillip/src/ea/stdlibs/libmemory/buildresults",
    "command": "arm-none-eabi-gcc -Isrc/libmemory_freelist.a.p -Isrc/ -I../src -Iinclude -I../include -I../dependencies/lib -fdiagnostics-color=always -nostdinc -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -std=c11 -O2 -fdiagnostics-show-option -ffunction-sections -fdata-sections -fdevirtualize -Wno-unknown-pragmas -Wno-padded -Wfloat-equal -Wconversion -Wlogical-op -Wundef -Wredundant-decls -Wshadow -Wstrict-overflow=2 -Wwrite-strings -Wpointer-arith -Wcast-qual -Wformat=2 -Wformat-truncation -Wmissing-include-dirs -Wcast-align -Wswitch-enum -Wsign-conversion -Wdisabled-optimization -Winvalid-pch -Wmissing-declarations -Wdouble-promotion -Wshadow -Wtrampolines -Wvector-operation-performance -Wshift-overflow=2 -Wnull-dereference -Wduplicated-cond -Wshift-overflow=2 -Wnull-dereference -Wduplicated-cond -Wcast-align=strict -Wno-pedantic -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mabi=aapcs -mthumb -fPIC -DPRINTF_ALIAS_STANDARD_FUNCTION_NAMES=1 -DNO_ERRNO -DIFNAN_CHECK -DGDTOA_NO_ASSERT -DNO_FENV_H -nostdinc -fno-builtin -isystem../subprojects/libc/printf/src -isystem../subprojects/libc/printf/src/printf -isystem../subprojects/libc/openlibm/src -isystem../subprojects/libc/openlibm/include -isystem../subprojects/libc/arch/arm/include -isystem../subprojects/libc/src/gdtoa/include -isystem../subprojects/libc/include -MD -MQ src/libmemory_freelist.a.p/aligned_malloc.c.o -MF src/libmemory_freelist.a.p/aligned_malloc.c.o.d -o src/libmemory_freelist.a.p/aligned_malloc.c.o -c ../src/aligned_malloc.c",
    "file": "../src/aligned_malloc.c",
    "output": "src/libmemory_freelist.a.p/aligned_malloc.c.o"
  },
phillipjohnston commented 2 years ago

Next time, you can ping me before going through issues on Meson's tracker. If you were editing cross files, you would need to re-create the build output folder after each modification. Like CMake's toolchain files, cross file modifications don't trigger a reconfiguration.

stefanct commented 2 years ago

Yes, with the updated build submodule and its libc.txt it works ok, even the additional flags. I am aware that the build dir (usually buildresults) is not updated automatically, I have rm -rfed it between my tests. So this was definitely not the issue I've been seeing. Unfortunately, I have reverted all my changes in the cross files and for an unknown reason I cannot re-create the problem even with the old build, damnit. So... can't reproduce, closing, sorry for the noise :(

phillipjohnston commented 2 years ago

That’s ok, I’m glad it’s working now. Without the issue I would not have noticed the build folder didn't include the libc files :).

Cheers,

Phillip

On Mar 6, 2022, at 07:59, Stefan Tauner @.***> wrote:

 Yes, with the updated build submodule and its libc.txt it works ok, even the additional flags. I am aware that the build dir (usually buildresults) is not updated automatically, I have rm -rfed it between my tests. So this was definitely not the issue I've been seeing. Unfortunately, I have reverted all my changes in the cross files and for an unknown reason I cannot re-create the problem even with the old build, damnit. So... can't reproduce, closing, sorry for the noise :(

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.

eli-schwartz commented 2 years ago

If you were editing cross files, you would need to re-create the build output folder after each modification. Like CMake's toolchain files, cross file modifications don't trigger a reconfiguration.

Actually, I have no idea about cmake's toolchain files but Meson cross files are added as reconfigure dependencies, so editing them and rerunning ninja will cause the buildsystem to reconfigure in order to apply changes.

This is equivalent to meson setup --reconfigure. For a slightly more extreme form of reconfiguration, meson setup --wipe will preserve all your original command line arguments (including defined cross files), then rm -rf the build directory for you and configure from scratch.

eli-schwartz commented 2 years ago

I then tried to find out what's going on (which took quite a while due to meson, which has officially replaced autotools as my most hated build system by now ;)) and stumbled about a series of bug reports in meson related to this one and I have concluded that this is the problem. In fact, all the settings to cpp_args etc. in the cross files are completely ignored. This is visible when building with meson compile --verbose that prints the command lines.

This bug report you link has to do with setting c_args / cpp_args from the command line instead of via a cross file.It should anyways be fixed since Meson 0.51.0 which added the ability to distinguish on the command line between -Dc_args (cross compiler) and -Dbuild.cpp_args (native compiler). Before that, there were no -Dbuild.* options and -Dc_args only affected the native compiler.

phillipjohnston commented 2 years ago

@eli-schwartz

Actually, I have no idea about cmake's toolchain files but Meson cross files are added as reconfigure dependencies, so editing them and rerunning ninja will cause the buildsystem to reconfigure in order to apply changes.

This is great, has it always been the case or was that added later? I noted in the manual:

Cross file settings are only read when the build directory is set up the first time. Any changes to them after the fact will be ignored. This is the same as regular compiles where you can't change the compiler once a build tree has been set up. If you need to edit your cross file, then you need to wipe your build tree and recreate it from scratch.

eli-schwartz commented 2 years ago

That's, uh.

I don't know what the manual is saying there, because while it is true that it was "added later", in this case "later" means several commits later on the same day that cross compilation was initially stubbed out, in https://github.com/mesonbuild/meson/commit/6aa1152d72731e59011ec9c46d45ead6f519953e which was part of the 0.7.0 release from 2013, and that predates the migration of the manual from wiki pages to version-controlled markdown files by nearly 4 years.

Perhaps someone wrote it in the wiki and it never got fixed? I'm not sure how the wiki version of the manual even worked, it was before my time, so for all I know it was unlocked for open editing and may not have been strictly reliable.

It was definitely a lot harder to keep in sync with changes to the codebase!

phillipjohnston commented 2 years ago

Wow - I am sad to learn I have been spreading misinformation, but very glad you popped in here!

eli-schwartz commented 2 years ago

No, no, Meson has been spreading misinformation!

Anyway, thanks for noticing that, I shall fix the docs. Hence this discussion was incredibly useful from my perspective.

eli-schwartz commented 2 years ago

Update: based on testing, it will trigger reconfiguration, but not all settings will be picked up. It's not clear to me what the purpose of adding it as a regeneration dependency is.

Update 2: if you add a binaries entry for a compiler that is used via add_languages(..., required: false) it will allow finding that for the first on cross file edits. However options are treated like project default_options and don't re-apply.

That's confusing in a way the docs don't properly explain. :/

phillipjohnston commented 2 years ago

Thanks for the update - confusing indeed!