I downloaded the FastX toolkit precomplied binaries for "MacOS X 10.5.8 (32-bit)" (http://hannonlab.cshl.edu/fastx_toolkit/download.html). However, when I cd into the directory with the tools and try to execute any of them (e.g. with any command like fastq_quality_filter -h), I get the error:
-bash: /usr/local/bin/fastq_quality_filter: cannot execute binary file
I'm not positive but it seems like it might be because the file kinds are "Unix executable" which might not be compatible with Mac (though I downloaded the binaries that were supposedly for Mac). I've tried chmod + x but the files already have execution permission so that didn't help. Any other ideas?
macOS 10.15 (Catalina) and newer do not support 32-bit apps. If you are on 10.15 or later, you need to either compile the toolkit yourself, or find a place to download 64-bit executables.
Related
I have a c ++ code that I wrote that uses almost nothing, which is not the language itself (except using osascript).
After compiling it on my operating system version (10.14.5) with the following flags:
D_DEBUG, Os, Wall, Wextra
I found that it was not running on older operating systems (in 10.13 for example - it raises an error that it can only run on 10.14 or later)
What are the right flags to use to tell GCC, that I want to support as many MacOs versions as possible?
You will need a versioning flag: -mmacosx-version-min=10.9
And let the compiler know where the SDK is: -isysroot= =/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
The older SDKs are available in older xcode bundles, or via https://github.com/phracker/MacOSX-SDKs/releases. You need to decompress the SDK and place the folder inside the xcode bundle, as shown in the sysroot flag above.
Apple sayeth: You must target your compile for the oldest version of OS X on which you want to run the executable. In addition, you should install and use the cross-development SDK for that version of OS X. For more information, see SDK Compatibility Guide
In attempting to install pkgin/pkgsrc (NetBSD-based package managment tools), using the saveosx.org instructions and github repository.
The repository has installation instructions, which I followed, up to the point of a specific but uninformative error:
It looks like there was an issue running: sudo /usr/pkg/bin/pkgin -y update
I tried running this file directly, but my terminal reports a segmentation fault.
I'm running OSX 10.7.5 and have Xcode-Command-Line Tools installed, but I find no information about Darwin version compatibility on NetBSD's site. My searches have revealed no one else reporting issues using pkgin.
Version 5.0+ is supported according to www.netbsd.org/docs/pkgsrc/platforms.html#darwin, which according to wikipedia (en.wikipedia.org/wiki/Darwin_%28operating_system%29#Release_history) corresponds to OSX 10.1.1+
What options do I have besides upgrading my operating system and hoping the problem is fixing by having newer libraries or a newer kernel?
For reference:
www.pkgsrc.org/#docs
www.perkin.org.uk/pages/pkgsrc-binary-packages-for-osx.html
wiki.netbsd.org/pkgsrc/pkgsrc_64bit_osx/
Related question: Unable to run pkgin on Mac OSX
It would appear that the pkgin binary currently supplied by saveosx is compiled only for more recent OSX releases. It needs at least a Darwin-14.x kernel, or newer, so it won't even run on 10.9.5. Unfortunately the script fails to check the OSX version before it blindly tries to run the pkgin binary, causing the program to crash.
saveosx is basically a painfully obnoxious, rather ugly, and poorly implemented. set of scripts that are superfluous to actually using pkgsrc on OSX.
I would strongly recommend avoiding saveosx for the time being.
Instead I would recommend trying the following well supported alternative:
OSX binary pkgsrc packages
A 32-bit Snow Leopard version that runs on 10.6.8 and newer is available, and I just checked the distribution directory and I see some 2015Q1 i386 packages are just now available, still supporting 10.6.8:
2015Q1 32-bit (i386) Snow Leopard and newer pkgsrc bootstrap
You can of course also build your own pkgsrc bootstrap for any specific OSX environment:
pkgsrc home
I have installed Xcode 5 on OS X Mavericks. I have a problem with the command-line tools (cc et al).
The version of cc in /usr/bin is outdated, so I’m not using it. The version of cc embedded deep within Xcode’s application bundle is current, so I’ve pasted the following code into my shell profile:
export PATH=`xcode-select -print-path`/usr/bin:`xcode-select -print-path`/Toolchains/XcodeDefault.xctoolchain/usr/bin:${PATH}
This worked under Xcode 4 on Mountain Lion. Now, however, while the compiler seems to run fine when invoked as cc, it won’t compile anything when I invoke it that way; it apparently cannot find system headers (e.g. stdio.h). When I invoke the compiler as xcrun cc, everything works just fine. Unfortunately, this requires me to patch the inputs for each and every build-automation program (such as make) before they will run properly.
The other problem is that I cannot find the command-line tools for download from ADC. As I upgraded from Mountain Lion, invoking /usr/bin/cc does not ask me if I want to download the tools; it just runs the (outdated) copy of cc from Xcode 4.
What is the difference between cc and xcrun cc, and is there anything I can do that will cause cc to work properly from the Terminal (or automated build tools)?
On OS X 10.9 Mavericks, run xcode-select --install to update the installed command line tools so they match the version inside of Xcode. This also installs header files into /usr/include and /System/Library and installs additional development libraries. This is a change from previous versions of OS X where the command line tools were either installed via Xcode.app itself or by an Xcode installer. It is still possible to download a standalone installer from the Apple Developer site but should normally no longer be necessary on 10.9.
I have no problems with cc (although you will get better results if you use clang instead of cc. I suggest that you remove the program, download it again, and install the command line tools with xcode-select --install
I've downloaded the source for KardsGT, which is written for I think QT 4.6.x onto my Mac OS X 10.6.8 system.
Since KardsGT is not written specifically for Mac OS X (it was meant for GNU/Linux), there is no associated XCode files, etc. When I run qmake on the source, I get lots of error like
WARNING: Ignored (not found) '/src/kardsgt-0.7.1/src/players/players-debug.xcodeproj'
It seems that qmake is thinking I am using XCode for this project? How do I correct this so the code will compile? (I've tried qmake -unix but that didn't change the results)
You do not need Xcode to compile a Qt program. Just run
$ qmake -config release
$ make clean
$ make
and you should be good to go (if the sources do not use any Linux-specific stuff).
I am using Mac OS X 10.6 SDK and my deployment target is set to Mac OS 10.5. I'm linking to libcrypto (AquaticPrime requires this) and found out that my app doesn't launch on Leopard. The error is
dyld: Library not loaded: /usr/lib/libcrypto.0.9.8.dylib
I've tried the following workarounds but none of them work:
Linking directly to libcrypto.0.9.7.dylib (the 10.6 SDK refuses to link directly with libcrypto.0.9.7.dylib.
Copying the 10.5 SDK's version of libcrypto.0.9.7.dylib to the 10.6 lib directory and try t link with it (this time the link process succeeded but in Leopard the app still tries to lookup the non-existent libcrypto.0.9.8.dylib file and thus won't launch).
Copying libcrypto.0.9.7.dylib from a Mac OS X 10.5.8 installation and link with it (the link was successful but the app still looks for libcrypto.0.9.8.dylib).
Is there a way to link to this library and still use the 10.6 SDK?
Thanks.
As per this thread here ( first post in thread: http://lists.apple.com/archives/cocoa-dev/2009/Aug/msg01737.html , "libcrypto on Snow Leopard" thread listing: http://lists.apple.com/archives/cocoa-dev/2009/Aug/thrd19.html ), I believe the solution is to do the following:
Go to /Developer/SDKs/MacOSX10.5.sdk/usr/lib/ . From this folder, copy "libcrypto.0.9.7.dylib" to your project source folder.
Rename the file you just copied to "libmycrypto.dylib".
Add the file you just renamed to your project. Make sure to remove any other linked libcrypto frameworks from your project.
Go through your build settings, and make sure you remove the "-lcrypto" linker flag. (It's usually put in the "Other Linker Flags" setting.)
Now you should be able to build your project and it will work on both 10.5 and 10.6.
(libcrypto.0.9.7 is available on both 10.5 and 10.6. The file you copied is just a stub of the headers, but you're just linking against it, not embedding it in your project. Since the linker uses the install path not the actual filename of the dylib, naming it "libmycrypto.dylib" eliminates path conflicts, but still allows you to link against the library you need.
FWIW, this is an Xcode problem. You should be able to link against /usr/lib/libcrypto.dylib -- the symbolic link -- and have it target the correct version of libcrypto on both 10.5 and 10.6. However, Xcode always seems to link to version 0.9.8 when building on Snow Leopard for some reason.)
You could try setting the base SDK to 10.5 in your target build settings.
Depending on what you're using the lib for, you might be able to replace libcrypto with CommonCrypto which works well with both 10.5 and 10.6. I've used libcrypto only for the MD5 function, so I replaced openssl/md5.h with CommonCrypto/CommonDigest.h and MD5() with CC_MD5(), and libcrypto with CommonCrypto, and now it works on both Leopards.
Have you tried linking against libcrypto.0.9.dylib or libcrypto.dylib instead of the specific versions?
Leopard OS X ships with a libcrypto and libssl that only has the ppc architecture.
A simple solution that doesn't require changing the code of the app is to backup your libcrypto.0.9.dylib, libcrypto.0.9.8.dylib, libssl0.9.dylib, libssl.0.9.8.dylib and copy over the libcrypto.0.9.7.dylib and libssl.0.9.7.dylib.
You can use Terminal.app to make these changes in your Applications folder:
cd /usr/lib
sudo cp libcrypto.0.9.dylib libcrypto.0.9.dylib.old
sudo cp libssl.0.9.dylib libssl.0.9.dylib.old
sudo ln -sf libcrypto.0.9.7.dylib libcrypto.0.9.dylib
sudo ln -sf libssl.0.9.7.dylib libssl.0.9.dylib
Here's an alternative solution that lets you stay on the freshest openssl version:
1. reactivate the current openssl: port activate openssl#1.0.0c_0 (or whatever)
2. clean up your old unwanted versions of everything: port uninstall inactive
3. uninstall badly behaved ports: port uninstall md5sha1sum subversion neon
4. get them back: port install subversion md5sha1sum