I'm on Macos 10.14.5. I run Ghostscript via Macports, and recently upgraded to Ghostscript 9.27. Ever since I upgraded, most of what I use Ghostscript for (Imagemagick file conversions) doesn't work anymore. I made the silly mistake of deleting the old version of Ghostscript in Macports (yeah ...).
Essentially, Ghostscript crashes with an 'Abort trap: 6' error. Example? I try to convert a PDF to PNG. I get this:
[ghostscript library 9.27] -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pngalpha' -dTextAlphaBits=4 -dGraphicsAlphaBits=4 '-r600x600' '-sOutputFile=/var/folders/k0/m6mz3d055m75782ynnkt2k0w0000gn/T/magick-5910MkmWy1yIM0tx%d' '-f/var/folders/k0/m6mz3d055m75782ynnkt2k0w0000gn/T/magick-5910gs9cNcP8C7cU' '-f/var/folders/k0/m6mz3d055m75782ynnkt2k0w0000gn/T/magick-5910iJZ-CiPdfIWp'Abort trap: 6
I believe this has to to with '/usr/local/bin/gs-X11' being unable to find the correct directory for a dyld library. When I run gs-X11, I get this:
/usr/local/bin/gs-X11
dyld: Library not loaded: /opt/X11/lib/libXt.6.dylib
Referenced from: /usr/local/bin/gs-X11
Reason: image not found
Abort trap: 6
The 'libXt.6.dylib' library exists on my file system, but not in '/opt/X11/', but in '/opt/local/lib/'.
How do I get Ghostscript to use the correct directory?
Ghostscript doesn't build an executable called 'gs-X11', the executable should be called simply 'gs'.
It 'sounds like' you've picked up a pre-built binary from somewhere, which has been built to expect X-Windows support, and that support is supplied by a system shared library, and as you rightly say, not where you have it installed.
I don't think you can (easily) modify the binary to look elsewhere for the system library, but I'm not a Mac developer so I might be mistaken.
Given that you have the library already present you could try simply copying it to /opt/X11/lib.
Or you could try the source you got the binary from and look for a non-X-Windows version. (or ask them, presumably the Macports people hwo to fix the problem)
Or you could build Ghostscript yourself from source.
To build from source you'll need gcc and the autotools, you can pick up autoconf, automake and libtool from HomeBrew if you don't already have them. With that, get the source tarball from the www.ghostscript.com downloads page, untar it somewhere convenient and then, from that folder do "./autogen.sh" and then "make". That should build a version of Ghostscript compatible with your system.
To be honest, this isn't a Ghostscript question really, more of a Mac system question.
I am having a similar problem on a machine that had various versions of X11 installed (and uninstalled) through both MacPorts and XQuartz. I seem to have solved the problem by providing a symlink between the missing /opt/X11 and the existing /opt/local where the needed things exist:
sudo ln -s /opt/local /opt/X11
sudo ln -s /opt/local /opt/X11R6
Similar problems seem to sometimes occur when /usr/local/X11 and /usr/local/X11R6 are non-existing, but in my case the /usr/local/X11 already had a symlink to /opt/X11 (as does /usr/local/X11R6 )
Probably to really fix everything properly, I should completely uninstall MacPorts, and completely uninstall XQuartz, and remove all the symlinks, then restart the computer to make sure it is all clear. Then reinstall it all and hope that the installers get everything in the right places. Perhaps redoing my MacTeX LaTeX installation would also be wise.
Related
I have spent an evening until some ridiculous time in the morning trying to figure out how to get Haskell's GHC to work correctly and to have Cabal install the gloss library.
After reading through every bit of documentation/error reports imaginable, even with old installs of ghc, gcc binary (instead of a symlink to clang), and brewing llvm no matter what happened one fix resolved one issue, only to then present another.
So I have a simple solution that worked for me for Yosemite and I will post it below (I wish someone else had posted it here)
Ok here is the easy solution to the headache:
Go here http://ghcformacosx.github.io/ and download the app and put it in the app directory and run it.
Add the stuff to the .bash_profile (you will see what I mean when you run it)
Run brew install llvm34 (note there was an issue with using a newer version)
Then symlink to llvm so that ghc can find it (I tried editing the ghc settings file but it didn't help. Maybe after all the stuffing around, it was the wrong version of ghc that I was editing)
Brew gave me symlinks at /user/local/bin to llvm BUT NOTE they were not called plain old llc & opt as ghc was looking for.. they were called llc-3.4 & opt-3.4, hence why it couldn't find them. Again their location can be specified in the ghc settings file, but as I had some issues with that I just created some more symlinks.
I went to /usr/bin and ran:
sudo ln -s /usr/local/bin/opt-3.4 opt
sudo ln -s /usr/local/bin/llc-3.4 llc
Which created the generic opt, generic llc that symlinked to the brew installion of the associated v3.4.2 llvm files.
Hope that saves someone an evening.
I don't know whether this is actually an SDL issue or just me not knowing how to build packages from msys/mingw. What I have done thus far:
downloaded latest mingw-get-inst.exe from sourceforge and ran it. This installed a C:\MinGW\ directory with msys inside. This brought me to my first bit of confusion. When I opened the mingw shell, rather than bringing me to my /home/ directory as I expected ( I have used mingw before and remember this being weird ) it placed me in /c/Users/me/.
I figured that this must be my home directory and put the extracted SDL-1.2.15/ in this location.
I then ran:
cd SDL-1.2.15
./configure --help
but received sh: ./configure: No such file or directory.
I then created a /c/MinGW/msys/1.0/home/ directory, set that as the HOME environment variable, moved the SDL folder into it and tried to configure again with the same result.
There are a few things I really dont understand about installing packages that I hope someone can clear up. I have installed a few before and the ./configure; make; make install; seems to be a common procedure. I know msys provides the functionality for make, but is configure a file that is supposed to be included in each package? If so, why is it not in the SDL package/how do configure it?
I have been following instructions from here and they seem to have worked for others in the comments. The bottom-most comment tells that mingw-get-inst works, though I did try it both ways.
I have a feeling my lack of msys/mingw knowledge is my problem.
I am on windows 7.
I had the same problem as you describe and I got SDL, SDL_image and SDL_ttf working after some research.
It seems that the configure file exists only in the source code packages. I found that out after I downloaded the SDL_image source. So, the problem probably lies in that the configure file comes only in the source packages.
However, I'm having other problems so I'm not sure this has fixed it for me, but it seems like it should.
I need to build ffmpeg for Mac for converting MOV to FLV in a Java application. I made and installed LAME and then FFMPEG, but I'm confused as to what file I should grab to include with the Java application. What is the binary file? The previous version that I grabbed from the source of ffmpegX was 10mb in size, but the file that's in my /usr/local/bin is only 0.1mb. Is that the right file, or what do I need to include?
I'm not too savvy with anything that needs to be typed into Terminal, so excuse the lack of technical jargon!
Short answer: that file in /usr/local/bin is either the real binary or a soft link to the real binary. If you run ls -l /usr/local/bin any links will be displayed with an arrow to their target location. But pszilard is probably right, that file might be the actual binary, which was dynamically linked to library code.
Long answer: If you compiled from source, then you ran the following three commands
./configure
make
make install
The first one creates a configuration file called config.mak. Near the top of that file, you'll see a lines similar to the following:
prefix=/usr/local
LIBDIR=$(DESTDIR)${prefix}/lib
SHLIBDIR=$(DESTDIR)${prefix}/lib
INCDIR=$(DESTDIR)${prefix}/include
BINDIR=$(DESTDIR)${prefix}/bin
DESTDIR is optional; it's irrelevant unless you ran make install with an additional argument. BINDIR is the actual install location. On my system (snow leopard) that was /usr/local/bin/.
If you're still having trouble, just don't install the build. If you run
make clean
make
The binary will be in your build folder.
Don't use MacPorts or Fink. You'll be happier in the long run if you compile from source yourself. If you insist on using a package manager, try Homebrew <Link>.
I'm not a Mac expert by far, but I've a few tips. If you build the lib with dynamic linkage and the the other one was statically linked that might explain the size difference.
As for the location, what did you use? MacPorts, Fink, or source? If you built from source depends what you used :) MacPorts and Fink have their specific location for binaries (I don't remember anymore, but the documentation should have the info, otherwise the big G has it ;)
For what I've read I need Python-Dev, how do I install it on OSX?
I think the problem I have, is, my Xcode was not properly installed, and I don't have the paths where I should.
This previous question:
Where is gcc on OSX? I have installed Xcode already
Was about I couldn't find gcc, now I can't find Python.h
Should I just link my /Developer directory to somewhere else in /usr/ ???
This is my output:
$ sudo easy_install mercurial
Password:
Searching for mercurial
Reading http://pypi.python.org/simple/mercurial/
Reading http://www.selenic.com/mercurial
Best match: mercurial 1.5.1
Downloading http://mercurial.selenic.com/release/mercurial-1.5.1.tar.gz
Processing mercurial-1.5.1.tar.gz
Running mercurial-1.5.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-_7RaTq/mercurial-1.5.1/egg-dist-tmp-l7JP3u
mercurial/base85.c:12:20: error: Python.h: No such file or directory
...
Thanks in advance.
I was struggling with this problem all day today.
I eventually discovered a site that claimed that all one needed to do was to reinstall Xcode, or install the latest version (4.3.2, as of this writing).
So I tried that. It did not help; not on its own. But then I went a step further: I fired up Xcode.app, and once I had done that, I opened the Xcode..Preferences menu item, and then go to the Downloads tab, and say that you want to install the "Command Line Tools"
Once I did that, and then re-ran easy_install (in my case I was trying to "easy_install dulwich" to satisfy a hg-git dependency), it was able to properly find Python.h for me.
Might depend on what version of Mac OSX you have, I have it in these spots:
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/Python.h
/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/Python.h
Also I believe the version of python that comes with Xcode is a custom build that plays well with xcode but you have to jump through some hoops if you use another dev environment.
Are you sure you want to build Mercurial from source? There are binary packages available, including the nice MacHg which comes with a bundled Mercurial.
I'm sure this is a newbie question, but every time I've compiled/dl'ed a new version of vim for os x, running vim on the command-line opens up the gvim app. I just want to upgrade the console version (so I can, for example, have python compiled in to use omnicomplete).
If I understsood the question correcty, here is another solution: check out http://www.andrewvos.com/2011/07/23/upgrading-vim-on-os-x-with-homebrew/
Really simple, fast, painless. It uses homebrew-alt and you also need to have mercurial installed (it will prompt you if not).
You can also use MacPorts to handle the installation for you. Once you've installed it, run the /opt/local/bin/vim binary. I place this in my PATH before the system binary dirs (although be aware that this may cause problems for cmdline tools that rely on the versions of tools shipped with OS X).
This may sound stupid, but are you copying the vim binary to /usr/bin? by default, the "vim" path is /usr/bin/vim. If you compile from source, you'll likely need to either copy the vim binary to /usr/bin/vim (thus overwriting the original vim), or launch the compiled version via absolute path (eg. ~/vim-checkout/build/vim).
that's just a guess, however. I can't see it being anything more than that.
With Homebrew:
brew install macvim
ln -s /usr/local/bin/mvim /usr/local/bin/vim
Can also symlink your new binary to /usr/local/bin/