Since gnucash 2.0 was released five months ago, I've been anxiously awaiting a binary fink package, which I understand is slow in coming because of some experimental library dependencies. However, I recently noticed that there is now a portfile for it, and got excited. Gnucash is somewhat infamous for being a pain to compile by hand because of its huge pile of dependencies, so having that taken care of automatically sounded great. I've successfully used darwinports in the past with good success, so I set out on what has turned into a fool's errand. In a perfect world, I would expect that all I would have to incant to achieve such a feat would be something along the lines of: `port sync; port selfupdate; port sync; port install gnucash`, so I started with that. The port install failed for some reason (that I didn't record, sorry), so I figured maybe a `port update all` would help. It at least ran to completion without incident. Well, it substantially altered my default Muttrc, about which I'm pretty displeased, but everything at least compiled successfully. I then reran my gnucash install line, and had problems creating destroot for qt3. Specifically, it was trying to move something like /opt/local/var/db/dports/build/_private_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_x11_qt3/work/destroot/opt/local/lib/*.* to ~destroot/opt/local/lib/qt3/lib, and nothing was matching the glob. After a bunch of poking around, I found that the stuff it was looking for had actually been built in ~destroot/private/opt/local/lib, so I moved it over, convinced archive to rerun with some difficulty*, and all was happy. I have no idea why it was building the libraries in ~destroot/private/opt/..., since it built everything else in ~destroot/opt/..., but there it was. *: if I run port with -f, I expect the step to run, regardless of what the state file says; I don't expect to have to edit the state file by hand. `port clean --archive qt3` didn't even have the desired effect, though it printed a message that claimed to have done so. WTF? The qt3 hurdle passed, I continued with my port install gnucash aspiration, and came to the next dependency, aqbanking. If you guessed that it went poorly, you'd be right! ld: warning prebinding disabled because dependent library: /opt/local/lib/libgwenhywfar.38.dylib is not prebound ld: warning can't open dynamic library: /opt/local/lib/libintl.3.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _libintl_dgettext referenced from libgwenhywfar.38 expected to be defined in /opt/local/lib/libintl.3.dylib _libintl_bind_textdomain_codeset referenced from libgwenhywfar.38 expected to be defined in /opt/local/lib/libintl.3.dylib _libintl_bindtextdomain referenced from libgwenhywfar.38 expected to be defined in /opt/local/lib/libintl.3.dylib /usr/bin/libtool: internal link edit command failed make[5]: *** [libaqbanking.la] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 In fact, it couldn't find /opt/local/lib/libintl.3.dynlib because it didn't exist, so I suppose my frustration should be more focused on gettext than on aqbanking. Google led me to http://trac.macosforge.org/projects/macports/wiki/ProblemHotlist, which had me run a shell script to find a list of packages to rebuild. That might have been fine, except the script assumed that `port provides /path/to/foo` works correctly...nope: ~% port provides /opt/local/bin/ethereal /private/opt/local/bin/ethereal is not provided by a MacPorts port. ~% port contents ethereal | grep /opt/local/bin/ethereal /opt/local/bin/ethereal ~% port -v -d provides /opt/local/bin/ethereal DEBUG: Changing to port directory: /opt/local/bin/ethereal /private/opt/local/bin/ethereal is not provided by a MacPorts port. In fact, I can't find anything that `port provides` knows about, and the debug message about trying to treat /opt/local/bin/ethereal as a directory is pretty suspicious. So I chopped up the script and just got a list of files in which otool -L found references to libintl. I'd post it here, but it's 53 lines and I suspect it would just be distracting. I'll certainly provide it on request. I don't really want to identify the source packages for all 53 of those and rebuild them by hand. That's why I'm using a package _manager_. In fact, at this point, I've basically given up, and I'm going to reinstall fink's binary package for gnucash 1.8 when I next have time to work on this. Considering how well this install has gone so far, I really can't bring myself to continue when I expect I'll have more problems with most of the rest of the dependencies, and the list of them looks like this: Error: The following dependencies failed to build: aqbanking g-wrap slib-guile guile slib gconf libbonobo intltool p5-xml-parser orbit2 libidl popt gnucash-docs scrollkeeper docbook-xml docbook-xml-scrollkeeper docbook-xsl libxslt yelp gnome-vfs dbus gnome-mime-data howl neon libgnome esound audiofile libgnomeui gnome-keyring libbonoboui libgnomecanvas libart_lgpl libgtkhtml gail goffice libgnomeprintui gnome-icon-theme hicolor-icon-theme icon-naming-utils p5-xml-simple p5-xml-namespacesupport libgnomeprint bison m4 libgnomecups cups-headers libgsf libgtkhtml3 gal p5-finance-quote p5-crypt-ssleay p5-libwww-perl p5-compress-zlib p5-compress-raw-zlib p5-io-compress-base p5-io-compress-zlib p5-html-parser p5-html-tagset p5-uri p5-datemanip p5-html-tableextract If anyone can tell me something simple like "your darwinports install is completely messed up; run these five commands and wait 15 hours for everything to recompile", I'd be thrilled. Otherwise, consider this email a bug report. I'm not sure what packages I should really be filing reports against, so I'll let someone else do it or point me in the right direction and tell me what other info to include. I'm running Mac OS 10.4.8 on an iBook G4. uname -a says Darwin maunakea.magicpacket.net 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc Thanks for all the stuff that's worked, which is everything I've done with darwinports before now. I only wish this time had been so smooth. Sorry this email is so snarky. -E
On Dec 11, 2006, at 1:34 PM, Eric Angell wrote:
`port sync; port selfupdate; port sync; port install gnucash`,
selfupdate does a sync, so this could be reduced to: port selfupdate; port install gnucash
so I moved it over, convinced archive to rerun with some difficulty*, and all was happy. I have no idea why it was building the libraries in ~destroot/private/opt/..., since it built everything else in ~destroot/opt/..., but there it was.
This seems odd, but I'm not sure from your description exactly what happened.
*: if I run port with -f, I expect the step to run, regardless of what the state file says; I don't expect to have to edit the state file by hand.
You shouldn't have to, but you don't say what you ran (and what happened), why you decided to modify the state file, and what happened after you did.
`port clean --archive qt3` didn't even have the desired effect, though it printed a message that claimed to have done so. WTF?
So, it didn't remove the qt3 archive?
In fact, it couldn't find /opt/local/lib/libintl.3.dynlib because it didn't exist, so I suppose my frustration should be more focused on gettext than on aqbanking.
It's because you told macports to upgrade everything, without understanding what that meant (and without macports just 'doing the right thing' for you here).
That might have been fine, except the script assumed that `port provides /path/to/foo` works correctly...nope:
Ok, at this point I'm sure that there is something wrong with your macports install.
If anyone can tell me something simple like "your darwinports install is completely messed up; run these five commands and wait 15 hours for everything to recompile", I'd be thrilled.
If you don't mind re-installing any installed ports, you could do something like rm -Rf /opt/local Then download and install macports and do: port selfupdate and then try again with port install gnucash -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Eric, I can't help on your first problem installing macports, or the second one with qt3, but I ran in to something very similar to your libintl dylib problems. On Dec 11, 2006, at 13:34, Eric Angell wrote:
ld: warning prebinding disabled because dependent library: /opt/local/lib/libgwenhywfar.38.dylib is not prebound ld: warning can't open dynamic library: /opt/local/lib/libintl.3.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _libintl_dgettext referenced from libgwenhywfar.38 expected to be defined in /opt/local/lib/libintl.3.dylib _libintl_bind_textdomain_codeset referenced from libgwenhywfar.38 expected to be defined in /opt/local/lib/libintl.3.dylib _libintl_bindtextdomain referenced from libgwenhywfar.38 expected to be defined in /opt/local/lib/libintl.3.dylib /usr/bin/libtool: internal link edit command failed make[5]: *** [libaqbanking.la] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
I think the script and script snippets in the second hint on http:// trac.macosforge.org/projects/macports/wiki/ProblemHotlist might help you solve problems related to a missing libint.3.dylib. This process is what I did on two machines, one PPC and one Intel, to solve this problem, and I have gnucash on both machines now. Frank
On Mon, Dec 11, 2006 at 13:56:16 -0500, Daniel J. Luke wrote:
selfupdate does a sync, so this could be reduced to:
port selfupdate; port install gnucash
Good to know, thanks.
so I moved it over, convinced archive to rerun with some difficulty*, and all was happy. I have no idea why it was building the libraries in ~destroot/private/opt/..., since it built everything else in ~destroot/opt/..., but there it was.
This seems odd, but I'm not sure from your description exactly what happened.
Sorry, I didn't save the logs from everything because I didn't expect to have such a hard time, so I don't have exact error messages. I'll try the explanation again. As far as I could see, the only error message that I got during the qt3 build process was from `mv ~destroot/opt/local/lib/*.* ~destroot/opt/local/lib/qt3/lib`, which told me '.../*.*: No such file or directory'. That message was accurate, as the only thing in .../lib was a directory named qt3, so the *.* glob didn't match anything. I found another directory, ~destroot/private/opt/local/lib, that contained several library files and symlinks providing alternate names for them. Since there was a lot of different stuff under ~destroot/opt/local, and only this one directory under ~destroot/private, I assumed that some build setting had been misconfigured, though I wasn't able to locate it. The error had come from a mv command during the com.apple.destroot phase, but the build phase had run to completion. So I moved the stuff in ~destroot/private/opt over to ~destroot/opt, and got everything to package up and install nicely. aqbanking was then able to find the relevant qt libraries to let its configure script run to completion and start the build. (When I first got the error, I touched foo.bar in the appropriate directory, but the installed qt package then didn't include any libraries, so aqbanking failed to configure. I left that part out of the original description, sorry).
*: if I run port with -f, I expect the step to run, regardless of what the state file says; I don't expect to have to edit the state file by hand.
You shouldn't have to, but you don't say what you ran (and what happened), why you decided to modify the state file, and what happened after you did.
Once I had tricked qt3 into finishing by touching foo.bar, it created a .tgz and deleted the entire work directory. Since that didn't fix my problem, I wanted to futz with it some more, so I ran `port uninstall qt3`, which appropriately removed all of the installed files. I don't remember the exact order I ran other commands in, but I think I tried a `port install qt3`, figuring it would fail in the same way, but it just found its tgz package and reinstalled it, so I uninstalled again, then ran `port clean --archive qt3`, which deleted the .tgz. However, it did not clean the state file, so when I ran `port install qt3` again, it assumed it was still archived, and complained when it couldn't find the .tgz. `port -f build qt3` got me back to my original build problem, but after I located the ~destroot/private/ business, I still couldn't get it to create a new .tgz. `port -f archive qt3` said something about "creating the archive...skipping that step, it's already done". Once I manually deleted the line in the state file, then it ran the archive and installed, letting me go on to aqbanking.
`port clean --archive qt3` didn't even have the desired effect, though it printed a message that claimed to have done so. WTF?
So, it didn't remove the qt3 archive?
It removed the .tgz, but it did not modify the state file, and a further `port -f archive qt3` refused to create the archive, insisting that it already existed.
In fact, it couldn't find /opt/local/lib/libintl.3.dynlib because it didn't exist, so I suppose my frustration should be more focused on gettext than on aqbanking.
It's because you told macports to upgrade everything, without understanding what that meant (and without macports just 'doing the right thing' for you here).
Okay, I may be naive in assuming that `port upgrade all` might help with my build problems. Again, I don't remember the original build error from qt3, but I'm pretty sure it changed after I did the upgrade all.
That might have been fine, except the script assumed that `port provides /path/to/foo` works correctly...nope:
Ok, at this point I'm sure that there is something wrong with your macports install.
If anyone can tell me something simple like "your darwinports install is completely messed up; run these five commands and wait 15 hours for everything to recompile", I'd be thrilled.
If you don't mind re-installing any installed ports, you could do something like
rm -Rf /opt/local
Then download and install macports and do:
port selfupdate
and then try again with
port install gnucash
Given that you think my current install is damaged based on the `port provides` behavior, I could see this as a potentially reasonable step. I know of at least one program (NmapFE) which is installed in /Applications/Darwinports/ rather than /opt/local. Is it likely that there is anything else outside /opt/local? I also note that the portfile for NmapFE no longer exists, but I haven't checked yet to see if that's because it's more of a Cocoa app anyway. If I assume that the only thing reinstalling from scratch would cost me is a bit of compile time, then it makes sense just to do it. Since it could botch the currently working installation of one of my ~60 packages, I'm a bit wary. -E
On Mon, Dec 11, 2006 at 15:41:53 -0500, Frank McPherson wrote:
I think the script and script snippets in the second hint on http:// trac.macosforge.org/projects/macports/wiki/ProblemHotlist might help you solve problems related to a missing libint.3.dylib. This process is what I did on two machines, one PPC and one Intel, to solve this problem, and I have gnucash on both machines now.
Thanks Frank. I did find that link as I mentioned in my first mail, but I ran into other problems while trying to follow the procedure listed there to fix it. -E
On Dec 11, 2006, at 5:21 PM, Eric Angell wrote:
This seems odd, but I'm not sure from your description exactly what happened.
Sorry, I didn't save the logs from everything because I didn't expect to have such a hard time, so I don't have exact error messages. I'll try the explanation again. As far as I could see, the only error message that I got during the qt3 build process was from `mv ~destroot/opt/local/lib/*.* ~destroot/opt/local/lib/qt3/lib`, which told me '.../*.*: No such file or directory'.
Um, so you have a user named destroot and have somehow managed to get macports to use it's home directory as the destroot when building ports? (or are you just using ~ as a shortcut for the normal path to the destroot?)
(When I first got the error, I touched foo.bar in the appropriate directory, but the installed qt package then didn't include any libraries, so aqbanking failed to configure. I left that part out of the original description, sorry).
Yep, the qt3 port must have been broken (or at least broken on your system).
*: if I run port with -f, I expect the step to run, regardless of what the state file says; I don't expect to have to edit the state file by hand.
You shouldn't have to, but you don't say what you ran (and what happened), why you decided to modify the state file, and what happened after you did.
Once I had tricked qt3 into finishing by touching foo.bar, it created a .tgz and deleted the entire work directory. Since that didn't fix my problem, I wanted to futz with it some more, so I ran `port uninstall qt3`, which appropriately removed all of the installed files. I don't remember the exact order I ran other commands in, but I think I tried a `port install qt3`, figuring it would fail in the same way, but it just found its tgz package and reinstalled it, so I uninstalled again, then ran `port clean --archive qt3`, which deleted the .tgz.
I think here you actually wanted port clean --all qt3 (as that would have removed the archive and the now stale work directory). FYI, archives are off by default on new macports installs.
It removed the .tgz, but it did not modify the state file, and a further `port -f archive qt3` refused to create the archive, insisting that it already existed.
That's a bug that should probably be fixed. port -f archive should force new archive creation if it doesn't. Could you file a bug on this? [I might even feel motivated to fix it ;-) ]
Okay, I may be naive in assuming that `port upgrade all` might help with my build problems. Again, I don't remember the original build error from qt3, but I'm pretty sure it changed after I did the upgrade all.
That's possible. It's possible that some out-of-date other macports provided software could have caused the original failure.
Given that you think my current install is damaged based on the `port provides` behavior, I could see this as a potentially reasonable step. I know of at least one program (NmapFE) which is installed in /Applications/Darwinports/ rather than /opt/local. Is it likely that there is anything else outside /opt/local?
There are a couple of ports that install under /Applications/ Darwinports or /Applications/MacPorts macports provided X11 also doesn't install under /opt/local (because it refuses to work correctly if installed there). If you forget to remove anything, you'll just find out later when you go to install that same package again (as macports will refuse to install over it unless you use force). So you'll be able to clean it up.
I also note that the portfile for NmapFE no longer exists, but I haven't checked yet to see if that's because it's more of a Cocoa app anyway.
IIRC It's because NmapFE isn't supported anymore and is superseded by the +gtk2 nmap variant.
If I assume that the only thing reinstalling from scratch would cost me is a bit of compile time, then it makes sense just to do it. Since it could botch the currently working installation of one of my ~60 packages, I'm a bit wary.
You could always tar up /opt/local before you remove it and restore it if your new install doesn't work ... -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On Mon, Dec 11, 2006 at 18:43:05 -0500, Daniel J. Luke wrote:
(or are you just using ~ as a shortcut for the normal path to the destroot?)
Yes. I didn't particularly want to type (or even paste) /opt/local/var/db/dports/build/_private_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_x11_qt3/work/ several times. I hoped my shorthand would be understood, sorry for the confusion.
It removed the .tgz, but it did not modify the state file, and a further `port -f archive qt3` refused to create the archive, insisting that it already existed.
That's a bug that should probably be fixed. port -f archive should force new archive creation if it doesn't.
Could you file a bug on this? [I might even feel motivated to fix it ;-) ]
Yes, though I might take a little while to do so.
You could always tar up /opt/local before you remove it and restore it if your new install doesn't work ...
Very good point. I'll give the full reinstall a shot when I get a chance in the next few weeks and report success or failure back to the list. -E
On Dec 11, 2006, at 16:21, Eric Angell wrote:
If you don't mind re-installing any installed ports, you could do something like
rm -Rf /opt/local
Then download and install macports and do:
port selfupdate
and then try again with
port install gnucash
Given that you think my current install is damaged based on the `port provides` behavior, I could see this as a potentially reasonable step. I know of at least one program (NmapFE) which is installed in /Applications/Darwinports/ rather than /opt/local. Is it likely that there is anything else outside /opt/local? I also note that the portfile for NmapFE no longer exists, but I haven't checked yet to see if that's because it's more of a Cocoa app anyway.
Possibly there are other things outside of /opt/local. Therefore the correct way to remove all of MacPorts is described here: http://trac.macosforge.org/projects/macports/wiki/ FAQ#HowdoIremoveoruninstallMacPorts
On Dec 11, 2006, at 12:34, Eric Angell wrote:
I then reran my gnucash install line, and had problems creating destroot for qt3. Specifically, it was trying to move something like /opt/local/var/db/dports/build/ _private_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_d pupdate_dports_x11_qt3/work/destroot/opt/local/lib/*.* to ~destroot/opt/local/lib/qt3/lib, and nothing was matching the glob. After a bunch of poking around, I found that the stuff it was looking for had actually been built in ~destroot/private/opt/local/lib, so I moved it over, convinced archive to rerun with some difficulty*, and all was happy. I have no idea why it was building the libraries in ~destroot/private/opt/..., since it built everything else in ~destroot/opt/..., but there it was.
[snip]
~% port provides /opt/local/bin/ethereal /private/opt/local/bin/ethereal is not provided by a MacPorts port. ~% port contents ethereal | grep /opt/local/bin/ethereal /opt/local/bin/ethereal ~% port -v -d provides /opt/local/bin/ethereal DEBUG: Changing to port directory: /opt/local/bin/ethereal /private/opt/local/bin/ethereal is not provided by a MacPorts port.
Why is your /opt inside /private? That should not be. Perhaps you installed the Cisco VPN client and it screwed up your MacPorts? Please see: http://lists.apple.com/archives/student-dev/2005/Nov/msg00074.html This used to be in the FAQ but was removed two months ago, apparently because Cisco fixed their VPN client. But maybe you used an older version. http://trac.macosforge.org/projects/macports/wiki/FAQ? version=1#IjustinstalledMacPorts1.2fromthe.dmgandIseemtohavelostallmyins talledportsakaCiscoVPNatemyMacPorts
On Mon, Dec 11, 2006 at 20:20:40 -0600, Ryan Schmidt wrote:
Why is your /opt inside /private? That should not be. Perhaps you installed the Cisco VPN client and it screwed up your MacPorts?
That is exactly true! I have the Cisco VPN client 4.7.00, which I probably installed over a year ago, though somehow nothing else has gone horribly wrong since then. It was definitely installed after Darwinports, though. That could certainly explain why qt3 got confused and started in with the destroot/private/... I'll rip out qt3, move everything out of /private, and see if another upgrade all helps, then I'll try the stuff from http://trac.macosforge.org/projects/macports/wiki/ProblemHotlist if `port provides` starts working after /private/opt -> /opt. Thanks! -E
Eric Angell <lists-macports-users@magicpacket.net> on Monday, December 11, 2006 at 8:23 PM -0800 wrote:
That is exactly true! I have the Cisco VPN client 4.7.00, which I probably installed over a year ago, though somehow nothing else has gone horribly wrong since then.
The Cisco client is up to 4.9.01 now and the bug was quashed some time ago. Mark
On Mon, Dec 11, 2006 at 18:43:05 -0500, Daniel J. Luke wrote:
It removed the .tgz, but it did not modify the state file, and a further `port -f archive qt3` refused to create the archive, insisting that it already existed.
That's a bug that should probably be fixed. port -f archive should force new archive creation if it doesn't.
Could you file a bug on this? [I might even feel motivated to fix it ;-) ]
Done, sooner than expected. http://trac.macports.org/projects/macports/ticket/11143 Thanks for your help, despite my original tone. -E
On Dec 13, 2006, at 1:09 AM, Eric Angell wrote:
Done, sooner than expected. http://trac.macports.org/projects/macports/ticket/11143
Ok, it looks like it's not just a bug with the archive target (like I originally thought), but force doesn't override the state file for other targets too. If a base/ committer (or at least someone who has more familiarity with base/ than I do) could comment, that would be appreciated. (I can create a patch and test it, but it would be helpful for someone to let me know if I'm going to break everything by changing portutil.tcl and/or if I should look elsewhere).
Thanks for your help, despite my original tone.
no problem. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
I'm coming in late to the discussion, but I decided to look into this. It seems the -f switch doesn't take effect until after the current statefile is checked. This runs contrary to the documentation of the - f switch, but I'm not sure it's wrong. For example, if I have a port caml-extlib installed, and I do `port -f extract caml-extlib`, it will extract it anyway (the -f switch overrides the fact that the port is installed, in this case). Then if I do `port -f configure caml-extlib` it will avoid re-extracting it, since I already extracted it, and it will move on to patching and configuring it. This is potentially useful, because you can run steps in sequence without re-doing the same work over and over. I would suggest that the documentation of the -f switch be updated to more accurately reflect what it does (makes it ignore the fact that the port is already installed) without changing current behaviour. If you want to re-run archive, you can either clean (and let it rebuild - if you don't rebuild, re-archiving isn't particularly helpful) or you can edit the stateful (yeah, ugly). For sake of argument, if the - f switch behaved as documented then trying to re-run archive would re- run all the previous steps anyway. If you think there's a valid reason for saying "perform this step again", maybe a new switch could be introduced that would edit the statefile and remove the given target (and any subsequent targets) from it, so you could say `port -- i-really-mean-it archive caml-extlib` and it would forget the fact that it had already run com.apple.archive (without forgetting any previous steps). On Dec 13, 2006, at 10:56 AM, Daniel J. Luke wrote:
On Dec 13, 2006, at 1:09 AM, Eric Angell wrote:
Done, sooner than expected. http://trac.macports.org/projects/macports/ticket/11143
Ok, it looks like it's not just a bug with the archive target (like I originally thought), but force doesn't override the state file for other targets too.
If a base/ committer (or at least someone who has more familiarity with base/ than I do) could comment, that would be appreciated. (I can create a patch and test it, but it would be helpful for someone to let me know if I'm going to break everything by changing portutil.tcl and/or if I should look elsewhere).
Thanks for your help, despite my original tone.
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On Mon, Dec 11, 2006 at 20:20:40 -0600, Ryan Schmidt wrote:
Why is your /opt inside /private? That should not be. Perhaps you installed the Cisco VPN client and it screwed up your MacPorts?
This used to be in the FAQ but was removed two months ago, apparently because Cisco fixed their VPN client. But maybe you used an older version.
Thanks again. I put /private/opt back in /opt, removed the Cisco vpn client (I no longer work there, so I don't need it), performed the rebuilding step to fix the libintl problem, and reran `port install gnucash`. The only thing that didn't go smoothly was that `port -duf uninstall foo` didn't remove the old unactivated versions of foo as suggested by http://trac.macosforge.org/projects/macports/wiki/ProblemHotlist so I had to run a bunch of uninstall foo @version commands by hand. It didn't quite take all 15 hours I guessed originally... That's one bizarre bug. On Mon, Dec 11, 2006 at 20:33:04 -0800, Mark Duling wrote:
The Cisco client is up to 4.9.01 now and the bug was quashed some time ago.
Yes, but when one's company says "here's the vpn client package, and it's preloaded with a list of configurations for our various incoming vpn servers", it's easy just to install it and see that it works. Also, this was over a year ago, so it may have been the newest version at that point. Since the installer was what messed everything up, I don't expect that upgrading to a later version would have fixed it. -E
participants (6)
-
Daniel J. Luke
-
Eric Angell
-
Frank McPherson
-
Kevin Ballard
-
Mark Duling
-
Ryan Schmidt