Workaround gnutar for gdbm
Hi all, Path to gnu tar seems hardcoded in make procedure for gdbm so here's how I quickly worked around that problem: So if you into /usr/bin/gnutar not found whilst upgrading your ports after Maveriks just install gnu tar from port (sudo port install gnutar) and then cd /usr/bin and sudo ln -s /opt/local/bin/gnutar . Hope it helps someone else! Best, Alejandro Imass ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Workaround gnutar for gdbm
On Mon, Mar 3, 2014 at 6:47 PM, Alejandro Imass aim...@yabarana.com wrote: Path to gnu tar seems hardcoded in make procedure for gdbm so here's how I quickly worked around that problem: If you get an error about /usr/bin/gnutar after upgrading, it means you did not follow the Migration instructions ( http://trac.macports.org/wiki/Migration ) that are mandatory after any OS X upgrade, and other things will break for you later. Your quick workaround might work for a few things, but will also just propagate problems. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Workaround gnutar for gdbm
Hi Alejandro, Path to gnu tar seems hardcoded in make procedure for gdbm so here's how I quickly worked around that problem: I can assure you that is not the case. I'm on Mavericks, don't have /usr/bin/gnutar and no gnutar port installed and gdbm builds fine from source (even in the sandbox hiding /usr/local and all files gdbm doesn't depend on) for me. So if you into /usr/bin/gnutar not found whilst upgrading your ports after Maveriks just install gnu tar from port (sudo port install gnutar) and then cd /usr/bin and sudo ln -s /opt/local/bin/gnutar . Please don't change stuff in /usr/bin – that's Apple-land. Furthermore, this symlink might later be picked up by MacPorts' configure script during its next selfupdate and then end up getting baked into your MacPorts release, effectively breaking it when you (or the next OS upgrade) ever remove it again. So, save yourself some trouble, delete the symlink and follow the instructions specifically laid out for this very case: - https://trac.macports.org/wiki/MavericksProblems#UpdatingMacPortsBase - https://trac.macports.org/wiki/Migration (since you didn't do that after upgrading to Mavericks, I assume) - http://apple.stackexchange.com/questions/106189/missing-usr-bin-gnutar-on-mavericks-macports - https://twitter.com/macports/status/393296788062355456 - and the numerous mentions of this very issue on this mailing list After you've done Migration, everything should be back to normal again. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Workaround gnutar for gdbm
On Mon, Mar 3, 2014 at 6:58 PM, Clemens Lang c...@macports.org wrote: Hi Alejandro, I can assure you that is not the case. I'm on Mavericks, don't have /usr/bin/gnutar and no gnutar port installed and gdbm builds fine from source (even in the sandbox hiding /usr/local and all files gdbm doesn't depend on) for me. [...] Please don't change stuff in /usr/bin - that's Apple-land. Furthermore, this symlink might later be picked up by MacPorts' configure script during its next selfupdate and then end up getting baked into your MacPorts release, effectively breaking it when you (or the next OS upgrade) ever remove it again. So, save yourself some trouble, delete the symlink and follow the instructions specifically laid out for this very case: - https://trac.macports.org/wiki/MavericksProblems#UpdatingMacPortsBase - https://trac.macports.org/wiki/Migration (since you didn't do that after upgrading to Mavericks, I assume) - http://apple.stackexchange.com/questions/106189/missing-usr-bin-gnutar-on-mavericks-macports - https://twitter.com/macports/status/393296788062355456 - and the numerous mentions of this very issue on this mailing list After you've done Migration, everything should be back to normal again. -- Clemens Lang Thanks a lot for both your replies. I will follow the upgrade procedure then. I was running a pretty well updated version of Xcode and OS X and since my Xcode didn't change I figured it was just a minor nuance but apparently it's not. 5 mins after I wrote the email I saw the first big gotcha with llvm 3 :( Thanks again! Alejandro Imass ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Workaround gnutar for gdbm
On Mon, Mar 3, 2014 at 7:03 PM, Alejandro Imass aim...@yabarana.com wrote: Thanks a lot for both your replies. I will follow the upgrade procedure then. I was running a pretty well updated version of Xcode and OS X and since my Xcode didn't change I figured it was just a minor nuance but apparently it's not. 5 mins after I wrote the email I saw the first big gotcha with llvm 3 :( Everything even remotely related to C++ is completely broken post-upgrade, because Apple switched C++ runtimes in Mavericks. The only thing you can do about it is rebuild, and replace some ports with compatible versions. This kind of thing is why the Migration instructions are so invasive; there just aren't any shortcuts you can take when Apple decides to change something that fundamental, and they (of course) don't ask third parties for permission before doing it. :( -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Workaround gnutar for gdbm
On Mon, Mar 3, 2014 at 7:03 PM, Alejandro Imass aim...@yabarana.com wrote: On Mon, Mar 3, 2014 at 6:58 PM, Clemens Lang c...@macports.org wrote: Hi Alejandro, [...] Please don't change stuff in /usr/bin - that's Apple-land. Furthermore, this symlink might later be picked up by MacPorts' configure script during its next selfupdate and then end up getting baked into your MacPorts release, effectively breaking it when you (or the next OS upgrade) ever remove it again. So, Oops feeling really stupid by not RTFM! The very first paragraph (https://trac.macports.org/wiki/MavericksProblems#UpdatingMacPortsBase) : quote Versions of MacPorts built on 10.8 or lower will fail to install packages on Mavericks because of a missing /usr/bin/gnutar. The solution to that problem is to re-install MacPorts using the installer for Mavericks. Do not create a symlink named /usr/bin/gnutar pointing to a different version of tar or a version of gnutar you installed using MacPorts or yourself. /quote Thanks again! Alejandro Imass ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
