I am trying to install gaia, image software for astronomy. I am running Snow Leopard 10.6.8 and have xcode tools 3.2.6 with developer tools installed. I also believe I have the correct gfortran compiler necessary.
How do I install gaia now? What are the commands I need to run. When I download it, it unzips and there are just a bunch of folders.
Any help is greatly appreciated.
Thanks,
Max
Steps for installing Starlink Gaia
Download the latest Starlink distribution (Hikianalia, as of this writing):
http://starlink.jach.hawaii.edu/starlink/HikianaliaDownload
Uncompress the .tar.gz. A new star directory will be created. You can move it some other place (for instance, /Users/Shared/star, or /star)
As the installer is 0.7GB, you might want to delete it after installation has been successful.
Depending on your default shell:
For C (csh, tcsh) shells:
Create a STARLINK_DIR environment variable pointing to where the star directory is to be left (i.e., /Users/Shared/star):
setenv STARLINK_DIR /Users/Shared/star
Source the chsrc files
source $STARLINK_DIR/etc/login
source $STARLINK_DIR/etc/cshrc
You can combine the steps above creating an alias called start_starlink to add to your .cshrc file, so that you only start the Starlink libraries when needed:
alias start_starlink 'setenv STARLINK_DIR /Users/Shared/star; source $STARLINK_DIR/etc/login; source $STARLINK_DIR/etc/cshrc'
For Bourne (sh, bash, zsh) shells:
Create a STARLINK_DIR environment variable pointing to where the star directory is to be left (i.e., /Users/Shared/star):
export STARLINK_DIR=/Users/Shared/star
Source the chsrc files
. $STARLINK_DIR/etc/profile
You can combine the steps above creating an alias called start_starlink to add to your .cshrc file, so that you only start the Starlink libraries when needed:
alias start_starlink='export STARLINK_DIR=/Users/Shared/star; . $STARLINK_DIR/etc/profile'
So, after typing start_starlink, you can just type gaia to launch Starlink Gaia.
Fixing a missing gfortran
In x86_64 systems, if launching gaia fails with the message:
dyld: Library not loaded: /usr/local/lib/libgfortran.3.dylib
Referenced from: /Users/jdsant/Downloads/star/bin/gaia/gaia_wish
Reason: image not found
you need to make sure that you have gfortran libraries installed, and that they are were gaia expects them.
You can try to use locate libgfortran.3.dylib, and copy it to /usr/local/lib , or make a symlink to it. See, for instance, http://starlink.jach.hawaii.edu/starlink/HikianaliaDownload#SnowLeopard64-bitdistribution
I had this
dyld: Library not loaded: /usr/local/lib/libgfortran.3.dylib
Referenced from: /Users/jdsant/Downloads/star/bin/gaia/gaia_wish
Reason: image not found
problem and was becoming very frustrated until I figured out that per the instructions on the GFortran website, that you must unzip the gcc file in the terminal, not using your browser. So, after downloading gcc-5.0-bin.tar.gz, I executed:
$ gunzip gcc-5.0-bin.tar.gz
$ sudo tar -xvf gcc-5.0-bin.tar -C /
this unpacked the file, but then received a very long error stating "Application initialization failed: no display name and no $DISPLAY environment variable" and "gaia was not properly installed". I then executed:
$ startx
which started X11, and then opened xterm. I then restated in xterm:
$ export STARLINK_DIR=/Users/kristen/Downloads/star-2014A
$ source $STARLINK_DIR/etc/profile
$ gaia &
and another GUI for GAIA Starlink popped up and it all worked
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 am attempting to install and run gfortran-8 on macOS with the following makefile. I installed it from http://hpc.sourceforge.net/ (8.3 version). I keep getting this error:
gfortran: error: libgfortran.spec: No such file or directory
I know libhfortran.spec is located in /usr/local/Cellar/gcc#8/8.4.0/lib/gcc/8/libgfortran.spec. I have added it to my etc/paths and my .bash_profile. I have also uninstalled gfortran and reinstalled it. Anyone have a clue on what I might be missing? I am attaching my makefile below.
Makefile:
https://drive.google.com/open?id=1Y_Zo2dSYI32dQpwMtdUy5rWB8avDHXor
Bellhop Macintosh Installation
Note: I know gfortran is now part of gcc but newest at version still only works with older gfotran compilers. If you have Catalina as well, don’t worry this will still work on Mojave as well as on Catalina. I had tested it.
Go to this link.
Download
Install the downloaded gfortran-8.2-Mojave.dmg, this compiler is being used by the at to create binaries for your MacOS.
Go to the path where you extracted at folder. (In Mac you don’t need windows binary, you need to compile using gfotran compiler.)
Execute the following commands in the at folder.
Once you installed. Close all the terminals.
Open new terminal. Do as follows:
In your terminal, type this:
echo $PATH
Above command give you current path in your zsh file, If you have one.
Add bellhop to your zsh file. You can use these commands in terminal:
cd
nano .zsh
Please note that there is no Bellhop in the path right now, so we are going to add that by adding the following line in the .zsh file, Copy and paste below list (change the path accordingly)
export PATH=your_local_macOS_path/at:your_local_macOS_path/at/Bellhop:$PATH$
For me, it was:
export PATH=/Users/jaypatel/Downloads/at:/Users/jaypatel/Downloads/at/Bellhop:$PATH$
Refer the screenshot below for more details.
Once you’re done, press ctrl+X and it will ask you do you want to save your file, type Y and press enter and it will save the path successfully.
And now source ~/.zsh to your terminal using this command :
source ~/.zsh
echo $PATH
This means your acoustic toolbox and bellhop.exe are in path’s now.
And now source ~/.zsh to your terminal using this command : source ~/.zsh
And Voila, Your Bellhop is successfully installed.
Reference :
You can find more details here.
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
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
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.