Related
Program is part of the Xenomai test suite, cross-compiled from Linux PC into Linux+Xenomai ARM toolchain.
# echo $LD_LIBRARY_PATH
/lib
# ls /lib
ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so
ld-linux.so.2 libdl.so.2 libpthread.so.0
libc-2.3.3.so libgcc_s.so libpthread_rt.so
libc.so.6 libgcc_s.so.1 libstdc++.so.6
libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9
libcrypt.so.1 libm.so.6
# ./clocktest
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory
Is the .1 at the end part of the filename? What does that mean anyway?
Your library is a dynamic library.
You need to tell the operating system where it can locate it at runtime.
To do so,
we will need to do those easy steps:
Find where the library is placed if you don't know it.
sudo find / -name the_name_of_the_file.so
Check for the existence of the dynamic library path environment variable(LD_LIBRARY_PATH)
echo $LD_LIBRARY_PATH
If there is nothing to be displayed, add a default path value (or not if you wish to)
LD_LIBRARY_PATH=/usr/local/lib
We add the desired path, export it and try the application.
Note that the path should be the directory where the path.so.something is. So if path.so.something is in /my_library/path.so.something, it should be:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
export LD_LIBRARY_PATH
./my_app
Reference to source
Here are a few solutions you can try:
ldconfig
As AbiusX pointed out: If you have just now installed the library, you may simply need to run ldconfig.
sudo ldconfig
ldconfig creates the necessary links and cache to the most recent
shared libraries found in the directories specified on the command
line, in the file /etc/ld.so.conf, and in the trusted directories
(/lib and /usr/lib).
Usually your package manager will take care of this when you install a new library, but not always, and it won't hurt to run ldconfig even if that is not your issue.
Dev package or wrong version
If that doesn't work, I would also check out Paul's suggestion and look for a "-dev" version of the library. Many libraries are split into dev and non-dev packages. You can use this command to look for it:
apt-cache search <libraryname>
This can also help if you simply have the wrong version of the library installed. Some libraries are published in different versions simultaneously, for example, Python.
Library location
If you are sure that the right package is installed, and ldconfig didn't find it, it may just be in a nonstandard directory. By default, ldconfig looks in /lib, /usr/lib, and directories listed in /etc/ld.so.conf and $LD_LIBRARY_PATH. If your library is somewhere else, you can either add the directory on its own line in /etc/ld.so.conf, append the library's path to $LD_LIBRARY_PATH, or move the library into /usr/lib. Then run ldconfig.
To find out where the library is, try this:
sudo find / -iname *libraryname*.so*
(Replace libraryname with the name of your library)
If you go the $LD_LIBRARY_PATH route, you'll want to put that into your ~/.bashrc file so it will run every time you log in:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
Update
While what I write below is true as a general answer about shared libraries, I think the most frequent cause of these sorts of message is because you've installed a package, but not installed the -dev version of that package.
Well, it's not lying - there is no libpthread_rt.so.1 in that listing. You probably need to re-configure and re-build it so that it depends on the library you have, or install whatever provides libpthread_rt.so.1.
Generally, the numbers after the .so are version numbers, and you'll often find that they are symlinks to each other, so if you have version 1.1 of libfoo.so, you'll have a real file libfoo.so.1.0, and symlinks foo.so and foo.so.1 pointing to the libfoo.so.1.0. And if you install version 1.1 without removing the other one, you'll have a libfoo.so.1.1, and libfoo.so.1 and libfoo.so will now point to the new one, but any code that requires that exact version can use the libfoo.so.1.0 file. Code that just relies on the version 1 API, but doesn't care if it's 1.0 or 1.1 will specify libfoo.so.1. As orip pointed out in the comments, this is explained well at here.
In your case, you might get away with symlinking libpthread_rt.so.1 to libpthread_rt.so. No guarantees that it won't break your code and eat your TV dinners, though.
You need to ensure that you specify the library path during
linking when you compile your .c file:
gcc -I/usr/local/include xxx.c -o xxx -L/usr/local/lib -Wl,-R/usr/local/lib
The -Wl,-R part tells the resulting binary to also look for the library
in /usr/local/lib at runtime before trying to use the one in /usr/lib/.
Try adding LD_LIBRARY_PATH, which indicates search paths, to your ~/.bashrc file
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library
It works!
The linux.org reference page explains the mechanics, but doesn't explain any of the motivation behind it :-(
For that, see Sun Linker and Libraries Guide
In addition, note that "external versioning" is largely obsolete on Linux, because symbol versioning (a GNU extension) allows you to have multiple incompatible versions of the same function to be present in a single library. This extension allowed glibc to have the same external version: libc.so.6 for the last 10 years.
cd /home/<user_name>/
sudo vi .bash_profile
add these lines at the end
LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH
Another possible solution depending on your situation.
If you know that libpthread_rt.so.1 is the same as libpthread_rt.so then you can create a symlink by:
ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1
Then ls -l /lib should now show the symlink and what it points to.
I had a similar error and it didn't fix with giving LD_LIBRARY_PATH in ~/.bashrc .
What solved my issue is by adding .conf file and loading it.
Go to terminal an be in su.
gedit /etc/ld.so.conf.d/myapp.conf
Add your library path in this file and save.(eg: /usr/local/lib).
You must run the following command to activate path:
ldconfig
Verify Your New Library Path:
ldconfig -v | less
If this shows your library files, then you are good to go.
running:
sudo ldconfig
was enough to fix my issue.
I had this error when running my application with Eclipse CDT on Linux x86.
To fix this:
In Eclipse:
Run as -> Run configurations -> Environment
Set the path
LD_LIBRARY_PATH=/my_lib_directory_path
Wanted to add, if your libraries are in a non standard path, run ldconfig followed by the path.
For instance I had to run:
sudo ldconfig /opt/intel/oneapi/mkl/2021.2.0/lib/intel64
to make R compile against Intel MKL
All I had to do was run:
sudo apt-get install libfontconfig1
I was in the folder located at /usr/lib/x86_64-linux-gnu and it worked perfectly.
Try to install lib32z1:
sudo apt-get install lib32z1
If you are running your application on Microsoft Windows, the path to dynamic libraries (.dll) need to be defined in the PATH environment variable.
If you are running your application on UNIX, the path to your dynamic libraries (.so) need to be defined in the LD_LIBRARY_PATH environment variable.
The error occurs as the system cannot refer to the library file mentioned. Take the following steps:
Running locate libpthread_rt.so.1 will list the path of all the files with that name. Let's suppose a path is /home/user/loc.
Copy the path and run cd home/USERNAME. Replace USERNAME with the name of the current active user with which you want to run the file.
Run vi .bash_profile and at the end of the LD_LIBRARY_PATH parameter, just before ., add the line /lib://home/usr/loc:.. Save the file.
Close terminal and restart the application. It should run.
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared
object file: No such file or directory
Try this. Fix permissions on files:
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
I use Ubuntu 18.04
Installing the corresponding -dev package worked for me,
sudo apt install libgconf2-dev
Before installing the above package, I was getting the below error:
turtl: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared object
file: No such file or directory
Try this. Fix permissions on files:
sudo su
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
chown -R root:root *
A similar problem can be found here.
I've tried the mentioned solution and it actually works.
The solutions in the previous questions may work. But the following is an easy way to fix it.
It works by reinstalling the package libwbclient
in fedora:
dnf reinstall libwbclient
You can read about libraries here:
https://domiyanyue.medium.com/c-development-tutorial-4-static-and-dynamic-libraries-7b537656163e
I have installed GO, setup the paths but when i run a file i get this error:
error!! exec: "sqlboiler": executable file not found in $PATH
exec: "sqlboiler": executable file not found in $PATH
exec: "sqlboiler": executable file not found in $PATH
exit status 3
What is going wrong?
The installation instructions are good, https://go.dev/doc/install. However, for me un Ubuntu 20.4 in wsl2, the suggested path for the binaries wasn't enough. Only go and gofmt are added to /usr/local/go/bin.
I did add the below to my .bashrc, since go install puts the binaries in this location on my system.
export PATH="$HOME/go/bin:$PATH"
Note, that the path to the binaries may differ on your system, so you have to adjust it accordingly.
Any binary you install with go install that is added to this path will be available to your shell afterwards.
For example:
$ go install github.com/volatiletech/sqlboiler/v4#latest
$ go install github.com/volatiletech/sqlboiler/v4/drivers/sqlboiler-psql#latest
$ whereis sqlboiler
sqlboiler: /home/blue/go/bin/sqlboiler
Potentially, you also need some database packages to your system. I am not sure on this any more. For example, you could add some Postgres libs if you are using Postgres. You have to see if it works without.
apt-get install postgresql-client-common postgresql-client-12
How to properly install GO with paths and all?
Install Go with the installer (Windows) or archive (extract into /usr/local on Linux/Mac).
When installing from archive, manually add the directory path where the go binary is located (/usr/local/go) to PATH.
Set GOPATH to a directory path wherein to contain bin, pkg and src sub-directories.
Add ${GOPATH}/bin to PATH.
What is going wrong?
The program you are running is trying to run the executable sqlboiler, which cannot be found in any of the directories specified in PATH.
I am trying to use CLion on Windows and I installed my environment using cygwin but I'm getting this warning in the settings. Moreover, it's almost impossible to debug because the debugger just stops showing debugger info in the middle.
I had the very same problem. I wasn't able to make CLion work with gdb 7.10.x but I was able to make cygwin install gdb 7.8-1. My method should work to install any version you want.
The following steps describe the way I managed to do it, I'm a newbie using cygwin, so maybe some of them are unnecessary.
Create a cache directory for cygwin and place the cygwin setup.exe in it (in my case C:\cygwinCache). [Source]
Execute the setup.exe and follow the usual steps for installing from Internet. Select Install from Internet, select your cygwin root directory (in my case C:\cygwin64), create and select a directory inside your cygwin cache directory (in my case C:\cygwinCache\downloaded), select the connection option your Internet connection requires, then select any server with gdb available (I selected http://cygwin.mirror.constant.com) and click Next. This will download and parse a setup.ini file that contains the available packages in the server you selected. This setup.ini file will be located in your cache directory in a sub directory named after the server you selected (C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64).
From the link that #H. DJEMAI found (this one) download the gdb installation and source files of the version you want (I downloaded gdb-7.8-1.tar.xz and gdb-7.8-1-src.tar.xz). As a backup, I uploaded these files in here.
In the directory where the setup.ini file is located create the \release\gdb directory. In this newly created \release\gdb directory place both of the gdb files you downloaded in the last step. Now you have the gdb installation and source files in the following paths:
C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\gdb\gdb-7.8-1.tar.xz
C:\cygwinCache\downloaded\http%3a%2f%2fcygwin.mirror.constant.com%2f\x86_64\release\gdb\gdb-7.8-1-src.tar.xz
Open the setup.ini file, and look for a line with this string: # gdb. This section has the information of the gdb package and information about the files it may contain. It should look like this:
# gdb
sdesc: "The GNU Debugger"
ldesc: "The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data."
category: Devel
requires: cygwin libexpat1 libiconv2 libintl8 liblzma5 libncursesw10 libreadline7 python
version: 7.10.1-1
install: x86_64/release/gdb/gdb-7.10.1-1.tar.xz 2670932 cd1fa152888faa3e4cb8e1d075604fb2e039d73acdd159d7c9553741fd7710778c742495c93476b234e3386d54bd5bdc5275007290b6eb940d70197feb21b573
source: x86_64/release/gdb/gdb-7.10.1-1-src.tar.xz 18542336 758428a83148af8425cff2712ac15d842f449d824f0edc9bb8db1d1d84bf963e2f371372d0c645408c202914ffb088a9da32be5a9b62a637a71f2fe9b7d4614f
[prev]
version: 7.9.1-1
install: x86_64/release/gdb/gdb-7.9.1-1.tar.xz 2550148 f62f65865a11757b945f431a3662e16d0357dc9a0cbc720d16f5e99543cd3231f34bacd245daeb113ad38501358d9b1e7d128a1a45871d02c2bfb1c15891fbcb
source: x86_64/release/gdb/gdb-7.9.1-1-src.tar.xz 17888340 b90d198404a0a16268b443f4a4ec9672dac1d531f3fbda848f807fee7c004f5394e1985253c64ab0cdc2dcf7c088645c60edbf8e9f39dce0f149bce4b11f5085
Now edit the file to make cygwin install the version you want. To achieve this modify the lines where it says version, install and source with the information of the files you want to install. I modified the lines after the [prev] string replacing 7.8-1 instead of 7.9.1-1 so cygwin points to the correct location. Note that the lines that start with install: and source: contain the relative location of the files you previously downloaded and placed in the \release\gdb directory. After this relative location the setup.ini file contains the byte size and SHA-512 of the specified file. You can get the bite size for your file in the file properties. To get the SHA-512 you have to use other software like this one. In the case of the 7.8-1 files I got the following:
# gdb
sdesc: "The GNU Debugger"
ldesc: "The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data."
category: Devel
requires: cygwin libexpat1 libiconv2 libintl8 liblzma5 libncursesw10 libreadline7 python
version: 7.10.1-1
install: x86_64/release/gdb/gdb-7.10.1-1.tar.xz 2670932 cd1fa152888faa3e4cb8e1d075604fb2e039d73acdd159d7c9553741fd7710778c742495c93476b234e3386d54bd5bdc5275007290b6eb940d70197feb21b573
source: x86_64/release/gdb/gdb-7.10.1-1-src.tar.xz 18542336 758428a83148af8425cff2712ac15d842f449d824f0edc9bb8db1d1d84bf963e2f371372d0c645408c202914ffb088a9da32be5a9b62a637a71f2fe9b7d4614f
[prev]
version: 7.8-1
install: x86_64/release/gdb/gdb-7.8-1.tar.xz 2491984 4c8d81984fe2ccbf92614c857737a42c4ec0c4016a5f8cf1dbc0fd117a1978baa7a8eadd2415a6d52041a1eecbe6b4e1373ba6850db6584869311a5e02a6e3b2
source: x86_64/release/gdb/gdb-7.8-1-src.tar.xz 17669132 a71b6886774cb004baa7dc88ed767983a72fc94c7585bd79ff64c2bd2071c411cf0de76584c56aa3553d9541172eaf31f1dd142a6dedec50c5446ff2986c6d48
Don't forget to save the setup.ini file after you modified it.
Open the cygwin setup inside the cache directory. Now instead of selecting the install from Internet option select Install from Local Directory, then set your root directory and as local package directory select your cache directory (C:\cygwinCache\downloaded). It will parse the setup.ini file, and if you edited it successfully, it will show you the grid to install, upgrade or uninstall packages. If the parsing fails an error will be shown.
Look for the gdb package under Devel category, it should appear installed with a current version:
Click it where it says Keep until you see the version you want. Then click next, this will start the installation, when the process is done, click finish.
You're done. You can open the cygwin terminal and type gdb --version and see that the correct version is installed:
After all these steps, now you can open clion and go to Settings > Toolchains and see the result:
PS. I achieved this with cygwin setup version 2.873 (64 bits).
While LuissRicardo's answer seems like it will work, I stumbled upon a solution online that is a lot more straightforward. See: http://kennyroh.blogspot.co.uk/2016/04/cygwin-clion-gdb-current-version-is-gnu.html
Download gdb-7.8-2.tar.xz from http://cygwin.mirror.constant.com/x86_64/release/gdb/ and put it somewhere in your Cygwin filesystem.
Open a Cygwin terminal at that location, and run: tar Jxvf gdb-7.8-2.tar.xz. The instructions use zxvf, but that won't work for .xz archives.
cd into the folder you just extracted (for me this was just cd usr).
Run the command cp -R * /usr/ to copy this to the correct location in the filesystem.
Run gdb --version just to make sure it's set to 7.8.2. If it's not then maybe try restarting Cygwin, and if that doesn't work then maybe post on StackOverflow or something :p
I am trying to include ZMQ sockets in a Go app but both zmq4 and gozmq (the referred ZMQ binding libraries for Go) are giving me problems. I would like to understand why zmq4 specifically isn't importable on my system.
I am running a Windows 8 system and I used the windows installer from the ZMQ website for version 4.0.3. I am primarily concerned about getting zmq4 set up and here is the result of my "go get" query on the github library's location:
> go get github.com/pebbe/zmq4
# github.com/pebbe/zmq4
polling.go:4:17: fatal error: zmq.h: No such file or directory
compilation terminated.
This issue is not alleviated by cloning the Github repository - the error remains the same.
I know the issue has to do with the C library zmq.h that is located in the "include" folder of my ZMQ installation, but whether the dependency is held up by a pathing issue or an external tool issue is a mystery to me.
A similar error has come up in regards to node.js and is the solution I see others referred to, outside of node scripting, but it was unsuccessful in my case.
I've so far included the path to the "include" folder in my PATH environment variable and previously placed zmq.h inside of the zmq4 top-level folder. I don't have much of an arsenal otherwise to understand this problem because I am new to C and C-importing packages in Go
I wanted to do the same thing, but on Windows 7, and here is what I had to do.
Since the Go bindings are using cgo to integrate with zeromq, you need zeromq built with gcc. There are no pre-built binaries, so you'll have to build them yourself, with mingw or similar, but this process is easier than it may sound, and nicely described on the zeromq site.
As #photoionized pointed out, C_INCLUDE_PATH and LIBRARY_PATH need to be set when building the Go bindings.
(In my case, I ran into a problem when compiling libzmq with IN6_ADDR not being defined. The only solution I found was, inspired by this issue, to manually add the line #include <in6addr.h> to the windows.hpp file.)
The Windows installer version of ZeroMQ won't work with zmq4, you need to compile from source with gcc, I recommend using MSYS2.
Install and update MSYS2 following the instructions from
http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
Start the mingw32_shell.bat or mingw64_shell.bat based on Go arch (32bit or 64bit)
pacman -S mingw-w64-(x86_64|i686)-toolchain make (x86_64 for 64bit, i686 for 32bit)
cd into zeromq src folder (C:\ path starts with /c/ inside the shell)
./configure
make
make install
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
Copy the following dlls and put them next to your go program (.exe):
/usr/local/bin/libzmq.dll
/mingw(32|64)/bin/libgcc*.dll
/mingw(32|64)/bin/libwinpthread*.dll
/mingw(32|64)/bin/libstdc++*.dll
Here's updated steps for #user2172816's MSYS2 solution:
Install and update MSYS2 following the instructions from http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
Start the mingw32_shell.bat or mingw64_shell.bat based on Go arch (32bit or 64bit)
pacman -S mingw-w64-(x86_64|i686)-toolchain make (x86_64 for 64bit, i686 for 32bit)
Add C:\msys64\mingw64\bin to your Path (pkg-config is there)
Restart the msys2 shell to get the new Path
Download and unzip libsodium source: https://github.com/jedisct1/libsodium/releases
cd into libsodium folder (C:\ path starts with /c/ inside the shell)
./configure --build=(x86_64|i686)-w64-mingw32
make
make install
Add /usr/local/lib to PKG_CONFIG_PATH (export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig)
cd into zeromq src folder
./configure --build=(x86_64|i686)-w64-mingw32
Add
#ifdef ZMQ_HAVE_MINGW32
#include <winsock2.h>
#include <windows.h>
#include "netioapi.h"
#endif
To the top of src/tcpaddress.cpp
make
make install
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go build in your project directory
Copy the following dlls and put them next to your go program (.exe):
/usr/local/bin/libzmq.dll
/mingw(32|64)/bin/libgcc*.dll
/mingw(32|64)/bin/libwinpthread-*.dll
/mingw(32|64)/bin/libstdc++*.dll
/usr/local/bin/libsodium-*.dll
maybe? /usr/local/bin/libsodium-*.def
An updated answer using MSYS2.
Install MSYS2 MSYS2 installation guide.
Make sure to choose the correct installation 32bit or 64bit.
Open the appropriate shell MSYS2 MinGW 64-bit or MSYS2 MinGW 32-bit. All further steps assume you are using this shell.
Update packages following instructions at the installation guide.
Install libtool pacman -Sy libtool.
Download zmq source code to a location of your choice.
Navigate to the zmq source folder.
To generate the configure file, run the autogen tool by running ./autogen.sh.
In the probable case that step 8 fails:
Find the file at fault (probably version.sh).
Replace line endings by (replace file by the actual filename).
cp file file.bak
tr -d '\r' <file.bak> file
If this fails you'll have to dive in the code and find the problem.
Run the configure tool ./configure.
In the probable case of failure. Comment out empty else clauses in the configure file.
Add Go to Path: PATH=${PATH}:<go bin directory>.
Install Go Package: CGO_CFLAGS=-I/usr/local/include CGO_LDFLAGS=-L/usr/local/lib go get github.com/pebbe/zmq4
To install ZMQ in windows: Problem in Installing Golang ZMQ for windows - fatal error: czmq.h: No such file or directory
First of all, install the msys64. Download the software from https://www.msys2.org/ and install it on C:\msys64.
Then add C:\msys64\mingw64\bin to PATH environment variable of the windows.
Then run the following commands (in CMD) one by one.
pacman -Su
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
pacman -S base-devel gcc vim cmake
pacman -S mingw-w64-x86_64-libsodium
pacman -S mingw-w64-x86_64-zeromq
Finally, run the Go install command:
go get github.com/pebbe/zmq4
Finished.
When using homebrew to install graphviz, the script gets to the point of "Making install in tkstubs" and then throws the following fatal error:
In file included from tkStubLib.c:15:
/usr/include/tk.h:78:11: fatal error: 'X11/Xlib.h' file not found
#include <X11/Xlib.h>
I have installed XQuartz as X11 has been dropped in Mountain Lion, but I'm unsure if it is installed correctly. The location of Xlib.h is:
/opt/X11/include/X11/Xlib.h
There are also two symlinks to /opt/X11, they are:
/usr/X11
/usr/X11R6
Does this look like the correct setup to you? I've never dealt with X11 or XQuartz until yesterday.
Cheers.
After installing XQuartz you may add a symlink to your X11 installation folder by just entering
ln -s /opt/X11/include/X11 /usr/local/include/X11
in terminal. That will fix the problem as well without changing any ruby script.
You need to tell the tkstubs build (and possibly other bits in the package as well) to look for headers in /opt/X11/include; this is not on the standard include path.
Usually this is achieved by passing -I/opt/X11/include as an additional compiler flag, the method to do so is however dependent on the build system.
For reasonably modern configure scripts, the best approach is to pass it in the environment variable CPPFLAGS; if the package uses another build system or this doesn't work for another reason, then you need to look at the Makefile in the build directory.
You can enter in your shell before the compile/link (or brew) command:
export CPPFLAGS=-I/opt/X11/include
The export line will tell the compile/linker to look in /opt/X11/include for the X11 include files
Had the same issue and running this command on terminal
xcode-select --install
worked for me. Run this command after installing xQuartz.
If you need this to work in your CMake builds:
if(APPLE)
include_directories(AFTER "/opt/X11/include")
endif()
That worked well for me.
I got it to install by copying the x11 header file directory to the /opt/local/include directory. Probably not the best way to work around it but quick and easy.
I found this thread while trying to compile ffmpeg from source on OS X. I needed --enable-x11grab and the homebrew build does not support this option.
I had XQuartz installed already but I kept getting errors from ./configure: ERROR: Xlib not found. I thought the answers here would solve my problem, but they did not!
So, if anyone is ever in the same boat, my solution was this:
I opened up the generated config.log and found lots of errors referring to various includes and header files, including X11/Xlib.h - this is misleading. At the very bottom of the logfile was the key, pkg-config was complaining about looking for xbc.pc, and requested that it be put on the path. However, the error message that is displayed on the terminal says nothing about pkg-config or xbc!
The solution is to add to your PKG_CONFIG_PATH environment variable. Mine was nonexistent, so I just did export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig/ (the folder where I found xbc.pc).
I reran configure and everything worked like a charm!
TL;DR: check config.log - don't trust the terminal output!
Since the make file is looking for X11/xlib.h i.e., it is looking for X11 folder in the current directory, one way to solve this problem is to simply copy the /opt/X11/include/X11 directory to the directory that contains make file.