Bug 708041 - C++ bindings cannot be compiled for non-x86 platforms using Buildroot
Summary: C++ bindings cannot be compiled for non-x86 platforms using Buildroot
Status: UNCONFIRMED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: mupdf (show other bugs)
Version: master
Hardware: All Linux
: P2 normal
Assignee: MuPDF bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-18 13:52 UTC by raphael.melotte
Modified: 2024-11-05 16:28 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Log file when compiling for aarch64 (5.39 MB, text/x-log)
2024-09-18 13:52 UTC, raphael.melotte
Details
Log file when compiling for armv5 (10.36 MB, text/x-log)
2024-09-18 13:53 UTC, raphael.melotte
Details
Generated classes.cpp for aarch64 (1.22 MB, text/x-c++src)
2024-09-18 13:59 UTC, raphael.melotte
Details
Generated classes.cpp for armv5 (1.22 MB, text/x-c++src)
2024-09-18 14:00 UTC, raphael.melotte
Details
Build log from nixos on Linux_x86-64 (92.20 KB, text/x-log)
2024-09-18 22:32 UTC, Sarah Clark
Details
Log file when compiling for armv5 using clang 19.1.3 (14.11 MB, text/x-log)
2024-11-05 14:38 UTC, raphael.melotte
Details
Generated classes.cpp for armv5 using clang 19.1.3 (1.22 MB, text/x-c++src)
2024-11-05 14:38 UTC, raphael.melotte
Details

Note You need to log in before you can comment on or make changes to this bug.
Description raphael.melotte 2024-09-18 13:52:06 UTC
Created attachment 26051 [details]
Log file when compiling for aarch64

Cross-compiling the C++ bindings with Buildroot (clang 15) on platforms other than x86_64 fails in various ways.

For example, here is the first error when cross-compiling for aarch64:
```
(+5.6s): -b: 1: __main__.py:1749:build: platform/c++/implementation/classes.cpp: In member function ‘void mupdf::FzOutput2::use_virtual_seek(bool)’:
(+5.6s): -b: 1: __main__.py:1749:build: platform/c++/implementation/classes.cpp:15111:34: error: invalid conversion from ‘void (*)(fz_context*, void*, int, int)’ to ‘void (*)(fz_context*, void*, int64_t, int)’ {aka ‘void (*)(fz_context*, 
void*, long int, int)’} [-fpermissive]

```

I attached a complete log file when compiling for different platforms.
Comment 1 raphael.melotte 2024-09-18 13:53:41 UTC
Created attachment 26052 [details]
Log file when compiling for armv5
Comment 2 raphael.melotte 2024-09-18 13:59:48 UTC
Created attachment 26053 [details]
Generated classes.cpp for aarch64
Comment 3 raphael.melotte 2024-09-18 14:00:42 UTC
Created attachment 26054 [details]
Generated classes.cpp for armv5
Comment 4 Sarah Clark 2024-09-18 22:29:37 UTC
Adding a build log from nixos on x86 Linux. The same failure seems to be happening there. (While building the Cxx extensions for use with Python, multiple "cannot convert int* to uint_XX*" where XX is in {8,16,32,64}
Comment 5 Sarah Clark 2024-09-18 22:32:18 UTC
Created attachment 26056 [details]
Build log from nixos on Linux_x86-64
Comment 6 Julian Smith 2024-11-01 14:08:39 UTC
It looks like libclang is somehow treating things like uint16_t as int.

It looks like you are building clang-15.0.3 and libclang locally - is that right? Maybe this is causing problems.

We do daily tests on Linux, MacOS and Windows, on x64 and arm64, using the libclang on pypi.org, which is currently version 18.1.1.

As a check, could you try to build the MuPDF C++ bindings similarly?

For example:

```
    python3 -m venv pylocal
    . pylocal/bin/activate
    python -m pip install --upgrade pip
    pip install libclang setuptools
    git clone --recursive git://git.ghostscript.com/mupdf.git
    cd mupdf
    git checkout 1.24.9
    python scripts/mupdfwrap.py -b m01
```

For more details, see: https://mupdf.readthedocs.io/en/latest/language-bindings.html#building-the-c-python-and-c-mupdf-apis-from-source
Comment 7 raphael.melotte 2024-11-05 14:36:53 UTC
Yes indeed, I'm building clang and its python bindings locally (using Buildroot).

To rule out an issue related to clang's version, I tried to cross-compile MuPDF using clang 19.1.3 (I'm attaching the logs for reference).
The resulting errors are the same.

If I build MuPDF and its python/C++ bindings locally for the host's architecture using libclang from pypi.org, it works. 
I only encounter issues when I try to cross-compile for another architecture.

In your tests, are you cross-compiling MuPDF for any of the targets, or are all of them compiled natively on a host of the corresponding architecture? (e.g. building for arm on an arm host).
Comment 8 raphael.melotte 2024-11-05 14:38:15 UTC
Created attachment 26173 [details]
Log file when compiling for armv5 using clang 19.1.3
Comment 9 raphael.melotte 2024-11-05 14:38:56 UTC
Created attachment 26174 [details]
Generated classes.cpp for armv5 using clang 19.1.3
Comment 10 Julian Smith 2024-11-05 16:28:20 UTC
We do not use cross-compilation in any of our tests or builds, so it is perhaps not surprising that it doesn't work for you.

I do not know whether it is possible to get the Python libclang package to build for a different platform than the one it is running on.