I am using pkg-config 0.26 on OS X Lion.
When I echo $PKG_CONFIG_PATH, it seems that the variable is blank.
When I assign into it, e.g. PKG_CONFIG_PATH=/path/to/my/folder/containing/pc/files, and then run pkg-config --list-all, the .pc files in the directory that I ostensibly just added are not found.
I have been side-stepping this issue by soft linking to individual .pc files from /opt/local/share/pkgconfig, but I would prefer to figure out what the right way is.
Aha! This works:
export PKG_CONFIG_PATH=/path/to/my/folder/containing/pc/files
This makes total sense, it's just that I wrote the question before I knew the meaning of the command export.
Quoting from Defining a variable with or without export :
export makes the variable available to subprocesses
And pkgconfig is a subprocess of the shell when it is run.
Related
I'm trying to add a directory to the pkg-config search paths, but I cannot figure out how to do it on mac. According to all the discussion I can find online, it looks like it should be according to the environment variable PKG_CONFIG_PATH, that variable doesn't seem to exist.
For example:
$ echo $PKG_CONFIG_PATH
gives a blank response.
Also, I have tried doing this:
$ export PKG_CONFIG_PATH=/my/path:$PKG_CONFIG_PATH
And it does not change the results of $ pkg-config --variable pc_path pkg-config.
How are the pkg-config search paths handled on macOS?
It turns out PKG_CONFIG_PATH is the correct path. It just does not echo to the console for some reason.
I am guessing that somehow PredictionIO didn't setup the path variables properly.
I used method 2 to install PredictionIO from this link here: PredictionIO
Everything installed correctly but when I typed in pio it says command not found. This is what I see:
When I try to start pio from finder I get this:
Kind of lost, what am I doing wrong here?
The solution is to edit your PATH environment variable. You can do it directly in the shell:
$ export PATH=/Users/yourname/PredictionIO/bin:$PATH
However it will be set only as long as the session lasts. To make it permanent, you have to edit your bash profile file. I don't know how it is called on MacOS. On my Ubuntu, it is the .profile file. It is usually .profile, or .bash_profile or something like that.
$PATH is probably set in this file, so find where and edit.
My .profile file has a part in it that reads:
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:/opt/java/jdk1.8.0_45/bin:$PATH"
fi
I would change it to (even though it looks weird because it mixes your MacOS path and my Ubuntu ones):
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:/opt/java/jdk1.8.0_45/bin:/Users/yourname/PredictionIO/bin:$PATH"
fi
To get this working I simply did the following, this is for Mac Yosemite users.
$ PATH=$PATH:/Users/yourname/PredictionIO/bin; export PATH
Assuming you installed PredictionIO in that specific directory
Sidenote: I really don't like that there is so much cynicism to beginner's / semi-beginner's in certain areas it really makes me question StackOverFlow.
pio uses its own python version, using your system's python can cause problems, you can define an alias in .zshrc file
alias pio='~/.platformio/penv/bin/python3 ~/.platformio/penv/bin/pio'
I have been putting together a makefile in a Windows environment for my team to use. I decided to use MinGW's version of make for Windows. I put that executable with its dependencies into a repository location that should be in everyone's PATH variable. The executable was renamed "make.exe" for simplicity.
Then I realized that I have to account for the case when someone has cygwin's bin folder in their path. Commands like echo, rmdir, and mkdir will call echo.exe, rmdir.exe, and mkdir.exe from cygwin's bin folder. This means that I need to appropriately catch this scenario and use different flags for each command.
I see three cases here:
Cygwin's bin path comes before the path where make.exe is located in the repository. When a team member executes make.exe, they will be executing cygwin's make. Unix-style commands must be used.
Cygwin's bin path comes after the path where make.exe is located in the repository. The correct make.exe will be executed, but I still have to use Unix-style commands.
Cygwin is not installed or not in the PATH. I can use all Windows commands in this case.
I am fine with treating cases 1 and 2 the same. Since MinGW's make and cygwin's make are both based on GNU Make, then I don't see this being much of an issue other than incompatibility issues between versions of GNU Make. Let's just assume that isn't a problem for now.
I have come up with the following check in my makefile.
ifneq (,$(findstring cygdrive,$(PATH))$(findstring cygwin,$(PATH))$(findstring Cygwin,$(PATH)))
#Use Unix style command variables
else
#Use Windows style command variables
endif
Finding "cygdrive" in the path variable means that we are most likely in case 1. Finding "cygwin" or "Cygwin" in the path variable most likely means that we are in case 2. Not finding either string in the path most likely means that we are in case 3.
I am not completely fond of this solution because the cygwin's folder can be renamed or the string "cygwin" or "cygdrive" can be put in the PATH variable without having cygwin installed. One team member is still having issues as he has cygwin's bin path in the PATH variable, but the above does not catch that. I am assuming that he renamed the folder to something else, but I haven't been able to check on that.
So is there a better way to figure out what syntax that I should be using?
Here is another solution that I thought up.
ifeq (a,$(shell echo "a"))
#Use Unix style command variables
else
#Use Windows style command variables
endif
This is based on the fact that 'echo "a"' in Unix will print a (without quotes) but windows will print "a" (with the quotes). If I am using the Unix style echo then I can assume that I am using all Unix commands.
I don't find this solution very elegant though, so I am not marking it as the solution for this question. I think this is better than what I originally had though.
Cygwin make v. MinGW make: Does mingw make support the jobserver, as in can you do make -j5? If not, ${.FEATURES} has jobserver for cygwin make. Maybe load is a good test too.
Cygwin before non-cygwin on path: cygpath.exe is unique to cygwin. You could just look for this in ${PATH}. Unfortunately, Windows users like using spaces in folder names, and there's no way of dealing with this in pure make. $(shell which make) will return /usr/bin/make for cygwin, though a shell invocation on every make run is very smelly.
You don't install a compiler from a repository, is not make a similar case? Just get your users to install cygwin and be done with it.
When I want to run make to generate some executables it always uses the Sun make located
at /usr/local/bin/make rather than GNU make which can be found at /usr/sfw/bin/gmake.
How can I tell the OS to use GNU make rather than Sun's? Do I need to overwrite the path somehow?
For two executables named identically, reorder paths in the PATH variable, since the first match will be used.
Otherwise, define an alias in your ~/.profile or ~/.bashrc file:
alias make="/usr/sfw/bin/gmake"
Or a function:
make() { /usr/sfw/bin/gmake "$#"; }
Note, that aliases work only in interactive mode. Scripts will not see them. Use functions in such case.
you can link /usr/sfw/bin/gmake to /usr/bin for example as long as the directory where you link it to is before /usr/local/bin in the PATH variable
thus
cd /usr/bin
ln -s /usr/sfw/bin/gmake make
just be sure there is no make already in the path.
otherwise you always can call gmake instead of make to use gnu-make and leave make for the sun-version-make.
otherwise you can use the alias as in the previous post
If you're manually running the make command, then simply type gmake instead of make. It will run the GNU version (assuming that your PATH) variable is set properly.
If there's an IDE or some other tool that's invoking make, you need to tell it to use gmake rather than make and the way to do that depends on which tool you're using.
The systems I work with have GCC 4.5 (experimental) in /usr/local/bin/gcc which has proven to be problematic for some R packages. I would like to instead use system GCC in /usr/bin/gcc.
I have tried setting CC and CXX in the Bash configuration files (.bashrc, .bash_profile etc.) as well as on the command line, but although Bash recognizes the change, R does not.
How can I get R to use the version of GCC in /usr/bin instead of the one in /usr/local/bin/?
This is not that well documented (e.g. I failed to locate it in either 'R Extension' or 'R Admin' right now) but Brian Ripley mentioned it a few times on the lists.
Basically, at R compile time, settings are registered and the stored in $R_HOME/etc/Makeconf. One possibility is to edit that file directly, but you may not have root privileges or may not want to affect all other users. So the better may be to create
~/.R/Makevars
with entries
CC=gcc-4.4
CXX=g++-4.4
plus whichever optmisation flags etc you want to set. That will the affect all subsequent uses of R CMD INSTALL or R CMD check or ... that you run.
Other files in $R_HOME/etc/ can similarly be overridden locally from ~/.R/.
I had a very similar problem.
What worked for me was to define a project directory (rstudio can do that for you), and then add a .Renviron file that modifies the PATH and LD_LIBRARY_PATH, to include the directory with the new gcc.
In your case, for example, the .Renviron will look something like:
LD_LIBRARY_PATH=/usr/local/bin/gcc/lib:/usr/local/bin/gcc/lib64:/usr/local/bin/gcc/libexec:other paths
PATH=/usr/local/bin/gcc/bin:/usr/local/bin:other paths
Check your path to see if /usr/local/bin comes before /usr/bin. If it does, just make sure /usr/bin comes first:
PATH=/usr/bin:${PATH}
(it's okay if /usr/bin is duplicated appears twice).
Look at configure.args part of ?install.packages and compare this to ./configure --help on e.g. the r source tree.
You can also, from bash, CC=clang R CMD INSTALL /path/to/package/source.
HTH