I’m trying to compile an application using mingw-w64.
My operating system is macOS Catalina.
mingw-w64 is installed using Homebrew (brew install mingw-w64).
First I define which compiler to use, like this:
export 'CC=/usr/local/bin/i686-w64-mingw32-gcc'
Now I wonder how I should call make.
Should I call it like this:
CC="$CC" make -f ./makefile.foo
Or should I call it like this?
make -f ./makefile.foo CC="$CC"
Related
Edit as of ZMQ version 4.1:
Configure automatically looks for libsodium, so this is no longer required. If for some reason you wish to build it WITHOUT libsodium and you have it built and installed, configure libzmq with '--without-libsodium'.
So I'm having problems building/making zeromq with libsodium.
im using msys2 as the shell - specifically the mingw32_shell - , and zmq 4.1.0 rc1 with libsodium 1.0.1 and mingw-w64 32bit (gcc 4.9.2).
im currently able to compile libsodium like this
cd .../libsodium
bash configure
make
make check
make install
and everything is fine, all the tests pass and the libs and includes end up in the /usr/local/ folders that msys2 seems to know about.
then when i try to build zeromq with these commands
cd .../zeromq
bash configure --with-libsodium
make
make check
make install
i never get past the configure stage, as configure returns
checking for sodium_init in -lsodium... no
configure: error: libsodium is not installed. Install it or don't pass --with-libsodium to configure script
i have tried the methods suggested in this post - ZeroMQ doesn't spot libsodium - but to no success.
therefore my question is thus: how do i either set the locations for zeromq's configure to look for libsodium to spot, whether with --with-libsodium, --with-libsodium-include-dir= and --with-libsodium-lib-dir=, or have them 'installed' in a location that msys2's shell is able to find?
I assume you tried it already since the link you provided mentions it:
--with-libsodium=/usr/local
I tried this and it worked for me. However, I don't recommend this because for MSYS2, it is cleaner if /usr/local is used only for MSYS2 software, and not MinGW-w64 software. For MinGW-w64 i686 software, the 'right' prefix for 'local' is /mingw32/local
I've just now added libsodium as a dependency on the zeromq package.
Github MinGW-w64 zeromq PKGBUILD commit e32ae0
I will ask Alexey to rebuild and repackage it tomorrow.
I'm wanting make use of the Libebur128 tool. It's a tool for checking loudness levels of audio files for broadcast compliance.
I've installed via homebrew:
brew install libebur128
There is however no unix executable so it can't be run by using $ebur128 [audiofile]
I've tried getting the source https://github.com/jiixyj/libebur128 and doing the following;
mkdir build
cd build
cmake ..
make
But still no executable.
Any ideas?
If you want to use libebur128 from CLI (e.g. as a tool), I would recommend checking out this project (the r128x-cli part).
how to use and install SystemC in terminal mac OS X?
I tried the Logic poet application, But i use os x 10.10 so it doesn't work.
so i want to know how can i compile and execute SystemC in terminal.
I could't find the detail of SystemC in terminal.
Thank you
The other answer is correct and perfectly fine, however, I thought I'd also answer and provide a little more detail.
Install Apple's "Command Line Tools"
You have two options: install Xcode (a big download), or just the command line tools (a much smaller download). If your goal is simply building SystemC applications at the command line, then I recommend the latter.
Install Apple's "Command Line Tools" by launching Terminal, entering
$ xcode-select --install
then clicking Install. After that, you'll have make, clang and more available at the command line.
Build and install Accellera's SystemC implementation
Download the latest release from the Accellera Downloads page (annoyingly, you'll have to provide a few personal details) and extract the contents of the .zip file.
I like to keep a copy of the SystemC source code available, because it can be useful for debugging or understanding how something works. Therefore, I move the extracted folder (systemc-2.3.1) into ~/Work/Other. That's where I keep source code for third party libraries. However, you can put it wherever you like.
Open Terminal, change into the extracted folder (systemc-2.3.1), and execute:
$ mkdir build
$ cd build
$ export CXX=clang++
$ ../configure --with-arch-suffix=
$ make install
The --with-arch-suffix= option prevents a -macosx64 suffix being add to the lib folder name, allowing your build scripts to be simpler.
After that process, the salient include and lib folders should be available within the systemc-2.3.1 folder.
Configure your build environment
There are many ways you can do this; I have a simple approach that I believe is close to what the SystemC maintainers envisioned. I define two environment variables in my .bash_profile (which is executed for every new Terminal session on OS X):
export CXX="clang++ -fcolor-diagnostics"
export SYSTEMC_HOME=~/Work/Other/systemc-2.3.1
Build a SystemC application
You could use Make, the quintessential build tool, which you get with Apple's "Command Line Tools", or any one of the plethora of other options. I use SCons with SConstruct files that look something like this:
import os
env = Environment(CXX=os.environ["CXX"],
SYSTEMC_HOME=os.environ["SYSTEMC_HOME"],
CPPPATH="$SYSTEMC_HOME/include",
LIBPATH="$SYSTEMC_HOME/lib")
env.Program("main.cpp", LIBS="systemc")
View trace (VCD) files
Scansion is a nice tool for this. GTKWave is another option, but it's a bit clunky.
Ensure you have xcode command line tools installed.
Follow instructions provided in the official repository.
From personal experience.
Compiling SystemC library with clang results in segmentation fault: 11
error every time I include systemc library into my code. To avoid this use gcc instead.
Note that I use gcc-8, installed with homebrew.
$ cd path/to/systemc-2.3.3
$ mkdir objdir
$ cd objdir
$ export CXX=g++-8
$ ../configure
$ make
$ make install
Use $ make check to launch examples compilation and unit tests.
To compile and run hello world example:
$ export SYSTEMC_HOME=path/to/systemc-2.3.3
$ g++-8 hello.cpp -o hello.o -L $SYSTEMC_HOME/lib-macosx64 -I $SYSTEMC_HOME/include/ -l systemc
$ ./hello.o
Tested on macOS 10.13.6; gcc version 8.2.0; systemc-2.3.3
Install
Go here click the first link and fill in your information to get the source code
http://www.accellera.org/downloads/standards/systemc
Then cd to the folder
Then run the following commands
./configure --with-unix-layout
gmake
sudo gmake install
gmake clean
After you do that it should all be saved in your use/local/(lib&include) directories
To Use
In code do this
#include "systemc.h"
I use a single makefile normally. But you could write the following to link the library. Given your cpp file is called main.
g++ -o main main.cpp -I/usr/local/include -L/usr/local/lib -lsystemc
I was following an online tutorial to install some Python modules using homebrew and one step was to install gfortran with brew install gfortran. Later on, I tried using another third-party installation script to install some Python modules and after the fact I realized that part of what the script did was download and run http://r.research.att.com/tools/gcc-42-5666.3-darwin11.pkg. I don't know that much about gfortran, but looking at the brew formula for gfortran it appears that brew uses a different version from the att.com one. Will that lead to problems in the future? I did brew uninstall gfortran and brew install gfortran again, and so far it seems like things are the same (I tried recompiling the old code that I had compiled before), but I am not sure what all the att.com pkg did. (I have OS X 10.8.2 and XCode 4.2 if that matters).
It depends on where the other gfortran installer goes to. In general, no, it won't conflict. * Homebrew is designed to be compatible with third-party gfortran installs - it defines dependencies on a generic "fortran" compiler, and not on the specific gfortran Homebrew formula. Homebrew stays under /usr/local, sticking the main install in /usr/local/Cellar, and symlinking judiciously in to /usr/local/lib. Other installers that install to /usr/local will just prevent Homebrew from linking its own compiler in, but will work with other formulas that use a fortran compiler. (Assuming the gfortran build options are compatible.)
That particular gcc-42 installer you linked to installs to /usr, not to /usr/local.** And its binaries are suffixed with "-4.2"; that is, it installs cpp-4.2, g++-4.2, gfortran-4.2, and so on. So a) there's no direct conflict with the Homebrew gfortran, and b) it won't directly shadow the /usr/local/bin/gfortran installed by Homebrew.
Which compiler will get picked up by things you build with both these gfortrans installed will depend on how the build works, but most will be looking for plain gfortran and so will find the Homebrew one, unless you explicitly direct them to the AT&T-provided one. You don't specify how you're building things, but since you're using brew, I'm assuming it's via brew or command line tools, in which case I think they're all probably seeing the Homebrew gfortran and ignoring this one. Look at the verbose output from their build processes to find out for sure.
*Depending, of course on what you mean by "conflict".
**Side note: AFAIK there's no easy way to figure this out by looking at the package or an installation manager. I just did a find /usr before and after running that installer, and did a diff on the output:
$ diff usr_before_any_installs.txt usr_after_att_install.txt | grep '^[<>]'
> /usr/bin/c++-4.2
> /usr/bin/cpp-4.2
> /usr/bin/g++-4.2
> /usr/bin/gcc-4.2
> /usr/bin/gfortran-4.2
> /usr/bin/i686-apple-darwin11-cpp-4.2.1
> /usr/bin/i686-apple-darwin11-g++-4.2.1
> /usr/bin/i686-apple-darwin11-gcc-4.2.1
> /usr/bin/i686-apple-darwin11-gfortran-4.2.1
> /usr/include/gcc
> /usr/include/gcc/darwin
> /usr/include/gcc/darwin/4.2
...
I have a project which requires opencl. I have installed CUDA and openCL on my machine but when I 'make' my project the following error occurs:
CL/cl.h: No such file or directory
I know that the i can create a hard link (in my unix (ubuntu) system) to fix the problem:
ln -s /usr/include/nvidia-current/CL
But i consider this a quick fix and not the correct solution. I would like to handle this in my makefile (i guess) so that a simple "make" command would compile. How could I do this?
You need to pass an appropriate -I option to the compiler (by setting CPPFLAGS or CFLAGS, for example). -I/usr/include/nvidia-current sounds like it'd work.
I saw this thread from compile opencl program using CL/cl.h file
I installed 7.5 and added below link in /usr/include, it works for my opencl program. looks like CUDA forget to implement this link after the installation.
ln -s /usr/local/cuda-7.5/include/CL /usr/include
Are you using Ubuntu or Debian distro? Then now you can use this package:
sudo apt-get install opencl-headers