I'm trying to cross compile an application with meson 0.51.1
My build system: Linux
Host System: Windows
The application depends on freetype2 from meson wrap db:
https://wrapdb.mesonbuild.com/v1/projects/freetype2/2.9.1/1/get_wrap
I'm keep getting the following error:
meson.build: ERROR: Could not find Windows resource compiler
The complaint is about the following line in the freetype's meson.build file:
winmod = import('windows')
base_sources += [
'builds/windows/ftdebug.c',
winmod.compile_resources('src/base/ftver.rc'),
]
My cross file looks like:
[binaries]
c = ['ccache', 'i686-w64-mingw32-gcc']
cpp = ['ccache', 'i686-w64-mingw32-g++']
ar = 'i686-w64-mingw32-ar'
strip = 'i686-w64-mingw32-strip'
exe_wrapper = 'WINEPREFIX=~/.wine64 wine'
windres = 'i686-w64-mingw32-windres'
[properties]
needs_exe_wrapper = true
[host_machine]
system = 'windows'
cpu_family = 'i686'
cpu = 'i686'
endian = 'little'
i686-w64-mingw32-windres is installed:
$ i686-w64-mingw32-windres --version
GNU windres (GNU Binutils) 2.32.51.20190707
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
I tried to set the WINDRES variable as described hear https://mesonbuild.com/Windows-module.html. It does not help either.
Related
I am a green hand about linux and I am using a server to run my R code through qsub xx.pbs. When I library "Rcpp" package, I got this error:
Error: package or namespace load failed for ‘Rcpp’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/data/user77/Rlib/Rcpp/libs/Rcpp.so':
/lib64/libc.so.6: version `GLIBC_2.14' not found (required by /data/user77/Rlib/Rcpp/libs/Rcpp.so)
However, when I used ldd --version to find out what is the current version of glibc, I got this:
ldd (GNU libc) 2.17
When I ran /lib64/libc.so.6, I got this:
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-23).
Compiled on a Linux 2.6.32 system on 2021-01-02.
How can I fix this problem? Thanks a lot for your providing solutions!
(PS: I am not allowed to use sudo.)
I want to set default compiler from clang to gcc in termux (android application).
gcc isn't available in official repo so I used pointless community repo. But now I can't configure the termux to use gcc instead of clang.
usr/bin/ contain g++, gcc, gcc-8, g++8.
But gcc --version command shows default clang.
gcc-8 --version shows:
"CANNOT LINK EXECUTABLE "gcc-8" : library "libc++_shared.so" not found
linker: CANNOT LINK EXECUTABLE "gcc-8": library "libc++_shared.so" not found.
I had this problem as well. The question that is asked by #Andy J is unfortunately less than helpful because there is not even ldconfig in this environment and I saw on Reddit that one of the developers said it's not even needed. (I doubt they are correct but it's not needed to fix this problem.
Do:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PREFIX/lib
export PATH=$PATH:$PREFIX/lib
Then finally you should be able to use GCC version 8.0.
~/gccbuild $ gcc-8 --version gcc-8 (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for
copying conditions. There is NO
warranty; not even for MERCHANTABILITY or F
FITNESS FOR A PARTICULAR PURPOSE.
Personally I'm trying to install it so that I can compile GCC 12, wish me luck with that lol.
I was preparing a demonstration of user mode Qemu's (qemu-user package) qemu-arm. To do so, I used a simple hello world C program hello.c:
#include <stdio.h>
int main()
{
printf("Oi, Qemu!\nPrograma C aqui!\n");
}
To cross compile it (statically linked), I used the cross toolchain from gcc-arm-linux-gnueabihf:
$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 9.3.0-10ubuntu1) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ arm-linux-gnueabihf-gcc hello.c -o hello_c_static -static
The output runs in both qemu-arm, Beaglebone Black AND ON THE PC.
How is it possible?!
EDIT
About the compiled executable:
file hello_c_static
hello_c_static: ELF 32-bit LSB executable, ARM, EABI5 version 1
(GNU/Linux), statically linked,
BuildID[sha1]=6a33aaa5abb9a14fbc0ca4f2e7b432d6fa5d7067, for GNU/Linux 3.2.0,
not stripped
Check ls -l /proc/sys/fs/binfmt_misc/ to see if your x86 system is set up to transparently run qemu on ARM binaries for you, the same way it can be to run WIINE on Windows executables or whatever using Linux binfmt_misc. https://en.wikipedia.org/wiki/Binfmt_misc
Admin guide https://www.kernel.org/doc/Documentation/admin-guide/binfmt-misc.rst
The installer for the qemu-user package might have registered the executable formats it supports.
With no binfmts registers, you'll just have the register and status "files". On my system, WINE and Mono boot scripts have registered handlers so I also see CLR and DOSWin files. e.g.
$ cat /proc/sys/fs/binfmt_misc/DOSWin
enabled
interpreter /usr/bin/wine
flags:
offset 0
magic 4d5a
If there's somehow a different mechanism, try using strace ./some_arm_program to see what system calls happen when you execute it.
Maybe also suspend it while it's running (control-z) and look at /proc/$(pidof some_arm_program)/maps and other files.
(This last section was written after the OP commented that they only saw register and status files, not qemu-arm, but they've since change their comment. It looks like binfmt-support is the answer.)
I'm trying to compile xmacro which I downloaded from http://xmacro.sourceforge.net/.
I'm running Fedora 19 LXDE.
question: Where do I get iostream.h? It's missing. I see some packages the include iostream.h. The package version number compat-gcc-34-c++.i686 doesn't match g++ (GCC) 4.8.1 20130603. Should it?
I'd think iostream.h would be included when I downloaded the compiler.
I have installed gcc-c++ , libx11-devel, & libxtxt.
question: did I get the right version of c++? What is Compatibility GNU Compiler Collection?
$ yum search "compat-gcc"
Loaded plugins: langpacks, refresh-packagekit
=========================================== N/S matched: compat-gcc ============================================
compat-gcc-34.i686 : Compatibility GNU Compiler Collection
compat-gcc-34-c++.i686 : C++ support for compatibility compiler
compat-gcc-34-g77.i686 : Fortran 77 support for compatibility compiler
Name and summary matches only, use "search all" for everything.
I get:
$ make
g++ -O2 -I/usr/X11R6/include -Wall -pedantic -DVERSION=0.3 xmacroplay.cpp -o xmacroplay -L/usr/X11R6/lib -lXtst -lX11
xmacroplay.cpp:57:22: fatal error: iostream.h: No such file or directory
#include <iostream.h>
^
compilation terminated.
make: *** [xmacroplay] Error 1
$ yum whatprovides '*/iostream.h'
Loaded plugins: langpacks, refresh-packagekit
compat-gcc-34-c++-3.4.6-29.fc19.i686 : C++ support for compatibility compiler
Repo : fedora
Matched from:
Filename : /usr/include/c++/3.4.6/backward/iostream.h
cxxtools-devel-2.2-1.fc19.i686 : Development files for cxxtools
Repo : fedora
Matched from:
Filename : /usr/include/cxxtools/iostream.h
gap-devel-4.6.4-2.fc19.i686 : GAP compiler and development files
Repo : fedora
Matched from:
Filename : /usr/lib/gap/src/iostream.h
gap-devel-4.6.5-1.fc19.i686 : GAP compiler and development files
Repo : updates
Matched from:
Filename : /usr/lib/gap/src/iostream.h
glibmm24-devel-2.36.2-2.fc19.i686 : Headers for developing programs that will use glibmm24
Repo : fedora
Matched from:
Filename : /usr/include/giomm-2.4/giomm/iostream.h
marisa-devel-0.2.2-2.fc19.i686 : Development files for marisa
Repo : fedora
Matched from:
Filename : /usr/include/marisa/iostream.h
mingw32-glibmm24-2.36.2-2.fc19.noarch : MinGW Windows C++ interface for GTK2 (a GUI library for X)
Repo : fedora
Matched from:
Filename : /usr/i686-w64-mingw32/sys-root/mingw/include/giomm-2.4/giomm/iostream.h
mingw64-glibmm24-2.36.2-2.fc19.noarch : MinGW Windows C++ interface for GTK2 (a GUI library for X)
Repo : fedora
Matched from:
Filename : /usr/x86_64-w64-mingw32/sys-root/mingw/include/giomm-2.4/giomm/iostream.h
root-cint-5.34.07-1.fc19.i686 : CINT C++ interpreter
Repo : fedora
Matched from:
Filename : /usr/lib/root/cint/cint/include/iostream.h
root-cint-5.34.10-1.fc19.i686 : CINT C++ interpreter
Repo : updates
Matched from:
Filename : /usr/lib/root/cint/cint/include/iostream.h
me ~ $ g++ --version
g++ (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
me ~ $
iostream.h is the old, pre-standard name for a header in what would later become the C++ standard library. The modern, standardised name is just iostream, without the .h.
The best solution would be to go through the source and change iostream.h to iostream everywhere. You might encounter other problems though, if the C++ code you're trying to compile is truly ancient. On the other hand it might work fine, with a few warnings. Give it a try and see what happens.
If it doesn't work, you might find that the "compat-g++" package (which has the very old 3.4 version of g++) handles this old code better than 4.8 does.
I have the source for a linux-based program, but trying to run in Win7 environment. I found software called "mingw32" and msys that can compile linux source to win7 using makefile.in (included with source). But I get error "nothing to be done for 'makefile.in'"
Source is available here: http://sourceforge.net/projects/libots/files/libots/ots-0.5.0/ots-0.5.0.tar.gz/download
Makefile.in is below
# Makefile.in generated automatically by automake 1.4-p6 from Makefile.am
# Copyright (C) 1994, 1995-8, 1999, 2001 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
[...]
POPT_LIBS = #POPT_LIBS#
POPT_REQUIRED = #POPT_REQUIRED#
RANLIB = #RANLIB#
RC = #RC#
STRIP = #STRIP#
VERSION = #VERSION#
VERSION_INFO = #VERSION_INFO#
[...]
lib_LTLIBRARIES = libots-1.la
[...]
libots-1.la: $(libots_1_la_OBJECTS) $(libots_1_la_DEPENDENCIES)
$(LINK) -rpath $(libdir) $(libots_1_la_LDFLAGS) $(libots_1_la_OBJECTS) $(libots_1_la_LIBADD) $(LIBS)
[...]
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
You need msys to run ./configure
Call msys.bat
cd to your e.g. c:\msys\1.0\src\ots-0.5.0 folder
run ./configure
you need also popt-1.5 . So if you don't have it , you have to download and build it first.
It's not that easy to build with mingw .
I would suggest first of all, download , the binary version for windows. If it runs without problems on your system, you can try to build it yourself. Ots-0.4.2-Win32-binary.zip
I doubt that this binary version works without error.
If you have time (3 days will not be enough)
you can download popt-1.8-1-src.zip .
But you must have also see line : configure:20043: checking for glib-2.0 >= 2.0 libxml-2.0 >= 2.4.23
and more.