port upgrade -R dbus goes bananas, plus a couple of newbie Q's
I tried Marc's suggestion with respect to dbus and Gnome packages (including gnucash): port upgrade -R dbus. Bad scene. tclsh eats infinite memory (slowly; 600-odd megabytes in 5 minutes or so) and cripples the box. Cleanup after reboot wasn't too painful, and I'm walking the gnucash -> foo -> dbus dependencies manually now; but it strikes me that this isn't the designed behavior of port. How can I analyze this situation usefully? (I speak enough Tcl to be dangerous, but am unfamiliar with the current generation of debugging tools.) On another note: gtk-sharp seems to be insistent on a libgda with the default variants, but I would prefer not to have any DB other than sqlite on this box. I most especially do not want db4 installed unless and until I research thoroughly what it takes to minimize its corruption potential on MacOS. (No slur on SleepyCat, but bdb places unusual strains on kernels, filesystems, compilers, and core libraries.) Is there a syntax for "any libgda variant will do" that I can use in the gtk-sharp portfile? (I'm hoping to get F-Spot running.) One more newbie question: is there any semi-automated way of generating a template portfile given the results of a successful manual build with the usual ./configure && make && sudo make install? I have in mind something that grovels through the build tree for shared libs and executables, generating port dependencies from the libraries that they link against, and maybe determines bash/python/perl/whatever dependencies from #! lines. gajim works for me (or rather did before the gnome fallout, and I expect will again shortly) and I'd like to wrap a portfile around it if it's not too much agony. Cheers, - Michael P. S. Intel / 10.4.8, if it matters.
What do you mean by this? In what way is it "insistent"? Does installing libgda with a variant, then installing gtk-sharp cause it to try and re-install libgda? Or does the gtk-sharp compilation simply fail? Or does something else happen? On Feb 1, 2007, at 2:36 AM, Michael K. Edwards wrote:
On another note: gtk-sharp seems to be insistent on a libgda with the default variants, but I would prefer not to have any DB other than sqlite on this box. I most especially do not want db4 installed unless and until I research thoroughly what it takes to minimize its corruption potential on MacOS. (No slur on SleepyCat, but bdb places unusual strains on kernels, filesystems, compilers, and core libraries.) Is there a syntax for "any libgda variant will do" that I can use in the gtk-sharp portfile? (I'm hoping to get F-Spot running.)
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On 2/1/07, Kevin Ballard <eridius@macports.org> wrote:
What do you mean by this? In what way is it "insistent"? Does installing libgda with a variant, then installing gtk-sharp cause it to try and re-install libgda? Or does the gtk-sharp compilation simply fail? Or does something else happen?
Sorry, didn't save that particular error message; it was something to the effect of "active variant doesn't match the dependency". In the meantime, I eventually wiped /opt/local and reinstalled macports to deal with the dbus fallout. libgda now doesn't build without the bdb variant (even without --with-bdb the configure step picks up /usr/include/db.h, which is useless). So I set up a local Portfile repo and altered the libgda Portfile to add --without-bdb and modify the default variants. That seems to have been enough to fool gtk-sharp into deciding its dependencies are satisfied. Building gtk-sharp 2.10.0 as we speak. Cheers, - Michael
So I've managed to build the current gtk-sharp, gnome-sharp, and f-spot, and solve various dylib loading problems, but now I hit SIGBUS during or shortly after the dylib loading stage. This is with the binary Mono 1.2.2.1 distro, which I have concluded is a mistake -- its glib 2.6.3 probably conflicts with the macports glib 2.12.7. The next thing to try seems to be to use the mono port instead of the binary distro. All I can say is, I must want F-Spot on my Mac pretty badly. Cheers, - Michael
On 2/3/07, Michael K. Edwards <m.k.edwards@gmail.com> wrote:
So I've managed to build the current gtk-sharp, gnome-sharp, and f-spot, and solve various dylib loading problems, but now I hit SIGBUS during or shortly after the dylib loading stage. This is with the binary Mono 1.2.2.1 distro, which I have concluded is a mistake -- its glib 2.6.3 probably conflicts with the macports glib 2.12.7. The next thing to try seems to be to use the mono port instead of the binary distro. All I can say is, I must want F-Spot on my Mac pretty badly.
And, after some more fiddling with dll.config files, that worked. Now I'm running into crashing gnome-vfs bugs, of course, but at least I grok most of the packaging issues now. Word to the wise: do not use DYLD_LIBRARY_PATH. Ever. I still have to propagate some hand-hacks to dll.config files back as patches to the mono, gtk-sharp, and gnome-sharp sources. When that's done I'll post Portfiles and patches. Cheers, - Michael
On Feb 3, 2007, at 5:45 AM, Michael K. Edwards wrote:
Word to the wise: do not use DYLD_LIBRARY_PATH. Ever.
You might be able to use DYLD_FALLBACK_LIBRARY_PATH to achieve the desired effect with fewer conflicts. The use of DYLD_LIBRARY_PATH does seem to make things explode. :) Chris
participants (3)
-
cssdev＠mac.com
-
Kevin Ballard
-
Michael K. Edwards