You are not logged in.

#1 2018-11-16 20:10:36

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

[Solved] Problems building Multilib with Meson/Ninja

While investigating missing makedepends for my aur lib32-mesa-git package I realised meson was looking for 64-bit dependencies instead of 32-bit deps.

build() function (see aur for full PKGBUILD)

build () {
  export CC="gcc -m32"
  export CXX="g++ -m32"
  export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"
  export LLVM_CONFIG=/usr/bin/llvm-config32

      if [  -d _build ]; then
        rm -rf _build
    fi
    meson setup mesa _build \
       -D b_ndebug=true \
       -D buildtype=plain \
       --wrap-mode=nofallback \
       -D prefix=/usr \
       -D sysconfdir=/etc \
       --libdir=/usr/lib32 \
       -D platforms=x11,wayland,drm,surfaceless \
       -D dri-drivers=i915,i965,r200,r100,nouveau \
       -D gallium-drivers=r300,r600,radeonsi,nouveau,svga,swrast,virgl \
       -D vulkan-drivers=amd,intel \
       -D dri3=true \
       -D egl=true \
       -D gallium-extra-hud=true \
       -D gallium-nine=true \
       -D gallium-omx=disabled \
       -D gallium-opencl=disabled \
       -D gallium-va=true \
       -D gallium-vdpau=true \
       -D gallium-xa=true \
       -D gallium-xvmc=false \
       -D gbm=true \
       -D gles1=true \
       -D gles2=true \
       -D glvnd=true \
       -D glx=dri \
       -D libunwind=true \
       -D llvm=true \
       -D lmsensors=true \
       -D osmesa=gallium \
       -D shared-glapi=true \
       -D valgrind=false \
       -D tools=[]
    meson configure _build
    ninja -C _build
}

full log of build() : https://pastebin.com/3Zz976qk

relevant code snippet

Program pkg-config found: YES (/usr/bin/pkg-config)
Found pkg-config: /usr/bin/pkg-config (1.5.4)
....
Found llvm-config: /usr/bin/llvm-config (8.0.0)

This clearly shows meson checks for x86_64 deps, not lib32 as intended.
It also makes me wonder whether the code is linked to x86_64 or lib32 .

This method to build multilib libraries has been used succesfully with autotools / gnu make/ libtool for many years.
extra lib32-mesa also uses it, and there may be a lot more packages.

At this point i'm not sure whether the problems are due to meson/ninja bugs or a flawed autotools - meson migration wrt multilib by archlinux community .

Thoughts ?

Last edited by Lone_Wolf (2018-11-19 12:57:09)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#2 2018-11-16 20:28:51

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [Solved] Problems building Multilib with Meson/Ninja

This is substantially the same thing done by the official lib32-mesa package, which plainly works since lots of people use it to run multilib programs like games.

Does `file` report "ELF 32-bit LSB shared object" or doesn't it?

Native C compiler: gcc -m32 (gcc 8.2.1 "gcc (GCC) 8.2.1 20180831")

It's building 32-bit ABI, so if it tried to link 64-bit libs you would notice.

...

Why do you think there's a problem?

pkg-config is *supposed* to use the host (64-bit) version, it's a program designed to read the .pc file format as instructed by the given path.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#3 2018-11-16 21:41:48

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

This is substantially the same thing done by the official lib32-mesa package

Thanks for noticing that, I try to stay close to extra for these packages.

, which plainly works since lots of people use it to run multilib programs like games.

The error may be limited to code parts that are rarely used


Checked some of the build binaries, they all report as "ELF 32-bit LSB shared object"
That's atleast one worry less.

Why do you think there's a problem?


Archlinux systems with multilib programs installed have two pkgconfig datasets.
one in /usr/lib/pkgconfig , another in /usr/lib32/pkgconfig for multlib programs.

example :
on a system where both libva and lib32-libva are present

$ pkgconf --libs libva
-lva 
$ PKG_CONFIG_PATH="/usr/lib32/pkgconfig" pkgconf --libs libva
-L/usr/lib32 -lva 
$

This demonstrates there are 2 separate libraries present and pkgconf needs to be directed to find the multilib version.


Take my lib32-mesa-git PKGBUILD
in makedepends replace lib32-libva with libva .
Build in a clean chroot
see meson/ninja happily building
After a while we have a lib32-mesa-git that advertises va support but isn't linked to multilib va library.

Will va work in this multilib package ?
I highly doubt it.

Last edited by Lone_Wolf (2018-11-16 21:42:39)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#4 2018-11-16 21:48:27

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [Solved] Problems building Multilib with Meson/Ninja

Instead of setting PKG_CONFIG_PATH, try PKG_CONFIG. Maybe meson tries to pick the pkg-config wrapper instead of calling pkgconf directly

PKG_CONFIG=/usr/bin/pkg-config-32

Edit:

$ sudo pacman -R lib32-libva
...
$  pkg-config-32 --libs libva
Package libva was not found in the pkg-config search path.
Perhaps you should add the directory containing `libva.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libva', required by 'virtual:world', not found
$  PKG_CONFIG_PATH="/usr/lib32/pkgconfig" pkg-config --libs libva
-lva

Last edited by progandy (2018-11-16 22:10:31)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#5 2018-11-16 22:06:45

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

PKG_CONFIG=/usr/bin/pkg-config-32
Program pkg-config found: YES (/usr/bin/pkg-config)
Found pkg-config: /usr/bin/pkg-config-32 (1.5.4)
Dependency vdpau found: YES 1.1.1
Dependency libva found: NO (tried pkgconfig)

meson.build:581:2: ERROR:  Dependency "libva" not found, tried pkgconfig

Fails as it should do.

Checking llvm-config next by using llvm-svn as dep instead of lib32-llvm-svn .


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#6 2018-11-16 22:08:45

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Offline

#7 2018-11-16 22:14:18

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [Solved] Problems building Multilib with Meson/Ninja

lib32-llvm contains "llvm-config32", not "llvm-config", so build scripts should refer to that I think.

Last edited by progandy (2018-11-16 22:25:43)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#8 2018-11-16 22:23:44

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

The links from loqs appear to confirm meson uses pkg_config .
problem partially solved.

with llvm-svn as makedep instead of lib32-llvm-svn meson sees no problems though ninja fails very soon in compiling due to absent files.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#9 2018-11-16 22:25:48

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [Solved] Problems building Multilib with Meson/Ninja

You'll probably want to create a cross build definition file for meson that defines the path for llvm-config. You could probably use it for pkg-config as well.
https://mesonbuild.com/Cross-compilation.html


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#10 2018-11-16 22:40:47

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

Sounds like a good idea, something like this :

[binaries]
# not sure yet what to put here


[properties]
# not sure yet what to put here

[host_machine]
system = 'linux'
cpu_family = 'x86_64'
cpu = 'i686'
endian = 'little'

[target_machine]
system = 'linux'
cpu_family = 'x86'
cpu = 'i686'
endian = 'little'

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#11 2018-11-16 22:58:15

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [Solved] Problems building Multilib with Meson/Ninja

meson should probably complain if it is missing an entry for a binary it needs in [binaries]. In my understanding, meson ignores $PATH while searching for an executable and only looks at the [binaries] section for the path and name.

Edit: I have two minimal cross build files that worked for a demo project.

project('test', ['c', 'cpp'])
gtkdep = dependency('gtk+-3.0')
llvmdep = dependency('llvm')
executable('test', 'main.c', dependencies : [ gtkdep, llvmdep ])

multi.cross

[binaries]
c = ['/usr/bin/gcc', '-m32']
cpp = ['/usr/bin/g++', '-m32']
ar = '/usr/bin/ar'
pkgconfig = '/usr/bin/pkg-config-32'
llvm-config = '/usr/lib/llvm-config32'

[host_machine]
system = 'linux'
cpu_family = 'x86'
cpu = 'i686'
endian = 'little'

multi-alt.cross

[binaries]
c = '/usr/bin/gcc'
cpp = '/usr/bin/g++'
ar = '/usr/bin/ar'
pkgconfig = '/usr/bin/pkg-config-32'
llvm-config = '/usr/lib/llvm-config32'

[properties]
c_args = ['-m32']
c_link_args = ['-m32']

[host_machine]
system = 'linux'
cpu_family = 'x86'
cpu = 'i686'
endian = 'little'

Everything was built with

meson build-multi --cross-file multi.cross
(cd build-multi && ninja)
meson build-multi-alt --cross-file multi-alt.cross
(cd build-multi-alt && ninja)
meson build
(cd build && ninja)

Last edited by progandy (2018-11-16 23:44:15)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#12 2018-11-17 18:03:44

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

The m32 through flags in multi-alt file gave errors in mesa vulkan code about incompatible file format.

Building with multi.cross does finish.

namcap reports several errros like this :

lib32-mesa-git W: ELF file ('usr/lib32/d3d/d3dadapter9.so.1.0.0') lacks FULL RELRO, check LDFLAGS

Not sure if those matter for *.so files though.


--------------------------
Now we're close to a solution, another thing comes to mind : How to make arch community, devs & TU aware of this ?

meson is  a makedepend for 10+ lib32 packages (besides mesa related ones) including lib32-systemd.
Once the lib32- packages have been adjusted, programs depending on them may also need rebuilds.

If archlinux has a multilib packaging standards page, this should be mentioned there.
In case such page doesn't exist yet, maybe we need to create one.

In my opinion this is important enough to be discussed by whole arch dev community.
arch-dev-public ML seems a logical place for that.

Eschwartz : are you willing to bring up this issue on arch-dev-public ?

Last edited by Lone_Wolf (2018-11-17 18:04:17)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#13 2018-11-17 18:11:04

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: [Solved] Problems building Multilib with Meson/Ninja

The FULL RELRO check should have been fixed for .so with namcap 3.2.8-3 https://git.archlinux.org/svntogit/pack … 07e8433943

Offline

#14 2018-11-17 18:24:10

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [Solved] Problems building Multilib with Meson/Ninja

The missing relro makes me question if meson ignore the LDFLAGS variable while crosscompiling.

.. Just checked, during cross-compile meson ignores LDFLAGS, apparently you have to copy everything to c_args (CPPFLAGS and CFLAGS) and c_link_args (LDFLAGS). There might be other such special cases. It seems that neither cross nor normal build is a good fit for multilib builds in meson. It would be great if there was a way to only override some binaries and keep everything else the default environment. Do we have to use a bin32 with symlinks to override the normal filename instead?
https://github.com/mesonbuild/meson/blo … /c.py#L425

Edit: It seems the meson git master has now introduced "native files" which can be used to override executables without doing a real cross-build. We may be better off waiting for that and creating a common multilib-native file that is included in a lib32-meson package or so.
https://github.com/mesonbuild/meson/blo … onments.md

Last edited by progandy (2018-11-17 18:34:29)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#15 2018-11-17 21:22:16

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

I knew I had seen something about --native files, found it again https://github.com/mesonbuild/meson/issues/3327

The commits for native files were added to master on nov 15, so only git version will have them now.


Using a multilib.native file that's shared by all does seem best option.
Maybe a lib32-mesondoc package with this file and an example PKGBUILD ?
That package could be added to multilib-devel group so everyone building multilib will have it.

An alternative would be to add it to pacman and install to /usr/share/pacman .


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#16 2018-11-18 00:24:26

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [Solved] Problems building Multilib with Meson/Ninja

Lone_Wolf wrote:

Eschwartz : are you willing to bring up this issue on arch-dev-public ?

I am *not* willing to bring this up on arch-dev-public.

So far, you have *YET TO STATE THERE IS A PROBLEM NEEDING TO BE FIXED*.

meson respects CC='gcc -m32', and compiles 32-bit code as it darn well should.

meson does not respect PKG_CONFIG_PATH, because it's not its job to respect PKG_CONFIG_PATH -- pkg-config itself respects PKG_CONFIG_PATH, and using pkg-config-32 is literally just a wrapper script to set pkg-config's internally respected variables before... running pkg-config.

You have stated:

This clearly shows meson checks for x86_64 deps, not lib32 as intended.
It also makes me wonder whether the code is linked to x86_64 or lib32 .

Which tells me quite clearly that you started this thread because you don't know if there is a problem, and are wondering whether there *might* be one. I have asserted that to the best of my knowledge, there shouldn't be one. I have pointed out how to check to see what ABI the files are compiled for, and I have observed that linking 64-bit ABI code into 32-bit ABI code doesn't actually work. To elaborate on that point, I don't expect linking a Windows DLL file to work either. The compile should complain most harshly against the attempt to build completely broken artifacts. The absolute best-case scenario is that you simply fail to detect the availability of either 32-bit or 64-bit code, and therefore use automagic dependencies to disable support for the 32-bit code.

The wonderful professors in this thread have then proceeded to get into a very long and involved discussion about all sorts of irrelevant things while forgetting to actually answer my initial question of "is there like an actual problem somewhere?"

...

There is *NO WAY* I am going to raise a question on arch-dev-public to discuss the topic of "Some random forum users aren't sure whether there might be such-and-such a problem. We should develop a formal developer discussion to figure out how to fix this."

STATE. THE. PROBLEM.

Last edited by eschwartz (2018-11-18 00:35:58)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#17 2018-11-18 10:02:22

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [Solved] Problems building Multilib with Meson/Ninja

The problem as I understood it is this: setting PKG_CONFIG_PATH is not working well. I have no lib32-libva installed here, but pkg-config picks it up. As a result, meson thinks the dependency is installed in its log output.

$ pacman -Q libva      
libva 2.3.0-1
$  CUTF pacman -Q lib32-libva
error: package 'lib32-libva' was not found
$ PKG_CONFIG_PATH="/usr/lib32/pkgconfig" pkg-config --libs libva
-lva 

Looking closer, /usr/bin/pkg-config is setting PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH, which is checked if nothing is found in PKG_CONFIG_PATH. To get multilib builds to look only in the 32bit directory, removing the 64bit location from PKG_CONFIG_LIBDIR is necessary. It is probably best to set all other variables set /usr/bin/pkg-config-32 as well, like the system library path.

$  PKG_CONFIG_LIBDIR="/usr/lib32/pkgconfig" pkg-config --libs libva               
Package libva was not found in the pkg-config search path.
Perhaps you should add the directory containing `libva.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libva', required by 'virtual:world', not found

Edit: Or just set PKG_CONFIG and let the wrapper script do it for you.

With LLVM and llvm-config there is a similar problem. llvm-config is shipped with the 64bit package, so meson will detect llvm as available if the 64bit version is installed during a multilib build. Detecting if 32bit llvm is available should be done with llvm-config32. meson has no nice solution yet to change the path for llvm-config except setting $PATH or using a cross-build. With the next release there will the native build files to do it, though. The cross-build looked like a nice idea, but it was like using a sledgehammer to kill a fly.

Last edited by progandy (2018-11-18 10:24:49)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#18 2018-11-18 13:35:43

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

Thanks for the detailed insight, progandy.

Eschwartz, I think I can provide a POC to show there are real problems with multib & meson now.

- build llvm-svn & lib32-llvm-svn from aur or get them from kerberizer unoffical repo
- clone my AUR lib32-mesa-git package
- edit the PKGBUILD
- in makedepends array replace lib32-libva with libva and lib32-llvm with llvm
- save PKGBUILD
- build in a clean chroot

expected behaviour
meson detects libva & llvm multilib support is  missing and aborts build

observed behaviour
meson is satisfied everything needed is present and build continues.
ninja misses needed files and aborts

--------


Why do i use AUR lib32-mesa-git instead of lib32-mesa in this POC ?
AUR lib32-mesa-git has all dependencies in top of pkgbuild, making it easy to control what is used.
lib32-mesa is a split package with dependencies throughout the entrire PKGBUILD.

Last edited by Lone_Wolf (2018-11-18 13:36:11)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#19 2018-11-18 19:25:25

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [Solved] Problems building Multilib with Meson/Ninja

@progandy,

Thanks for explaining the problem.

So, I ran a test build with PKG_CONFIG=/usr/bin/pkg-config-32 and as expected, this works too. Note that assuming the makedepends are properly set, this should never be a problem, so using PKG_CONFIG_PATH technically works as well. It should be impossible to hit issues unless the PKGBUILD is broken.
Furthermore, I dug around in the mesa codebase, and discovered that mesa's build system depends on the libva headers, but not libva itself. Which explains why falling back on detecting 64-bit libva does not result in compilation failures.

As for llvm-config32, does meson not respect an LLVM_CONFIG environment variable? Maybe this would be a good idea for a feature request. It's obvious that supporting a PKG_CONFIG variable is the same sort of utility as supporting a *_CONFIG variable in the general case, so once again it should respect prior art and look for LLVM_CONFIG. Okay, no, they've rejected it for no reason.
But again, it works in the repository, so maybe it makes no difference which one you use as long as both llvm packages are compiled the same, which they really should be.

...

Again, as far as I can tell, it's still impossible to break the package without manually breaking the makedepends list. Multilib in the general case is perfectly fine. I'm not even sure I'd go so far as to say that multilib llvm-config is broken in the specific case -- it is only potentially broken.

That being said, it is certainly flaky and unreliable to depend on llvm-config and llvm-config32 returning the same results minus -L/usr/lib32 so... we can discuss fixing the *one* package which depends on lib32-llvm, once a released version of meson supports doing this in a remotely sane manner.

As a matter of code correctness, I'd favor using PKG_CONFIG over PKG_CONFIG_PATH, but I'm not really sure we need some sort of public discussion or general policy on it... I guess it would be nice to have a multilib packaging guidelines page describing it.

Last edited by eschwartz (2018-11-18 19:28:57)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#20 2018-11-18 19:35:57

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [Solved] Problems building Multilib with Meson/Ninja

eschwartz wrote:

Again, as far as I can tell, it's still impossible to break the package without manually breaking the makedepends list. Multilib in the general case is perfectly fine. I'm not even sure I'd go so far as to say that multilib llvm-config is broken in the specific case -- it is only potentially broken.

Yes, it is no problem for properly written packages.
It may result in confusion during the creation of a new PKGBUILD, though. If you accidentally only depend on llvm instead of lib32-llvm, you get no clear error message but only some build errors you have to hunt down. If you think to look for a missing dependency, but depend on the meson detection output, it tells nothing is missing.
Edit: The longer I think about that, the more I come to the conclusion, that this is difficult to handle. In the same manner that you can forget to use the lib32- prefix, you can also forget to add the "--native llvm.path" option to the build and get cryptic errors.

Last edited by progandy (2018-11-18 19:38:25)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#21 2018-11-19 12:56:34

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

Summary

Archlinux multilib aka lib32 packages use upto 4 environment variables to ensure compiled code is correct.

  export CC="gcc -m32"
  export CXX="g++ -m32"
  export PKG_CONFIG_PATH="/usr/lib32/pkgconfig"
  export LLVM_CONFIG=/usr/bin/llvm-config32

This method was designed for & tested with "./configure - make - make install" aka autotools / gnu make.
The first 3 vars above are used by all, the 4th only by multilib mesa packages.

Many programs have migrated from autotools/gnu make to meson/ninja as build tools.

Meson 0.48.2 does use the GCC & CC environment variables, but ignores the other 2.

For  export PKG_CONFIG_PATH="/usr/lib32/pkgconfig" meson does provide an alternative :

export PKG_CONFIG=/usr/bin/pkg-config-32

For LLVM_CONFIG Meson 0.48.2 has no alternative, but one has been submitted to meson master.
The next release of meson should include that code.

https://github.com/mesonbuild/meson/blo … onments.md

Severity , impact, necessary actions :
Consensus has not been achieved, use your own judgment.

End of Summary
---------------------------


In my opinion this topic is now solved.

I will switch from PKG_CONFIG_PATH to PKG_CONFIG in the multilib packages I maintain.
The lib32-mesa-git PKGBUILD will get a comment that llvm_config currently doesn't work and needs to be replaced as soon as meson supports --native.
If this doesn't happen this year, i'll probably revert lib32-mesa-git to autotools.


Progandy, Loqs, Eschwartz : thank you for participating.




Edit :

It might be a good idea to verify if lib32-systemd needs lib32-libxslt or libxslt

makedepends=('gcc-multilib' 'git' 'gperf' 'intltool' 'lib32-acl' 'lib32-bzip2'
             'lib32-curl' 'lib32-dbus' 'lib32-gcc-libs' 'lib32-glib2'
             'lib32-gnutls' 'lib32-libelf' 'lib32-libidn2' 'lib32-pcre2'
             'libxslt' 'meson')

Last edited by Lone_Wolf (2018-11-19 13:01:39)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#22 2018-12-23 11:54:25

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: [Solved] Problems building Multilib with Meson/Ninja

Latest Meson release 0.49 does support the option to use other tools on native builds.

I've added a llvm32.native file to my AUR lib32-mesa-git package and have not found any drawbacks.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

Board footer

Powered by FluxBB