I found the cdeconvert app, got a clean build and then the error about not passing the file path. Sorry for the lame question, but I have never built/run an OS X app from XCode directly. Question is: how do I execute (either from XCode or OS X directly) cdeconvert passing the cdeevent file path?
cdeconvert is a command line tool. Once it is built, you can locate the executable file (in Products), and use it via the command line. There is no app.
Related
I'm transitioning to Mac OS (from Win and Linux) and today I got strange messages while trying to debug some code:
Unable to start LLDB "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb": chdir: No such file or directory.
The LLDB process failed to start. Either the invoked program "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb" is missing, or you may have insufficient permissions to invoke the program.
What's going on?
I had the same problem when I set my working directory to a folder that didn't exist. Changing my working directory to an existing path fixed the issue.
I am trying to install openFoam on Mac OS X 10.10.5 (http://www.openfoam.com/download/install-binary.php) by using Docker-toolbox.
I can do without problems all the suggested steps, but then, when I try to run the example included in the installation guide, I cannot open paraFoam, since it returns the following error:
paraview: cannot connect to X server
I have also installed XQuartz but it doesn't seem to help much!
Why don't you get the latest paraview from Kitware. It has a native OpenFOAM reader built-in, which I always use. The only thing you have to do, instead of calling
paraFoam
is to create an empty file with a foam extension. Like so:
touch foo.foam
Then you can run start paraview like any other mac application, browse to to the respective case-directory and "open" the empty foo.foam file:
paraview foo.foam
If you would like to use a command similar to paraFoam or paraview in the command line, then use your command line to change into the Paraview.app and find paraview, which is the actual executable. Create a symbolic link pointing to that executable. I do the same, since I like to use the latest paraview instead of the one provided with OpenFOAM.
I've been using the vim-latex suite on my mac (10.7.?) for months with no problem. Over the weekend, I upgraded the OS to 10.8.2, and now my tex files fail to compile. The compile command
\ll
produces no errors within vim, but no pdf-file gets produced. If I drop to the command line in a terminal, the following command
latex document.tex
produces
-bash: latex: command not found
Similarly, for pdflatex. I'm not sure if this is a path error, or if latex for 10.8.2 needs to be reinstalled. I'm not sure how to proceed in either case.
I had the same problem and typing:
export PATH=/usr/texbin:$PATH
seems to work fine in a shell. Although it no longer works if I open a new shell, this is a faster solution to re-downloading and re-installing the huge MacTeX program.
This happened to me after upgrading to OS X El Capitan. I found the latex executables in /usr/local/texlive/2014/bin/x86_64-darwin. So, I just added this to my .bashrc
export PATH="$PATH:/usr/local/texlive/2014/bin/x86_64-darwin"
No need to reinstall.
On OS X, the standard way for third party installers to add a directory to the path is to put a file under /etc/paths.d. TeXLive does this as part of the installation, but the OS upgrade probably blew it away.
You should be able to just create a new file under that directory containing just one line, the path the directory containing the TeX executables.
When setting the path via #petew's answer, /usr/local/texlive/2014/bin/x86_64-darwin may not be the correct version. On my system /usr/local/texlive/2021/bin/universal-darwin was what was needed. Make sure to check your texlive binaries to see what file you downloaded.
I am trying to run our App on Mac Lion. App is built on Snow Leopard 10.6.8, packaged using package maker. We are linking dynamically to libCurl(3rd party lib). On snow leopard it works. On Lion when I install and click the app icon it fails in call to curl_easy_perform (from libCurl). But when I right click the app icon, click show package contents, and goto /Applications/MyDir/OurApp.app/Contents/MacOS/OurApp and then try to run that unix executable, then it works. I used otool to check the lib paths and they all seem correct.
Can someone help me why it fails when I click the .app? I thought .app is a soft link to the main executable. so if the executable works, then .app should also work.
Do I have to tell the path of the lib in .app? if so, how?
The dynamic linker "dyld" and related programs such as "otool" are influenced by environment variables. Environment variables can vary by process: the Finder has a unique copy of environment variable settings, and so does each shell in a terminal window.
As you can see if you run "man dyld", there are many variables that can influence the behavior of these programs.
If you're seeing different behavior from the command line than in the Finder, I imagine that at least one of the special linker variables has been set in your terminal. It is probably instructing the linker to look in places for libraries that are different from the linker's defaults (or whatever the Finder uses).
You can run "env | sort" from your terminal to see what's been set.
The make command is missing on my mac, running OS X version 10.6 (Snow Leopard). What should I do to install make?
You'll need to install the OS X developer tools from the Mac OS X installation discs.
EDIT: Directions here.
You need to install XCode, which comes along with make. You can download the latest XCode for free (if you're on Lion or Mountain Lion) from the Mac App store.
Update
It seems the link in the selected answer is a better solution, in that you don't have to add it to your path, it installs it in /usr/bin. I was originally thrown off by this as the answer mentions installation disks, which do not exist anymore (and are not needed here).
Original Post
make went missing on my installation of OSX Lion, even with XCode installed.
What I discovered was that, it was not in /usr/bin, but was in /Developer/usr/bin, which is not in $PATH environment variable by default. This is most likely a result of the XCode install.
You have a few options:
install it to one of the directories that is in your path
make a symbolic link to point to the Developer bin directory (for example, from /usr/bin)
modify your path to include the Developer directory (what I did) - see below
Add the developer bin to your path:
Somewhere in ~/.bashrc place the following code:
export PATH=$PATH:/Developer/usr/bin
#Remove Duplicates:
PATH=`perl -e '#A=split(/:/,$ENV{PATH});%H=map {$A[$#A-$_]=>$#A-$_} (0..$#A);#A=join(":",sort{$H{$a} <=> $H{$b} }keys %H);print "#A"'`
export PATH
Line 1: add /Developer/usr/bin to the end of the current path so it has low priority
Line 3: because we're adjusting path, we want to remove duplicates (in case you source more than once). Duplicates aren't really problematic, but this should cause the same directory to not be searched more than once, which may make it faster.
Line 4: Make it available to your environment
Note:
If you're using a different shell (for instance csh), you'll have to adjust the script above and make the changes in that corresponding resource file (~/.cshrc).
To apply changes you'll have to source ~/.bashrc or reopen your terminal.