Closed stefanct closed 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"
},
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.
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 -rf
ed 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 :(
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.
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.
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 withmeson 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.
@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.
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!
Wow - I am sad to learn I have been spreading misinformation, but very glad you popped in here!
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.
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. :/
Thanks for the update - confusing indeed!
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 usedmeson 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 ofarm-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 withmeson 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):
All of this is with up to date repos, meson 0.61.2 and gcc version 7.3.1 20180622 (both from Debian repos).