Vala examples compile errors - windows

Installed Vala for Windows64 from the MSYS2 project. Started running various examples from https://wiki.gnome.org/Projects/Vala/Examples. Some examples produce errors like
... the "Clutter Samples:Animated Actors"
D:\Projects\Vala\Examples>valac.exe --version
Vala 0.36.1-dirty
D:\Projects\Vala\Examples>valac.exe --pkg clutter-1.0 clutter.vala -o clutter.exe
D:/Projects/Vala/Examples/clutter.vala.c:7:29: fatal error: clutter/clutter.h: No such file or direc
tory
#include <clutter/clutter.h>
^
compilation terminated.
error: cc exited with status 1
Compilation failed: 1 error(s), 0 warning(s)
... and the "Vala GTK+ 3.x Examples: Basic Sample"
D:\Projects\Vala\Examples>valac.exe --version
Vala 0.36.1-dirty
D:\Projects\Vala\Examples>valac.exe --pkg gtk+-3.0 gtk+3-hello.vala -o gtk+3-hello.exe
D:/Projects/Vala/Examples/gtk+3-hello.vala.c:17:21: fatal error: gtk/gtk.h: No such file or director
y
^
compilation terminated.
error: cc exited with status 1
Compilation failed: 1 error(s), 0 warning(s)
...and the Vala Collections: libgee sample
D:\Projects\Vala\Examples>valac.exe --version
Vala 0.36.1-dirty
D:\Projects\Vala\Examples>valac.exe --pkg=gee-0.8 libgee-collections.vala -o libgee-collections.exe
error: Package `gee-0.8' not found in specified Vala API directories or GObject-Introspection GIR di
rectories
Compilation failed: 1 error(s), 0 warning(s)
I realize pkg:gee-0.8 is not installed, but I did find 0.20.0-1 using pacman. I dont know how to reference this library?
$ pacman -Ss gee -v
Root : /
Conf File : /etc/pacman.conf
DB Path : /var/lib/pacman/
Cache Dirs: /var/cache/pacman/pkg/
Hook Dirs : /usr/share/libalpm/hooks/ /etc/pacman.d/hooks/
Lock File : /var/lib/pacman/db.lck
Log File : /var/log/pacman.log
GPG Dir : /etc/pacman.d/gnupg/
Targets : gee
mingw32/mingw-w64-i686-libgee 0.20.0-1
A collection library providing GObject-based interfaces and classes for
commonly used data structures (mingw-w64)
mingw64/mingw-w64-x86_64-libgee 0.20.0-1
A collection library providing GObject-based interfaces and classes for
commonly used data structures (mingw-w64)
Obviously my installation is incorrect/incomplete. What do I need to change or install to fix these type of issues?
Thanks for your help!

Running valac.exe directly can be a problem.
Usually when using msys2 to compile something you first enter the msys2 shell with the MSYSTEM environment variable set up correctly. (there are scripts and in newer versions executables in the msys2 root folder that can do that for you).
For example when you set MSYSTEM=MINGW64 (caveat: MINGW64 must be upper case!) and then run mingtty.exe or bash.exe --login you can then check your PKG_CONFIG_PATH var:
$ echo $PKG_CONFIG_PATH
/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig
Be sure to understand the difference of the three MSYSTEM settings:
MSYS - Only used to bootstrap the core msys2 system and for packaging purposes
MINGW32 / MINGW64 - The "normal" environment (32-Bit / 64-Bit) you work in when using msys2.
The pacman package names for the different MSYSTEM environment have prefixes. I.e. the packages that start with mingw-w64-x86_64 are used in the MSYSTEM=MINGW64 environment.
vala uses pkg-config (be sure to have mingw64/mingw-w64-x86_64-pkg-config installed) when you specify something with --pkg and pkg-config then searches for .pc files (like gee-0.8.pc).
The mingw-w64-x86_64-libgee package installs its pc file as /mingw64/lib/pkgconfig/gee-0.8.pc.

With gee-0.8 the 0.8 is the interface version number, not the release version number. So install release 0.20.0 and the relevant interface files should become available. That also applies to Clutter and GTK+3.

Related

Header files not found by 'make'

The make instruction is not finding the libraries required for compilation. They are in other folder than the usual /usr/include folder.
I'm complying a simulation software called magnum.fe I already installed all the required dependencies (FEniCS = 1.5
CMake >= 2.8
SWIG >= 2.0
G++ >= 4.0) and started to run make as the instructions suggest.
$ cd /path/to/magnum.fe
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install
But when running make I get the following error:
/usr/include/petscsys.h:136:12: fatal error: petsc/mpiuni/mpi.h: No such file or directory
136 | # include <petsc/mpiuni/mpi.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
The files do exist, but in other folder: /home/myusername/bin/petsc/include/mpiuni/mpi.h
I compiled petsc on /home/myusername/bin/petsc/ with the following instruction:
$ ./configure --with-cc=gcc --with-cxx=g++ --with-fc=gfortran --download-mpich --download-fblaslapack
$ make all check
It compiled it sucessfully but I couldn't get the magnum.fe compilation to finish.
I tried moving each header file to /usr/include but now I'm stuck on if moving the whole petsc directory into this folder. It must be a more elegant way to do it.
Thanks
I've made it!
There are two options available:
Specify the libraries to use with the make command editing the MAKEfile, use the variable LDLIBS to set it up. Detailed usage in here: https://web.archive.org/web/20070723140628/http://arco.inf-cr.uclm.es/~david.villa/doc/repo/make/make.html#AEN36
or
Create symbolic links pointing to /usr/include. In my case I used:
ln -s /home/myusername/bin/petsc/include/* /usr/include

Compile go program with C dependency for Windows

Building go works fine for pure go project with pure go dependencies. But when building a project with a C dependency, it fails on Windows:
go build -a -o bin/xyz.exe ./xyz/main.go
go: downloading gopkg.in/confluentinc/confluent-kafka-go.v1 v1.4.2
go: downloading github.com/confluentinc/confluent-kafka-go v1.4.2
# gopkg.in/confluentinc/confluent-kafka-go.v1/kafka
In file included from C:\Users\VssAdministrator\go\pkg\mod\gopkg.in\confluentinc\confluent-kafka-go.v1#v1.4.2\kafka\00version.go:24:
./librdkafka/rdkafka.h:83:10: fatal error: sys/socket.h: No such file or directory
#include <sys/socket.h> /* for sockaddr, .. */
^~~~~~~~~~~~~~
compilation terminated.
mingw32-make: *** [Makefile:10: build-windows] Error 2
##[error]Cmd.exe exited with code '2'.
Finishing: CmdLine
As can be seen from the output above, I'm using a Makefile, and my azure-pipelines.yml looks like this:
...
- script: 'make package-windows'
...
Here's my Makefile:
build-windows:
go build -a -o bin/xyz.exe ./xyz/main.go
I also tried setting GOOS and GOARCH, to no avail:
build-windows:
GOOS=windows GOARCH=amd64 go build -a -o bin/xyz.exe ./xyz/main.go
So how can I build this?
This doesn't have much to do with Go - it seems you're doing everything correctly in that regard. The issue is that the library you're using needs sys/socket.h which simply doesn't exist on Windows (see Using sys/socket.h functions on windows).
Your options are similar to what's mentioned in the other answer:
Try to build using Cygwin.
Modify the library to use Winsock instead of sys/socket.h.
Find a different library, one that supports Windows (the author of the library you're using specifically said Windows is not supported).

Recompile Hadoop 2.5.1 native libraries to 32 bit

Phase 1: I have installed Hadoop 2.6.0 on Ubuntu 14.04 64bit, I have started it in pseudo-distributed mode and I ran the sample program they provide . Everything ok here.
Phase 2: I have installed Hadoop 2.5.1 on 3 computers that run Ubuntu 10.04 32bit. I have started the HDFS and YARN, I can see them in the web GUI. But when try to compile the same test program I get this:
gcc test.c -I$HADOOP_HDFS_HOME/include -L/usr/lib/java/jdk1.7.0_71/jre/lib/amd64/server/ -L$HADOOP_HDFS_HOME/lib/native -lhdfs -ljvm -o test
/usr/bin/ld: skipping incompatible /usr/local/hadoop/lib/native/libhdfs.so when searching for -lhdfs
/usr/bin/ld: skipping incompatible /usr/local/hadoop/lib/native/libhdfs.a when searching for -lhdfs
/usr/bin/ld: cannot find -lhdfs
collect2: ld returned 1 exit status
Now, when I do file libhdfs.so.0.0.0 , I get :
libhdfs.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
So, the native libraries are 64bit and my OS is 32bit.
Question:
Is it necessary to recompile entire Hadoop from source or can I only recompile native libraries and replace them in the existing installation?
What is the shortest path ?
Please provide info on recompilation.
Edit:
I have compiled for 32bit on my 64bit machine, I've exported CLFAGS=-m32 , but I had this error :
[exec] /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so: error adding symbols: File in wrong format
[exec] collect2: error: ld returned 1 exit status
[exec] make[2]: *** [target/usr/local/lib/libhdfs.so.0.0.0] Error 1
[exec] make[1]: *** [CMakeFiles/hdfs.dir/all] Error 2
What I did next was to manually install and configure update-alternatives to point java8 JDK 32bit.
I only had a problem with libfuse-dev, which I have uninstalled.
Since it was not mandatory.
After that I ran : mvn package -Pnative -DskipTests -Dtar
and found the libs here : hadoop-hdfs-project/hadoop-hdfs/target/native/target/usr/local/lib :
libhdfs.a libhdfs.so libhdfs.so.0.0.0
The recent hadoop tarballs only seem to ship with 64 bit libraries. You can compile them yourself, altough i haven't tested this myself.
You will have to download the source tarball of hadoop and install the following packages:
GCC (or another C compiler)
GNU Autotools (autoconf, automake, libtool)
zlib dev package
openssl dev package
maven
Once this is installed you can use the standard hadoop pom.xml file contained in the source tarball to compile the native libraries:
$ mvn package -Pdist,native -DskipTests -Dtar
The libraries can be found in:
$ hadoop-dist/target/hadoop-2.6.0/lib/native
The bin/hadoop script ensures the native hadoop library is on the classpath via the system property -Djava.library.path. You can modify the bin/hadoop script to point to your newly compiled libraries. For more information be sure to check the documentation that is available here.

Unable to build Boost libraries with GCC

I am using Windows 7 64-bit, and want to compile the non-precompiled libraries (specifically, I need Filesystem) from the command line (I do not use MSVC). I have MinGW, but read on the Boost website that MSYS shell is not supported, so I'm trying to compile the libraries from the Windows command prompt.
First of all, running bootstrap.bat results in the following error:
Building Boost.Jam build engine
'cl' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Jam build engine.
Please consult bjam.log for furter diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bjam.log in that case.
Plus, there is not bjam.log file anywhere in the boost_root directory.
Disregarding this error, and trying to run the downloaded bjam.exe file, I get another error:
c:/boost_1_45_0/tools/build/v2/build\configure.jam:145: in builds-raw
*** argument error
* rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? )
* called with: ( <pbin.v2\libs\regex\build\gcc-mingw-4.5.2\debug\address-model64\architecture-x86>has_icu.exe : : ignore-minus-n : ignore-minus-q )
* extra argument ignore-minus-q
(builtin):see definition of rule 'UPDATE_NOW' being called
c:/boost_1_45_0/tools/build/v2/build\configure.jam:179: in configu
re.builds
c:/boost_1_45_0/tools/build/v2/build\configure.jam:216: in object(
check-target-builds-worker)#409.check
etc. with quite a lot of complaints. Setting the 'architecture' and 'address-model' options doesn't help.
Any suggestions?
#Andre
Following Andre's suggestion, I created minGW-bjam that was running for an hour and a half and built most of the libraries, but not the one I need at this moment: Filesystem.
Trying to compile only Filesystem, specifying version 2 with define="BOOST_FILESYSTEM_VERSION=2" and --disable-filesystem3 does not help. I get the following error:
gcc.compile.c++ bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o
In file included from ./boost/filesystem/v3/operations.hpp:24:0,
from libs\filesystem\v3\src\operations.cpp:48:
./boost/filesystem/v3/config.hpp:16:5: error: #error Compiling Filesystem version 3
file with BOOST_FILESYSTEM_VERSION defined != 3
libs\filesystem\v3\src\operations.cpp:647:26: warning:
'<unnamed>::create_symbolic_link_api' defined but not used
"g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -
DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_SYSTEM_DYN_LINK=1 -
I"." -c -o "bin.v2\libs\filesystem\build\gcc-mingw-4.5.2\debug\v3\src\operations.o"
"libs\filesystem\v3\src\operations.cpp"
etc. with a lot of ...failed statements.
Any hints here?
It's easy. Just use "bootstrap.bat gcc" to select GCC
The bootstrap script assumes the msvc compiler is available. But you can build bjam by hand without the bootstrap script:
Step into the tools\build\v2\engine\src directory and call "build.bat mingw". It will create a bjam.exe. You can then put it in your %PATH% or perhaps in the root boost directory...
To be honest, I usually build bjam like this with the msvc compiler and use this "msvc-bjam" to build my mingw boost libraries.
So... the first part of the problem was solved by Andre's suggestion.
The second part was solved by setting the variable BOOST_FILESYSTEM_VERSION to 3 everywhere (the error above complains about incompatibility with what is set in file user.hpp). Although this is not the default option for Boost 1.45 that I'm using, it's the only thing that works (i.e. bjam wants to compile version 3 no matter what). So now I have version 3 of the filesystem library, and version 2 for all others, but that doesn't seem to be an issue for the moment.
I do have a problem with using Boost with OpenCV and Eigen libraries, though... off to the next challenge ;)
Since I can't comment yet, I want to add that I ran
bootstrap mingw
to generate b2 properly and then
b2 --build-dir="c:\boost_release" toolset=gcc --build-type=complete "c:\boost_release\stage"
The includes will be located at your boost root folder (boost_1_58_00/boost) and your binaries at the specified build folder.

Building GCC cross compiler (from "Linux" to "Windows")

I want to build "gcc cross-compiler" to compile "c/c++" applications on "Linux" environment but for "Windows" target.
I have made this so far:
Installed the necessary tools and packages for building GCC listed on "Prerequisites for GCC" page.
Downloaded required sources:
"gcc-core-4.4.1", "gcc-g++-4.4.1", "binutils-2.19.1", "w32api-3.13-mingw32", "mingwrt-3.16-mingw32"
Created this directory hierarchy:
"${HOME}/gcc/" - for final cross-compiler
"${HOME}/src/" - for sources
"${HOME}/src/build-binutils/i386-mingw32/" - for building binutils to "i386-mingw32" target
"${HOME}/src/build-gcc/i386-mingw32/" - for building gcc to "i386-mingw32" target
Builded binutils package:
cd "${HOME}/src/build-binutils/i386-mingw32/"
../../binutils-2.19.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --disable-nls
make
make install
Copied "w32api" and "mingwrt" headers to the install directory:
cp -R "${HOME}/src/w32api-3.13-mingw32/include" "${HOME}/gcc/i386-mingw32"
cp -R "${HOME}/src/mingwrt-3.16-mingw32/include" "${HOME}/gcc/i386-mingw32"
And now when I am trying to build the "c (only) cross-compiler":
cd "${HOME}/src/build-gcc/i386-mingw32/"
../../gcc-4.4.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --enable-languages=c --with-headers="${HOME}/gcc/i386-mingw32/include" --disable-nls
make<br>
it was building something about 4 minutes and then gives me these errors:
${HOME}/gcc/i386-mingw32/bin/ld: dllcrt2.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dll] Error 1
make[2]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32/i386-mingw32/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32'
make: *** [all] Error 2
From that error message I really don't know what to do now :-((( .
Does anybody know where is the problem?
Thanks.
That's actually OK: the way things go, you need to
build binutils
install headers
build the a partial C compiler: enough to create object files, but not enough to link
build the win32api and mingw runtime (which includes your missing dllcrt2.o)
build a complete C compiler (and other front-ends, such as C++, Fortran, Ada, whatever, if you want them)
You have successful performed step 3 above; it fails building libgcc (which is a GCC support library), but that means the C compiler core is functionnal (although it won't be able to link, it can still create valid object files). You can check that by looking at the gcc/xgcc file in your GCC build directory.
So, you need to go to the next step, not worrying about your current failure.
(To actuall install the partial C compiler, you should run make with the -k option, to have it do it best, even in the face of errors. For example, use make -k install.)
There are precompiled cross-compilers of MinGW-w64 available.
This allows to compile native 32- and 64-bit Windows binaries from Linux, a two minute tutorial is available at http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/
Just in case you don't want to spend a lot of time trying to build it yourself.
I grepped through the MinGW sources, and found that dllcrt2.o is something built off the mingwrt package. I assume you have to compile and install that, not just copy the headers?

Resources