I've been trying to install a few dependencies for an application I'm running and I'm worried I might have broken the dev environment. I'm running this program on a MacBook (OSX Tiger, I don't have access to a newer one). MacPorts is officially broken, returning this error when I try and run any command:
sqlite error: near "ADD": syntax error (1) while executing query: ALTER TABLE registry.files ADD COLUMN binary bool
while executing
"registry::open $db_path"
(procedure "mportinit" line 633)
invoked from within
"mportinit ui_options global_options global_variations"
Seeing as this happens on any port __ command, I can't use the standard way of uninstalling MacPorts. However, given that I'm the one who got it in this condition in the first place, I'd rather not root around myself without knowing what I'm doing.
Is this problem fixable? Just in the interests of my own knowledge, does anyone know what exactly could have caused this error or what it actually means in terms of macport's functioning?
How can I (assuming this is necessary/a good idea) thoroughly uninstall macports? I'd rather not have to go through the trouble of reinstalling all my ports afterwards, but it's better than what I've got now.
MacPorts will usually still work on older versions of Mac OS X as the developers do not intentionally break compatibility. MacPorts officially only supports the latest release of Mac OS X and the one before (at the time of this writing this is 10.7 Lion and 10.6 Snow Leopard).
However, according to your report here, the latest MacPorts 2.1.0 upgrade seems to have compatibility problems with Mac OS X 10.4 Tiger. As indicated in the error message above, the older SQLite library version does not seem to understand the ALTER TABLE ... ADD COLUMN syntax used to update the port registry.
For this case, I assume only the upgrade procedure itself is affected and normal operation would work. This procedure is supposed to bring your MacPorts registry to a newer version required for the new features added in this release. Creating a new, empty registry would probably still work. However, this requires a full reinstall of MacPorts and all of your ports.
Please follow the uninstall instructions, but skip the first command as port cannot be executed anymore. This might leave some traces of ports installing to system locations, but in most cases this works fine. Afterwards, install MacPorts from source using the installation instructions in the guide.
This was a bug in MacPorts 2.1.0 that only affected Tiger, that was fixed in 2.1.1. If you are still running 2.0.4, you can "sudo port selfupdate" to 2.1.1 without problems. If you already ran selfupdate while 2.1.0 was out and are thus unable to use any port commands, you can re-run the last disk image installer for Tiger, and then run selfupdate to get to 2.1.1.
Related
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've looked pretty carefully (I believe), and have been unsuccessful at getting an installation of Git for my Mac.
For various reasons, I'm running 10.6.8 of Mac OS X and will not be changing that anytime soon.
I've already gathered and installed the bundle exposed here:
https://help.github.com/articles/set-up-git
The installation instructions are pretty clear, and it's obvious to me that the package installed. But any attempts to use the git client from the command line result in an "Illegal Instruction" error.
I've sifted pretty carefully through information available here:
http://git-scm.com/book/en/Getting-Started-Installing-Git
There is another bundle that seems to be available. It is called "GitHub for Mac 1.7.5, but it appears to require Mac OS X 10.7 or later.
Has anyone else encountered this difficulty? Must I build from source?
I'm a couple of hours of reading and hacking into this effort? Is there something obvious that I've not considered?
Yes, I've had the same exact problem, and what I did is installed an earlier build from here:
https://code.google.com/p/git-osx-installer/
I'm running 10.6.8 and installed the newest build there, 1.8.4.2
SourceForge only has 1.9.0 and 1.8.5.2
http://sourceforge.net/projects/git-osx-installer/reviews?source=navbar
Someone on the reviews said they had trouble with both and went back to 1.7. I would try that if 1.8.4.2 doesn't work.
I was able to run the config commands without an illegal instruction error, at least.
I had this problem and was able to install a working version using Homebrew.
# first uninstall the broken version
# mount the DMG for the broken version using Finder
# "type" this with the tab key! it saves typing and fixes the version number
cd /Volumes/Git\ 2.0.1\ Snow\ Leopard\ Intel\ Universal/
./uninstall.sh
# make bash forget about the uninstalled binary
hash -r
cd
# now install the working version
# assumes you have Homebrew installed
brew install git
git version
I had this today on Snow Leopard after running the suggested git installer from git-scm. Really horrible. Found that installing Macports using their old Snow Leopard package and then
sudo port install git +svn +doc +bash_completion +gitweb
installs git plus its dependencies and git now works fine; version 1.9.3 installed and working on 10.6.8.
I had the same problem. There are various methods for downloading and installing git - Try macports or homebrew. The thing that finally worked for me was having xcode 3.2.6 installed with the additional command line tools - version 3.2 that comes with the leopard install disk wasn't enough. You can install xcode etc. from the disk and then run software update to upgrade it to 3.2.6.
The latest build for Snow Leopard in the official git-osx-installer repo is Git 2.3.5 currently. You can download it from http://sourceforge.net/projects/git-osx-installer/files/git-2.3.5-intel-universal-snow-leopard.dmg/download using web browser. This installation works for me on OS X 10.6.8.
Or you can check yourself for a newer version: http://sourceforge.net/projects/git-osx-installer/files/
Yes - it seems that it does not support the older OS version (mine was 10.6.8). I upgraded to the newest Mac OS 10.9.4 (the installation will take a while), reinstalled the Git software (note that it will ask for xcode to be installed, which I proceeded), and everything works fine from there. Hope this helps.
Ref : https://help.github.com/articles/does-github-for-mac-run-on-os-x-10-6-snow-leopard
To quote:
Does GitHub for Mac run on OS X 10.6 Snow Leopard?
No, GitHub for Mac requires OS X 10.7 (Lion) or higher.
We made this decision because the app relies on a number of
technologies which are not available in Mac OS X 10.6 or earlier. We
want to provide the best experience possible for the app's users, so
we've made the choice to only support 10.7 and above, and not make
earlier versions available.
I'm completely new with MacOS X and I'm not underestanding where my system postgresql 9.1.5 is installed. I want to upgrade to 9.2 but I would like to uninstall this default installation before.
When I type in the terminal
$> psql --version
The result is:
psql (PostgreSQL) 9.1.5
but I can not find this installation.
MacOS X does not come with PostgreSQL installed as a server (unless you have OS X Server Edition).
Only the client-side PostgreSQL commands and the libpq library ship with the system. These include the psql command that resides is /usr/bin along with other commands such as pg_dump, pg_restore, createdb... You don't have to remove them, and if you did, it's not clear anyway what would prevent the next maintenance update of the OS to put them back.
So if you didn't previously install PostgreSQL yourself on this system, going to 9.2 is not an upgrade, it's a fresh install.
There are a number of providers of PostgreSQL packages for Mac OS X: postgres.app, homebrew, fink, macports...
These packages provide both a server and the client tools with the same version than the server, they have distinct installation paths, and they don't overwrite anything in /usr/bin. Once installed, you want to use the commands from the package preferrably to the ones in /usr/bin, which means technically putting them first in your PATH. Each package I've seen comes with a mention on how to do that in its installation instructions.
You don't have to remove the version Apple ships.
I have been using MacPorts to run various custom builds of PostgreSQL on OSX. It takes a little effort to make it "just work" (PATH and PG environment variables) but I never had to remove Apple's copy of Postgres.
I also keep a VM (VirtualBox) of a pretty minimal Debian install with Postgres running. I can do all my testing against the VM with a change of PG variables or JDBC URL. It's not as performant as running on the host but it is really clean for development.
I want the latest version of openmpi. I like to use macports because it is easy to install, uninstall, and upgrade software. I have installed the latest mpi via building from source, but no one seems to be able to get it to build properly with macports. There is always a build error. There are tickets (and you can see the logs at ), but they seem to be collecting dust and it seems strange that no one had found a solution.
I have tried uninstalling the built in version (I know, openmpi says not to do that--but it works fine if I reinstall it--even in a different directory), but I still the same build errors. I also tried with different gcc.
Does anyone know what is so difficult about getting openmpi via macports?
sudo port install openmpi
worked for me
I've installed Snow Leopard over Leopard with macports and rubygems already installed. This was regular install, not a clean "archive and erase" install.
It turned out, that SL has 64bit versions of shared libraries and many development utilities do not work. For example, "port" command complains on incompatible tcl library, or ruby cannot load 32bit bundles.
What is the easiest way to solve these issues?
I was googling for the answer for about 4 days already and finally came up with a step-by-step manual on fixing macports and rubygems:
http://oleganza.tumblr.com/post/127709563/snow-leopard-with-legacy-macports-and-rubygems
In short: for proper use of macports and rubygems you would have to:
Install trunk macports from source (or use 1.8 version when it is released)
Add alias for "gem install with 64bit architecture"
Reinstall all ports (not automated yet)
Reinstall all gems (100% automated)
This would take 10-20 minutes of your personal time and another 20
minutes of machine time in order to build and install stuff.
I would be glad to get more answers in order to fix other issues we might meet later.
Since it's really hard to force MacPorts to recompile all ports (in the proper order), I just did:
mv /opt /opt.old
Then install MacPorts 1.8, and bring back any configs you need from /opt.old/local/etc/
Otherwise, you'll get assorted errors complaining about your existing libs' architecture, (e.g. "Command output: ld: warning: in /opt/local/lib/libz.dylib, file is not of required architecture").
This isn't as clean as 'port uninstall installed' but works fast and good enough for me.
Richard Dooling's MacPorts On Snow Leopard explains that to fix the older install of MacPorts, which is broken after the upgrade to Snow Leopard, you should just download and install the new compatible version over the old one and then simply follow the migration instructions - which also say the same.