Unable to install glib library with meson - makefile

I am trying to install latest version glib version 2.64.3 library which uses meson build system to compile glib code.
While installing glib i am trying to give custom options to compiler to compile with specific gcc version...etc.
Here is my command :-
/test/common/pkgs/python/v3.6.1/bin/meson setup glib_install  -Dbuild.cpp_args="-fPIC" -Dbuild.c_args='-fPIC -O2' -Dc_link_args='/test/common/pkgs/gcc/v6.3.0/lib64' -Ddefault_library=both -Db_staticpic=true -Dprefix='/home/user/test/glib-2.64.3/glib-2.64.3/glib_install'
I am getting following issue :-
The Meson build system
Version: 0.54.2
Source dir: /home/user/extlibs/glib-2.64.3/glib-2.64.3
Build dir: /home/user/extlibs/glib-2.64.3/glib-2.64.3/glib_install
Build type: native build
WARNING: Unknown options: "c_args, cpp_args"
The value of new options can be set with:
meson setup <builddir> --reconfigure -Dnew_option=new_value ...
Project name: glib
Project version: 2.64.3
meson.build:1:0: ERROR: Compiler cc can not compile programs.
I am not sure if i am missing something here. I could not find much info about like how can we provide custom arguments to use specific compiler flags while running meson. Let me know if i am missing something here.

Check in your glib_install/meson-logs/meson-log.txt file to see why the configuration is failing, but as a start it seems you need to pass -Dcpp_args="-fPIC" -Dc_args='-fPIC -O2' (without build.) on the command line.

Related

Bazel build of JAX fails with missing dependency declarations

I am trying build cuda-enabled JAX from source on a cluster with CentOS version7. In the jax home directory, I run:
python build/build.py --enable_cuda --cuda_path=$CUDA_HOME --cudnn_path=$CUDNN_HOME
Here are my specs:
cuda version: 11.6
cudnn version 7.5
gcc version: 11.2.0
Bazel binary path: ./bazel-5.1.1-linux-x86_64
Bazel version: 5.1.1
Python binary path: ~/.conda/envs/JAX/bin/python
Python version: 3.9
NumPy version: 1.21.5
MKL-DNN enabled: yes
Target CPU: x86_64
Target CPU features: release
CUDA enabled: yes
Here are my environment variables:
CC=/usr/local/app/compiler/gcc/11.2.0/bin/gcc
CXX=/usr/local/app/compiler/gcc/11.2.0/bin/g++
INCLUDE=/usr/local/app/compiler/gcc/11.2.0/include
LIBRARY_PATH=/usr/local/app/compiler/gcc/11.2.0/lib64:/usr/local/app/lib/nvidia/cuda/11.6.1/lib64:/usr/local/app/lib/nvidia/driver/510.47/lib64/nvidia
LD_LIBRARY_PATH=/usr/local/app/compiler/gcc/11.2.0/lib64:/usr/local/app/lib/nvidia/cuda/11.6.1/lib64:/usr/local/app/lib/nvidia/driver/510.47/lib64/nvidia
The Bazel build throws this error:
ERROR: /lustre1/home/rice_cake/.cache/bazel/_bazel_rice_cake/8366d0a62cbb3b115627233e356374ab/external/zlib/BUILD.bazel:5:11: Compiling uncompr.c failed: undeclared inclusion(s) in rule '#zlib//:zlib':
this rule is missing dependency declarations for the following files included by 'uncompr.c':
'/usr/local/app/compiler/gcc/11.2.0/lib/gcc/x86_64-redhat-linux/11.2.0/include/stddef.h'
'/usr/local/app/compiler/gcc/11.2.0/lib/gcc/x86_64-redhat-linux/11.2.0/include-fixed/limits.h'
'/usr/local/app/compiler/gcc/11.2.0/lib/gcc/x86_64-redhat-linux/11.2.0/include-fixed/syslimits.h'
'/usr/local/app/compiler/gcc/11.2.0/lib/gcc/x86_64-redhat-linux/11.2.0/include/stdarg.h'
It seems that Bazel is complaining that I do not declare dependency for the C++ library files. Is there a way to solve this?
The trouble is that these Bazel build files are automatically generated by jax/build/build.py, and I don't know how to fix them manually.
P.S. Building JAX from source is successful on my local machine..
Thanks very much for any help,
Rice
I went into the Bazel cache files and checked the BUILD file, and it's the same as the on my local machine, so I'm a bit stuck. I am expecting that maybe setting environment variables might help Bazel build my JAX.

Cross compile the Aravis Library using a makefile for ARM archi

I have already used the Aravis library on a host running on Linux,
Aravis is a C open-source library for camera acquisition. You could find the GitHub repo in the link below:
https://github.com/AravisProject/aravis
I want to cross-compile the library for my ARM target running on a Mendel Linux machine.
The thing is I am not very familiar with the meson build and this library does not offer any makefile.
Do you have any idea or sample of the makefile that could help me cross-compile, please?
Thank you in advance
S.Tarik
I tried to change the configuration in Linux to call the g++ cross compiler first by changing the priority between the default gcc and aarch64-linux-gnu-g++.
https://github.com/highperformancecoder
the error message thrown by the compiler is the following:
www#www-virtual-machine:~/Downloads/aravis-main$ meson build
The Meson build system
Version: 0.63.3
Source dir: /home/www/Downloads/aravis-main
Build dir: /home/www/Downloads/aravis-main/build
Build type: native build
Project name: aravis
Project version: 0.8.23
meson.build:1:0: ERROR: Could not invoke sanity test executable: [Errno 8] Exec format error: '/home/www/Downloads/aravis-main/build/meson-private/sanitycheckc.exe'.
A full log can be found at /home/www/Downloads/aravis-main/build/meson-logs/meson-log.txt
tar

Using gcc plugins with cross compiler, undefined symbol

I'm trying to see if it's possible to use a gcc plugin in an ARM cross compiler (arm-none-eabi-gcc). I'm running into compiler errors however, and am questioning whether what I'm trying to do is possible.
The plugin I'm trying to set up is: https://github.com/vanhauser-thc/AFLplusplus/tree/master/gcc_plugin
I'm compiling the plugin on x86-64 linux using the -m32 flag, since the cross compiler is a 32-bit application. However when I try to use the plugin in the cross compiler using -fplugin , I get an undefined symbol compiler error:
cc1plus: error: cannot load plugin ../afl-gcc-pass.so
../afl-gcc-pass.so: undefined symbol: _Z13build_int_cstP9tree_nodel
I looked through the plugin's symbols using nm and discovered that the majority of symbols are undefined, including ones like exit and random. I'm new to most of this and am unsure of what that really means. Some searching online suggested that it may have had something to do with incorrect library paths, but setting LIBRARY_PATH and LD_LIBRARY_PATH and rebuilding did not seem to help.
The gcc version set-ups I have tried:
1: x86: 5.4.0 , arm: 5.4.1 on ubuntu 16.04
2: x86: 5.2.0 , arm: 5.2.1 on CentOS 6.8
Is it possible to use a gcc plugin in a different gcc than it was compiled with or am I wasting my time?
Yes, it is possible to build a gcc plugin with a given compiler and then use the plugin in another compiler (including a cross-compiler), but you have to make sure you include the right header files when building the plugin.
Specifically, you have to include the plugin development header files of the target compiler, instead of those of the host compiler. The directory where plugin development files for your target compiler are located can be obtained with the following command:
$(TARGET_CC) -print-file-name=plugin
where $(TARGET_CC) is your target compiler. So a concise way to specify the relevant include directory in the compiler flags when building the plugin would be something like -I"$(shell $(TARGET_CC) -print-file-name=plugin)/include".
For the specific plugin you are trying to use (instrumentation for afl-fuzz), in order to build the plugin for your cross-compiler you could modify the Makefile in the gcc_plugin folder; more specifically, you could define a TARGET_CC variable containing the path to your cross-compiler, and then replace $(CC) with $(TARGET_CC) in the definition of PLUGIN_FLAGS, as in:
PLUGIN_FLAGS = -fPIC -fno-rtti -I"$(shell $(TARGET_CC) -print-file-name=plugin)/include"
You will also have to comment out the commands executed in the test_build Makefile target, because those commands would try to use the plugin with the native compiler and so would fail.
Then, you will be able to use the plugin with your cross-compiler, as in:
arm-none-eabi-gcc -fplugin=../afl-gcc-pass.so --specs=nosys.specs my_source_file.c

How do I set up meson project with wxWidgets depends for Windows?

I'm trying out a new setup. I'm on a 64-bit Windows 10. I've meson example project and clang compiler stack over Visual Studio 2017. Both of those are in my PATH.
[0/1] Regenerating build files.
The Meson build system Version: 0.49.0
Source dir: C:\WORK\cpp-example\wx-example
Build dir: C:\WORK\cpp-example\wx-example\builddir
Build type: native build
Project name: wx-example
Project version: undefined
Native C++ compiler: clang++ (clang 7.0.0 "clang version 7.0.0 (tags/RELEASE_700/final)")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found wx-config '>=3.0.0' NO
Dependency WxWidgets found: NO (tried config-tool)
meson.build:8:2: ERROR: Dependency "wxwidgets" not found, tried config-tool
A full log can be found at C:\WORK\cpp-example\wx-example\builddir\meson-logs\meson-log.txt
FAILED: build.ninja
My meson.build is
project('wx-example', 'cpp')
#if build_machine.system() == 'windows'
# cpp = meson.get_compiler('cpp')
# add_project_link_arguments(['C:\WORK\wxWidgets-3.1.2\include'], language : 'cpp')
# wx_dep = cpp.find_library('wxwidgets', dirs : ['C:\WORK\wxWidgets-3.1.2\lib\vc_x64_dll'])
#else
wx_dep = dependency('wxwidgets', version : '>=3.0.0', required : true)
#endif
executable('wx-example.exe', ['main.cpp'], dependencies : [wx_dep])
Do u have any idea how to compile my example?
Maybe I should use MinGW wxWitgets package?
Meson's dependency for wxWidgets only supports wx-config tool, which was originally intended for *nix only. So you need to get wx-config Windows native port first to make it work with VC++.
BTW. Maybe even the easiest thing to do is to write it on your own, as it's just a regular console application, which parses the command line and spits to stdout the corresponding compiler/linker flags.
Maybe I should use MinGW wxWitgets package?
Well, that's, of course, possible but then you will also have to switch to gcc/g++. Moreover, Meson's wxWidgets dependency is still broken under MSYS2/MinGW. The problem is that Meson erroneously tries to execute wx-config directly, while under Windows it must be prefixed with env/sh/bash or whatever. Not a big problem to fix it, but you'll still have some work to do.
UPD.: The issue appears to be fixed in Meson 0.51.0

Cross compiling, missing packages

I'm working on Linux PC x86_64.
I've set up a cross compile toolchain for raspberry pi and I can compile basic helloworld and run it on raspberry.
I'm stuck at compiling some open-source programs as ./configure is complaining about missing packages, for example:
configure: No package 'glib-2.0' found
I'm using this. ./configure --host=arm-linux-gnueabihf to cross compile and it looks good until that error above.
Should I tell ./configure to use libs from target system or? How to do it?
Pass options to the configure script so that it finds the development headers and libraries. It uses using LDFLAGS and CFLAGS.

Resources