Error while compiling Halide program using Linux command in Windows environment through Cygwin - halide

I downloaded Halide binaries for Linux. For compiling the tutorial programs(especially the autoscheduler program), I need to install g++ version 5.3. But, I am not able to install this particular version. How to solve the problem? Please find the instructions below copied from the link : https://github.com/halide/Halide/releases
Update 1:
I ran the command sudo apt install g++-5.3 . I got the error "Unable to locate the package g++5.3"
Update 2:
These are some of the errors I get.
Update 4:
I want to run this program :
https://halide-lang.org/tutorials/tutorial_lesson_21_auto_scheduler_generate.html.
The linux command is given at the very top of the above link. I am pasting it below:
g++ lesson_21_auto_scheduler_generate.cpp ../tools/GenGen.cpp -g -std=c++11 -fno-rtti -I ../include -L ../bin -lHalide -lpthread -ldl -o lesson_21_generate
Additionally, I moved the "libHalide.a" file from the lib folder to the bin folder and executed the commmand.

The problem is that you're on Windows, as your references to x86_64-pc-cygwin and /cygdrive/c in your screenshot indicate, but you're trying to use the Linux binaries. Cygwin is only source-compatible with Linux programs, not binary-compatible. Here's your choices:
Use the Windows or MinGW downloads instead of the Linux ones (you may have to switch to MinGW)
In Ubuntu in VirtualBox, just install g++ instead of g++-5.3, and then use the Linux download there

Related

How to Compile Ncurses Program for Native Windows Use

I'm trying to compile a C program using Ncurses on Windows. I compiled it successfully using GCC and it works perfectly if I run it in Cygwin or MSYS2. However, if I try to run it in the Windows Command Prompt, I get this error:
Error opening terminal: xterm-256color.
Is it possible to compile it to run using the native Windows console? This is how I've been compiling it:
gcc -o PROGRAMNAME main.c -lncurses
I also have the Cygwin and Msys dlls for Ncurses copied into the directory of the compiled executable.
Update
So I figured out how to get the program to run. I deleted all the DLLs from the project folder and then added "C:\msys64\usr\bin" to my PATH environment variable. However, I would still like to know if there's a way to get this to work if I were to distribute it, since it's still relying on my installation of MSYS2.
Update 2
Gave up and just used pdcurses and it works fine.
Update 3
Nevermind, found a solution! See below.
I figured out a solution. I'll post it here in case anyone else has this same issue. Thanks to Thomas Dickey for your help!
Install the mingw-w64 toolchain and any other packages you need to compile your project (this is mostly where I messed up)
Make sure to include the /mingw64/include/ncurses directory when compiling, or else gcc won't be able to find curses.h
Include /mingw64/bin as a static directory or copy over the necessary dlls to the same folder as the directory
I ended up with this to compile:
gcc -I/mingw64/include/ncurses -o PROGRAMNAME main.c -lncurses -L/mingw64/bin -static

How to Compile mingw-w64-crt

I'm on Windows 10 and using the latest version of MSYS2 (with gcc installed: pacman -S gcc)
I'm trying to compile mingw-w64-headers and mingw-w64-crt from mingw-w64-v7.0.0
Inside of my MSYS2 installation directory C:\msys2 I have created the folder mingw-w64 which I reference in the prefix argument below.
To compile each of these I use the same steps (replace name of library where appropriate):
mkdir mingw-w64-crt && cd mingw-w64-crt
../mingw-w64-v7.0.0/mingw-w64-crt/configure --prefix=/mingw-w64
make
make install
This works for mingw-w64-headers however for mingw-w64-crt I encounter errors at the make step. Specifically: incompatible types when assigning to type 'mbstate_t' {aka 'struct anonymous'} from type 'int'. A more detailed error image can be found here.
I would appreciate some guidance as to how to proceed.
I suggest that you just open one of MSYS2's MinGW environments (by running mingw32.exe or mingw64.exe) and then install the complete MinGW-w64 toolchain by running this:
pacman -S $MINGW_PACKAGE_PREFIX-toolchain
The toolchain includes GCC, the MinGW-w64 libraries, and the MinGW-w64 headers. If those prebuilt MinGW-w64 things are good enough for you, then you're done.
If you want to compile your own MinGW-w64, then should be able to use the environment you just installed to do it. To double-check that you are using the right toolchain, run which gcc and make sure it returns /mingw64/bin/gcc or /mingw32/bin/gcc.
Performing the following has allowed me to successfully compile:
pacman -S $MINGW_PACKAGE_PREFIX-toolchain
mkdir mingw-w64-crt && cd mingw-w64-crt
../mingw-w64-v7.0.0/mingw-w64-crt/configure --prefix=/mingw-w64 --with-sysroot=/mingw64
make -j %NUMBER_OF_PROCESSORS%
make install

Compilation of MPI - cuda aware program fails [duplicate]

when I compile my script with only
#include <mpi.h>
it tells me that there is no such file or directory.
But when i include the path to mpi.h as
#include "/usr/include/mpi/mpi.h"
(the path is correct) it returns:
In file included from /usr/include/mpi/mpi.h:2087:0,
from lbm.cc:7:
/usr/include/mpi/openmpi/ompi/mpi/cxx/mpicxx.h:35:17: fatal error: mpi.h: No such file or directory
#include "mpi.h"
^
compilation terminated.
Anyone know how to fix this?
The problem is almost certainly that you're not using the MPI compiler wrappers. Whenever you're compiling an MPI program, you should use the MPI wrappers:
C - mpicc
C++ - mpiCC, mpicxx, mpic++
FORTRAN - mpifort, mpif77, mpif90
These wrappers do all of the dirty work for you of making sure that all of the appropriate compiler flags, libraries, include directories, library directories, etc. are included when you compile your program.
On my system, I was just missing the Linux package.
sudo apt install libopenmpi-dev
pip install mpi4py
(example of something that uses it that is a good instant test to see if it succeeded)
Succeded.
You can execute:
$ mpicc -showme
result :
gcc -I/Users/<USER_NAME>/openmpi-2.0.1/include -L/Users/<USER_NAME>/openmpi-2.0.1/lib -lmp
This command shows you the necessary libraries to compile mpicc
Example:
$ mpicc -g -I/Users/<USER_NAME>/openmpi-2.0.1/include -o [nameExec] [objetcs.o...] [program.c] -lm
$ mpicc -g -I/Users/<USER_NAME>/openmpi-2.0.1/include -o example file_object.o my_program.c otherlib.o -lm
this command generates executable with your program in example, you can execute :
$ ./example
On my system Ubuntu 16.04. I installed :
sudo apt install libopenmpi-dev
after I used mpiCC to compile and it works
As suggested above the inclusion of
/usr/lib/openmpi/include
in the include path takes care of this (in my case)
Debian appears to include the following:
mpiCC.openmpi
mpic++.openmpi
mpicc.openmpi
mpicxx.openmpi
mpif77.openmpi
mpif90.openmpi
I'll test symlinks of each for mpic, etc., and see if that helps the likes of HDF5-openmpi enabled find mpi.h.
Take that back Debian includes symlinks via their alternatives system and it still cannot find the proper paths between HDF5 openmpi packages and mpi.h referenced in the H5public.h header.
On Ubuntu 18.04 I had to install:
sudo apt install lam4-dev
On Fedora:
dnf install openmpi-devel
On Mac 12.2, I installed with brew install openmpi. The header file is under /opt/homebrew/Cellar/open-mpi/x.x.x/include.
once you have mpi installed:
$ sudo apt install mpich
see where the library is installed, each case is different:
$ mpicc -show
in my case: (Ubuntu 20.0)
and add...
#include </usr/lib/x86_64-linux-gnu/openmpi/include/openmpi>
:-)

Cant build V8 with GYP successfully on Mac OSX

I followed V8 Build Instructions from here
Here are the steps that I'm following to build V8 on Mac OSX.
1. git clone git://github.com/v8/v8.git v8-src && cd v8-src
2. make dependencies
3. make x64 -j8 library=shared snapshot=on console=readline
But I do not see out/x64.release/obj.target/tools/gyp/libv8_base.x64.a (or snapshot.a)
The Folder only contains js2c.stamp
Here is the Gist: Build Output
What am I doing wrong ..
Ok, the documentation specifies the location for Linux Machines. For Mac OSX, these files are here :
out/x64.release/libv8_base.x64.a (& snapshot.a)
Finally, compile your C++ Module, by linking V8, as below:
g++ -Iinclude test.cc -o test out/x64.release/libv8_{base.x64,snapshot}.a -lpthread

OSX 10.7.4 w/XCode 4.4.1 & GCC (Issues w/compiling straight C/C++)

The issue I'm having is that gcc (and family) don't appear to be properly setup. I have a 10.7.4 machine that I just installed Xcode on (from the app store). I've done no prior development on this machine.
Working w/in Xcode seems to work fine. I can build and compile no problem. However, trying to execute gcc command line fails.
First, I gcc wasn't on my path ... no big deal. I located it and ran as:
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -dynamiclib -fno-common -o s.dylib s.c
(I'm working on a lib w/some functions...). Anyways, it fails.
s.c:1:19: error: stdio.h: No such file or directory
s.c:2:20: error: stdlib.h: No such file or directory
s.c:3:20: error: string.h: No such file or directory
Surprise! hah, well I searched my machine for stdio.h and I can't find it anywhere. Since I've been out of the OSX game for a bit, I'm assuming I'm missing something -
Basically I want to be able to continue using Xcode but I want to be able to build C/C++/etc on the command line with all the dependencies (.h) in the correct place.
Any thoughts?
There are two main ways to run the compiler from the command line: the Command Line Tools package, and xcrun.
xcrun is particularly good if you just need this occasionally. Just stick "xcrun" at the start, like you'd do with sudo:
xcrun gcc -dynamiclib -fno-common -o s.dylib s.c
This will find the correct version of gcc and set the needed directories, etc. You can specify a specific SDK with --sdk.
If you do this a lot, download and install the Command Line Tools package (Xcode>Open Developer Tool>More Tools...; it also may be available in Preferences>Downloads). This installs a full copy of everything in /usr.
Probably xcrun is not enough if you are using 10.8.
Looking in to the clang documentation I found that you need to include the system root because you do not have your libraries in the standard place but inside Xcode.
using:
xcrun gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
or:
xcrun clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk

Resources