I'm trying to compile a C project on windows that has a dependency on gtk+-3.0 (using msys to build it). Here's the list of gtk packages that I installed:
$ pacman -Ss gtk | grep installed
mingw32/mingw-w64-i686-glib2 2.52.3-1 [installed]
mingw32/mingw-w64-i686-gtk3 3.22.18-1 [installed]
mingw32/mingw-w64-i686-gtkmm3 3.22.0-1 [installed]
mingw64/mingw-w64-x86_64-glib2 2.52.3-1 [installed]
msys/glib2 2.48.2-1 [installed]
However, when I run ./configure I get the following error:
checking for GTK... no
configure: error: Package requirements (gtk+-3.0 >= gtk_required_version) were not met:
No package 'gtk+-3.0' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Alternatively, you may set the environment variables GTK_CFLAGS and GTK_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
What did I do wrong?
The problem was due to compiling directly from bash instead of the shell environment setup for building native 32-bit apps (msys2_shell.cmd -mingw32)
Related
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
I wanted to install updated version of gcc on a server where I do not have root access. I tried
conda install -c creditx gcc-7
which was not working. Then I found
conda install -c anaconda gcc_linux-64
in fact installs gccv7.3. But after the successful installation, the conda environment still uses the system gcc at
/usr/bin/gcc
Please help me so that I can use the gcc v7.3 that I just installed.
As explained here: https://docs.conda.io/projects/conda-build/en/latest/resources/compiler-tools.html
1) All of the executables in a compiler package are "prefixed." Instead of gcc, the executable name of the compiler you use will be something like x86_64-conda_cos6-linux-gnu-gcc
2) Many build tools such as make and CMake search by default for a compiler named simply gcc, so we set environment variables to point these tools to the correct compiler.
So if you run:
conda create -n cc_env gcc_linux-64
conda activate cc_env
ls $CONDA_PREFIX/bin
You will see a bunch of compiler tools with the prefixed name:
c89 x86_64-conda_cos6-linux-gnu-ct-ng.config x86_64-conda_cos6-linux-gnu-gcov-dump x86_64-conda_cos6-linux-gnu-objdump
c99 x86_64-conda_cos6-linux-gnu-dwp x86_64-conda_cos6-linux-gnu-gcov-tool x86_64-conda_cos6-linux-gnu-ranlib
x86_64-conda_cos6-linux-gnu-addr2line x86_64-conda_cos6-linux-gnu-elfedit x86_64-conda_cos6-linux-gnu-gprof x86_64-conda_cos6-linux-gnu-readelf
x86_64-conda_cos6-linux-gnu-ar x86_64-conda_cos6-linux-gnu-gcc x86_64-conda_cos6-linux-gnu-ld x86_64-conda_cos6-linux-gnu-size
x86_64-conda_cos6-linux-gnu-as x86_64-conda_cos6-linux-gnu-gcc-ar x86_64-conda_cos6-linux-gnu-ld.bfd x86_64-conda_cos6-linux-gnu-strings
x86_64-conda_cos6-linux-gnu-cc x86_64-conda_cos6-linux-gnu-gcc-nm x86_64-conda_cos6-linux-gnu-ld.gold x86_64-conda_cos6-linux-gnu-strip
x86_64-conda_cos6-linux-gnu-c++filt x86_64-conda_cos6-linux-gnu-gcc-ranlib x86_64-conda_cos6-linux-gnu-nm
x86_64-conda_cos6-linux-gnu-cpp x86_64-conda_cos6-linux-gnu-gcov x86_64-conda_cos6-linux-gnu-objcopy
This is ok because environment variables like CC and CPP are pointing to the compiler to use, and commands like make know to use these variable:
$ echo $CC
/home/builder/anaconda3/envs/cc_env/bin/x86_64-conda_cos6-linux-gnu-cc
$ echo $CPP
/home/builder/anaconda3/envs/cc_env/bin/x86_64-conda_cos6-linux-gnu-cpp
For more info on what environment variables make is aware of see: https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
My ultimate goal is to get python package graph_tool working on my system and also on ipynb if possible. I have already brew install graph-tool, as indicated here, but that's still insufficient.
So I follow conda instructions here, and I make decent progress, until I encounter a compiler issue with the configuration.
$ conda create -n py36env python=3.6.3 anaconda
(py36env) $ conda install -c conda-forge cgal
... and so forth with the other required libraries
(py36env) Tams-MacBook-Pro:graph-tool-2.25 tamtam$ ./configure --prefix=/Users/tamtam/anaconda3/envs/py36env/ --with-python-module-path=/Users/tamtam/anaconda3/envs/py36env/lib/python3.6/site-packages
.
.
.
checking whether g++ supports C++14 features by default... no
checking whether g++ supports C++14 features with -std=gnu++14... no
checking whether g++ supports C++14 features with -std=gnu++1y... no
configure: error: *** A compiler with support for C++14 language features is required.
I'm not very familiar with compiler things, but I check my system as follows:
(py36env) Tams-MacBook-Pro:graph-tool-2.25 tamtam$ conda list | grep gcc
gcc 4.8.5 8
And outside of the conda env:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/tamtam/anaconda3/envs/py36env/bin/../libexec/gcc/x86_64-apple-darwin11.4.2/4.8.5/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure --prefix=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/
Thread model: posix
gcc version 4.8.5 (GCC)
And with Homebrew
$ brew list --versions | grep gcc
gcc 7.1.0 7.2.0
$ /usr/local/bin/gcc-7 --version
gcc-7 (Homebrew GCC 7.2.0) 7.2.0
$ echo $PATH
/Users/tamtam/anaconda3/bin:/Users/tamtam/anaconda/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin
So my questions are: EDITS INCLUDED
1) What's the difference between the conda gcc 4.8.5 and Homebrew gcc 7.2 on my system? I'm confused because they're each up-to-date packages.
EDIT: Nowhere online that I perused explicitly states this, but I am understanding (aka educated guess bc it's 3am and I need sleep) conda gcc 4.8.5 to just be equivalent to brew gcc 4.8.5, and that Anaconda is just way behind on developing an 'official' gcc supporting C++14. In the meantime I conda install -c salford_systems gcc-5 and ./configure seems to find itself a C++14 compiler. YAY (but this also led me to a new problem T.B.A.)
NOTE: I had also tried running the ./configure file with both conda gcc 4.8.5 and brew gcc 7.2.0 (switching of default gcc compiler guided here), but still same error of ./configure not finding C++14 compile (so ignore this)
2) I also have Xcode 8.3.3 that also comes with clang, which is what gcc is symlinked to... ?? No idea about the setup/relation
3) How can I adjust my system (for example, paths) so that the configuration process will detect a C++14 compiler? EDIT: resolved per 1)
(This solution is also included within the edits at the bottom of my question.)
Nowhere online that I perused explicitly states this, but I am understanding (aka educated guess bc it's 3am and I need sleep) conda gcc 4.8.5 to just be equivalent to brew gcc 4.8.5, and that Anaconda is just way behind on developing an 'official' gcc supporting C++14. In the meantime I conda install -c salford_systems gcc-5 and ./configure seems to find itself a C++14 compiler. YAY (but this also led me to a new problem)
NOTE: I had also tried running the ./configure file with both conda gcc 4.8.5 and brew gcc 7.2.0 (switching of default gcc compiler guided here), but still same error of ./configure not finding C++14 compile arises (so ignore this)
As a rule of thumb, if a product provides its own build tools (compiler, C headers, static libraries, include/library paths etc) instead of using the system's ones, you should use those when building things to use within its environment.
That's because, depending on include files, compiler, compiler version, compiler flags, predefined macros etc the same sources and libraries built with different toolchains can be binary incompatible. This goes double for C++ where there are no ABI standards at all. (In C, there are de facto ones for most platforms where there are competing compilers due to the need to do system calls.)
Now, what you have on your system:
The system's stock gcc (if any) is at /usr/bin (so includes are at /usr/include, static libraries at /usr/lib etc)
Homebrew's gcc 7.2 at /usr/local/bin (includes are probably at /usr/local/include)
Anaconda also has a gcc package that, if installed, would reside somewhere like /Users/<login>/anaconda3/envs/<env name>/bin
If an environment provides an own toolchain, it provides some way to make build scripts select that toolchain when building things. A common way is to set relevant environment variables (PATH, INCLUDE, LIB) - either directly or through some tool that the environment provides. Homebrew executables reside in /usr/local/bin which is always present in UNIX PATH as per the FHS; Anaconda adds itself to PATH whenever its environment is activated.
So, as you yourself guessed, since Anaconda provides its own gcc packages (thus enforces the compatibility of their output with its binary packages via package metadata - if there are known incompatibilities, the installation will fail due to requirement conflicts), you need to install one that meets graph-tool requirements -- which is gcc 5, available via gcc-5 package from salford_systems channel. Then specify --prefix as you already have.
You may need to install other dependencies, too, if you didn't already or you need optional features that they're required for.
I have XCode installed (Version 7.2.1 (7C1002)) in Yosemite and have downloaded and installed command line tools. When I try to check the gcc version I get:
$ gcc -v
Segmentation fault: 11
$
The output for:
$ type -a gcc
gcc is /usr/local/bin/gcc
gcc is /usr/bin/gcc
$
From what I understand, that should mean that I have it installed so I still don't understand why I can't check it's version. Since I will need gcc for other applications I would like to have it fixed...any suggestions? Do I need to link it somehow?
You have a faulty third-party version of gcc (or perhaps another compiler masquerading as gcc) installed in /usr/local. This may be something put there by Homebrew or maybe you installed this build of gcc yourself or something.
A short-term fix would be to modify your PATH environment variable so that /usr/bin comes before /usr/local/bin. Or, you could just always specify the full path to gcc, such as /usr/bin/gcc -v.
Longer term, you probably want to remove the broken gcc that's been installed to /usr/local. How you do that exactly depends on how you originally installed it there.
I'm trying to build a c++ project on Ubuntu 12.04 64-bit.
the project is 32-bit.
At the terminal output I receive such lines:
ibcrypto.a(bio_b64.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/x86_64-linux-
gnu/libcrypto.a(bio_asn1.o)' is incompatible with i386 output
collect2: ld returned 1 exit status
make[2]: * [linux/release_32/cesmagent] Error 1
I thought it had something to do with libssl0.9.8, but so I did "sudo apt-get install libssl0.9.8:i386" but there already was the newest version of it.
Can any one please help me here?
The linker is trying to link against the 64-bit version of libcrypto.a because it can't find a 32-bit version.
You say you have this:
$ locate libcrypto.a
/usr/lib/x86_64-linux-gnu/libcrypto.a
Whereas, you need this:
$ locate libcrypto.a
/usr/lib/i386-linux-gnu/libcrypto.a
(I thought you could have both, but it turns out, on 12.04, it's impossible to have both because the packages conflict.)
You can install the i386 library like this:
sudo apt-get install libssl-dev:i386
Basically, you probably had the run-time libraries installed correctly, but you did not have the developer libraries.
The workaround which solved my problem:
I installed 32-bit version library
sudo apt-get install libssl-dev:i386
the 64-bit library was removed by that.
in the directory /usr/lib/i386-linux-gnu I found 32-bit version libcrypto.a and put it in /usr/lib32
Then I installed 64-bit library
sudo apt-get install libssl-dev
in the directory /usr/lib/x86_64-linux-gnu I found 64-bit version libcrypto.a and put it in /usr/lib64
in the Makefile of a project I adjusted paths /usr/lib32/libcrypto.a and /usr/lib64/libcrypto.a to be dependent on the corresponding command argument.
the project builds!