Flatbuffers not generating 32-bit "flatc" executable on Ubuntu

[Jonathan-Greve]

Xmake Version

2.8.8

Operating System Version and Architecture

Ubuntu 22.04.4 LTS x86_64

Describe Bug

When installing the flatbuffers package it will build the flatbuffer compiler flatc. It does so perfectly on both windows 32 and 64 bit (using xmake f -a x86 and xmake f -a x64 respectively). It also works perfectly on Ubuntu for x86_64 and build the flatc executable in the installdir. But for some reason it doesn't build the flatc executable on linux with architecture set to i386. I.e. there isn't any installdir/bin/flatc . The installdir contains the same files otherwise except the missing bin folder.

There are no errors anywhere when downloading or installing the package.

Expected Behavior

I would expect it to compile the flatbuffer project and provide the flatc compiler in the installdir/bin/ folder like it does on 64 bit mode on Ubuntu and both 32- and 64-bit mode in Windows 10.

Project Configuration

You can see it fail here in this github action:
https://github.com/Jonathan-Greve/gw_dat_reader/actions/runs/8328945753/job/22790106109

Additional Information and Error Logs

Other than the missing flatc I don't have any issues. I can generate the 32-bit flatc manually by doing:

1. Cloning the google flatbuffers repository.
2. Running cmake -G "Unix Makefiles" -DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32
3. Running make -j

[SirLynix]

-DFLATBUFFERS_BUILD_FLATC=OFF is passed to cmake as seen here.

This is because of this part of the script.

The issue is that xmake recognize cross-compilation and thus the inability to run the flatc binary on the host.

It would work with a 32bits runner, but I don't think GitHub provides those as 32bits Linux are pretty rare today.

[Jonathan-Greve]

Ah yeah that makes sense. I didn't think of building 32-bit binary on 64-bit OS as cross-compilation but I guess it makes sense.

I don't quite understand the intricacies of xmake so I'm not sure if the current way of doing it is working as intended or not.
I can of course work around it for the time being. But it would be nice if something like this would work without having to do something special for the linux i386 case:

local flatbuffers_installdir = target:pkg("flatbuffers"):installdir()
local flatc_exe = is_plat("windows") and "flatc.exe" or "flatc"
local flatc_path = path.join(flatbuffers_installdir, "bin", flatc_exe)

Thanks for clarifying. And if this is intended behavior if there is a more general issue covering this topic feel free to close this issue.

[SirLynix]

Are you using flatbuffers only for its binary package?

If so you want use add_requires("flatbuffers", { host = true }) to tell xmake to install it with the host system/arch instead of the target system/arch, you'll then have flatc executable available.

[Jonathan-Greve]

No I will be using the library too for my project. I.e. i won't just be using flatc I will also be including the flatbuffer headers in my code. It will always be compiled on 64-bit OS though so I don't mind flatc being 64-bit only.

EDIT:
I'll probably only be doing cross-compilation since my code unfortunately is going to depend on some 32-bit inline __asm code. So even though I'll only be compiling on 64-bit hosts I'm gonna have to target 32-bit.

[SirLynix]

One way is to write something like:

add_requires("flatbuffers")
if is_cross() then -- requires xmake 2.8.8
    add_requires("flatbuffers~host", { host = true })
end

and use flatbuffers~host flatc if present or flatbuffers otherwise, something I do with my own binary shader compiler rule.

[Jonathan-Greve]

Hi thanks for the support. Yes that seems to do what I need but I don't understand what flatbuffers~host does. Should I close the issue since my problem is solved?

[SirLynix]

It's a way to requires flatbuffers a second time without conflicting on the package name. xmake remove the ~ part when fetching a package on xmake-repo but keeps it as its reference name. ("~host" is just a suffix, it could be anything).

The real magic is to configure it with host = true

[Jonathan-Greve]

Alright thanks a lot :)