<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Meson: crosscompiling with a crossfile seems to fail"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=108922">108922</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Meson: crosscompiling with a crossfile seems to fail
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>Mesa
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>git
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>Other
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>All
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>medium
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Other
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>mesa-dev@lists.freedesktop.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>alexandre.f.demers@gmail.com
          </td>
        </tr>

        <tr>
          <th>QA Contact</th>
          <td>mesa-dev@lists.freedesktop.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>SI'm not sure it is a bug per se since there is a workaround that I'm
suggesting at the end. However, this clearly doesn't follow meson's doc about
crosscompilation.

I've been using a script to build mesa easily. I only have to add a few
arguments to crosscompile, bisect, etc. Now, I'm in the process of moving this
script from autotools to meson. Everything is being configured and is compiling
fine when build from x86_64 (build) to x86_64 (host). To follow meson's doc
about crosscompilation, I've created a simple crossfile (I'll attach it). That
way, meson knows I'm building on a x86_64 build to a x86 host. Adding a bit of
debug outputs shows that the build is detected as x86_64 and the host as x86.
However, this fails miserably:

error
[40/2045] Compiling C object
'src/mapi/glapi/src@mapi@glapi@@glapi_static@sta/.._entry.c.o'.
FAILED: src/mapi/glapi/src@mapi@glapi@@glapi_static@sta/.._entry.c.o 
/usr/bin/gcc -Isrc/mapi/glapi/src@mapi@glapi@@glapi_static@sta -Isrc/mapi/glapi
-I../../src/mapi/glapi -Isrc/mesa -I../../src/mesa -Iinclude -I../../include
-Isrc -I../../src -Isrc/mapi -I../../src/mapi -Isrc/mapi/glapi/gen
-fdiagnostics-color=always -DNDEBUG -pipe -D_FILE_OFFSET_BITS=64 -Wall
-Winvalid-pch -std=c99 -O3 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="19.0.0-devel"'
'-DPACKAGE_BUGREPORT="<a href="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa">https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa</a>"'
-DGLX_USE_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=1
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM
-DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
-DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL
-DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS
-DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK
-DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED
-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_VISIBILITY
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -D_GNU_SOURCE
-DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_STRTOF
-DHAVE_MKOSTEMP -DHAVE_POSIX_MEMALIGN -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE
-DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LLVM=0x0700
-DMESA_LLVM_VERSION_PATCH=0 -DUSE_LIBGLVND=1 -DHAVE_LIBUNWIND
-DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS
-DHAVE_GALLIUM_EXTRA_HUD=1 -DHAVE_LIBSENSORS=1
-Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -fno-math-errno -fno-trapping-math
-Wno-missing-field-initializers -Wno-format-truncation -fPIC -pthread
-Werror=pointer-arith -Werror=vla -DMAPI_MODE_BRIDGE
'-DMAPI_ABI_HEADER="/home/ademers/projects/display/mesa/build/i686-pc-linux-gnu/src/mapi/glapi/gen/glapi_mapi_tmp.h"'
 -MD -MQ 'src/mapi/glapi/src@mapi@glapi@@glapi_static@sta/.._entry.c.o' -MF
'src/mapi/glapi/src@mapi@glapi@@glapi_static@sta/.._entry.c.o.d' -o
'src/mapi/glapi/src@mapi@glapi@@glapi_static@sta/.._entry.c.o' -c
../../src/mapi/entry.c
{standard input}: Assembler messages:
{standard input}:8: Error: invalid instruction suffix for `pop'
{standard input}:10: Error: @GOTNTPOFF reloc is not supported with 64-bit
output format
{standard input}:10: Error: junk `@GOTNTPOFF' after expression
ninja: build stopped: subcommand failed.
make failed and returned exitcode 1

It happens even if I set (or not) the following:
  export CFLAGS="-m32"
  export CXXFLAGS="-m32"

Now, instead of using the crossfile, if I set the following (which is being
used in Archlinux's lib32 mesa package), it will build fine:
  export CC="gcc -m32"
  export CXX="g++ -m32"
This is being detected as an x86 build to an x86 host, which is mostly a
workaround than a real fix since we are overcoming the x86_64 build -> x86 host
situation.

Am I missing something?</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>