December 2007 - macports-users - lists.macosforge.org

Re: First port installation fails
by Richard Tobin 13 Dec '07

13 Dec '07

> The p5-pathtools needs to overwrite the older pathtools that come with > perl5.8 in order to be found (perl searches the vendor location last > by default, and the perl community consensus is that this is the > appropriate way to upgrade modules that ship with perl). > > To that end, p5-pathtools would have printed out: > > "You must install or activate this package with '-f' (force) as it > needs to overwrite files installed by the perl5.8 port" > > You can run `sudo port -f install p5-pathtools` and then try > installing firefox-x11 again and it should work. I did that, and it said: macpro$ sudo port -f install p5-pathtools ---> Installing p5-pathtools 3.25_0 Error: Target org.macports.install returned: Registry error: p5-pathtools @3.25_0 already registered as installed. Please uninstall it first. Error: Status 1 encountered during processing. So I now try "sudo port install firefox-x11" again. It aborts with ---> Staging p5-getopt-long into destroot You must install or activate this package with '-f' (force) as it needs to overwrite files installed by the perl5.8 port ---> Installing p5-getopt-long 2.37_0 ---> Activating p5-getopt-long 2.37_0 Error: Target org.macports.activate returned: Image error: /opt/local/lib/perl5/5.8.8/Getopt/Long.pm is being used by the active perl5.8 port. Please deactivate this port first, or use the -f flag to force the activation. Error: The following dependencies failed to build: gnome-icon-theme icon-naming-utils p5-getopt-long p5-xml-simple p5-test-simple p5-test-harness p5-xml-namespacesupport p5-xml-sax p5-xml-parser gnome-vfs dbus docbook-xml-4.1.2 xmlcatmgr libxml2 xmlto docbook-xml-4.2 docbook-xsl getopt libxslt dbus-glib gconf gtk2 atk gtk-doc scrollkeeper docbook-xml docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 jpeg pango Xft2 xorg-xproto xorg-util-macros tiff intltool orbit2 libidl gnome-mime-data howl neon openssl zip Error: Status 1 encountered during processing. I try to install firefox-x11 yet again, and yet again it fails in the same way, this time for p5-test-harness. Then p5-test-simple. After that it seems to proceed happily. But surely we're not supposed to have to do this by hand? -- Richard

3 2

Re: sudo port install xboard
by Ryan Schmidt 13 Dec '07

13 Dec '07

On Dec 12, 2007, at 21:11, Charles Darwin wrote: > On Dec 12, 2007, at 10:03 PM, Ryan Schmidt wrote: > >> On Dec 12, 2007, at 20:58, Charles Darwin wrote: >> >>> $uname -r;arch >>> 8.11.0 >>> ppc >>> $ sudo port install xboard >>> ---> Configuring xboard >>> Error: Target org.macports.configure returned: error copying "/ >>> usr/share/libtool/config.guess": no such file or directory >>> Error: Status 1 encountered during processing. >>> $ >> >> Why don't you have /usr/share/libtool/config.guess on your system? >> It should be there. >> >> We had one report of this before, for a different port I think >> (there are many that employ the technique of copying that file) >> but I don't think we ever found out why the user was missing that >> file. > > $ libtool -V > Apple Computer, Inc. version cctools-622.8 > $ port search libtool > libtool devel/libtool 1.5.24 GNU > Libtool - The GNU Portable Library Tool > $ > > The only libtool here http://www.opensource.apple.com/darwinsource/ > Current/ is the GNU one. > Should I install the GNU version? Nothing in MacPorts will install anything into /usr/share, so installing a port through MacPorts won't fix this problem. /usr/share/ libtool/config.guess is a file that, as far as I have been able to determine, is provided by Apple and should be on every Mac (or at least every Mac with Xcode, I'm not sure) and I don't know why it's not there on your system. Don't forget to Reply To All so that your message goes to the list too, not just to me.

3 7

Re: plans for 64bit support
by Ryan Schmidt 13 Dec '07

13 Dec '07

This discussion belongs on the mailing list, not in my private mailbox. Please use Reply To All when replying. On Dec 11, 2007, at 04:30, Keith J. Schultz wrote: > Am 11.12.2007 um 09:50 schrieb Ryan Schmidt: > >> On Dec 11, 2007, at 02:35, Daniel Oberhoff wrote: >> >>> Am 10.12.2007 um 01:33 schrieb Ryan Schmidt: >>> >>>> On Dec 9, 2007, at 14:43, Daniel Oberhoff wrote: >>>> >>>>> Now that Leopard is out and already at 10.5.1 will macports be >>>>> supporting 64bit libraries? It's just I need 64bit in my octave >>>>> installation. I pull my octave from octave.org's cvs, but it >>>>> needs quite a lot of support libraries. From what I gather it >>>>> should be possible on Leopard to build fat libraries, i.e. ones >>>>> that contain 64 and 32 bit code (i think it works using -arch >>>>> x84_64 -arch i686 as gcc flags). Or will this be left to the >>>>> separate ports? >>>> >>>> MacPorts is supposed to build libraries for whatever system it's >>>> running on. So I would have thought that if you're on a 64-bit >>>> Intel system, it should build 64-bit Intel libraries. Is it >>>> building 32-bit Intel libraries for you? >>>> >>>> We have the +universal variant for building 2-way (32-bit, Intel >>>> and PowerPC) universal binaries. We are still in the process of >>>> getting this to work with many of the ports. It could be changed >>>> to build 4-way (32-bit and 64-bit, Intel and PowerPC) universal >>>> binaries. This should be possible on Tiger too, as far as I >>>> know. It won't fix any ports that are having trouble building 2- >>>> way universal binaries. Not sure if it would mess up any ports >>>> that are already working. Are all the ports that you need >>>> already working as 2-way universal binaries? >>>> >>>> I haven't heard anyone suggest building libraries that contain >>>> 32-bit and 64-bit code for just one processor family before (in >>>> relation to MacPorts). It would of course be possible, but I >>>> think it would make most sense to continue along our current >>>> path: software should be default install for the architecture >>>> you're on, and if you need multiple architectures, then you need >>>> the +universal variant. >>>> >>>> It has been said before that maybe 64-bit binaries aren't all >>>> that helpful, but the Ars Technica review of Leopard explains >>>> that while 64-bit binaries aren't that helpful on the PowerPC >>>> architecture, they really are quite good for secondary reasons >>>> on the Intel architecture. The 32-bit Intel architecture has >>>> often been called inferior to the 32-bit PowerPC architecture, >>>> but the 64-bit Intel architecture seems to fix many of the >>>> issues. Also, maybe Leopard being a full 64-bit system makes 64- >>>> bit binaries more relevant. >>>> >>>> Perhaps we could do 4-way universal binaries only when MacPorts >>>> is running on Leopard.... but that might be a bad idea, since >>>> only people running Leopard could then develop and test this. >>>> >>>> We could introduce a new automatic variant... +universal4? >>>> +universal64? People could test with this new variant and if any >>>> problems are encountered it would not prevent anyone from using >>>> the existing 2-way 32-bit +universal variant. I'm wary of this >>>> though... I wouldn't want, say, "universal64" directives to >>>> start appearing in portfiles, if we want to eventually fold >>>> +universal64 into +universal. >>>> >>>> Just some thoughts off the top of my head. >>> >>> Hmm, ok. That makes sense, since I upgraded with an installed >>> macports base. I suppose I should really reinstall all then, >>> since otherwise I will end up with a crazy mix? >> >> Yes, if you're moving from one architecture to another (G4->G5, >> PPC->Intel, 32-bit->64-bit, etc.) you should really throw away >> your old MacPorts (saving any conf files or databases or other >> data) and rebuild all your ports. >> >>> Though, per default on Leopard compilation seems to be 32 bit. >>> When you just compile something without further options pointer >>> size is 32bit. Only when you specify -arch x86_64 or -m64 do you >>> get 64bit. >> >> Ah, I see. I didn't know. I haven't had a 64-bit machine. >> >>> So it would really make sense to have both (but not ppc). So I >>> would vote for an autamatic variant to get intel only 32/64bit. >> >> So by default we build 32-bit binaries for the host architecture. >> And we have a +universal variant for building 32-bit binaries for >> both architectures. You want an additional variant for building >> fat 32-bit and 64-bit Intel binaries. Do we then also need a >> separate variant for building fat 32-bit and 64-bit PowerPC >> binaries? And what about a fat universal variant with all 4 >> options? This proliferation of variants is what I want to avoid. >> Most users will not need it and it will confuse some of them. It's >> much extra work for some portfile authors, because some software >> (rather a lot, actually) does not build successful universal >> binaries using the simple tricks, and much more work is required >> to build universal. See for example the openssl port (which, to >> build universal, you'll have to back-date to version 0.9.8e >> because of bug #12911) which goes through crazy hoops to build >> first for one architecture, then the other, then lipo them >> together. Similar (though perhaps not identical) hoops would have >> to be gone through for fat binaries or 4-way binaries. Well, that >> is until MacPorts base grows some universal-build helpers. (I >> still really think MacPorts base should have an easy way to build >> a port multiple times, once for each architecture, and lipo it >> together, automatically, selected with just a single line in the >> portfile). >> >> >> Why, by the way, do you need 64-bit octave? Just curious. > > Hi Everybody, > > Why would someone with a Intel or PowerPC want to build a > universal for a port. > I mean it is build on one machine and is used on one machine. I > can understand > the variants for Intel and PowerPC as well as the need for 32 or > 64 bit variants, > but universal no way. > > Yes, a port author will want to test and build the different > variants, but why universal. > I mean ports does not need unversal variants on the pure unix > side. Cocoa Apps is a different > matter, but since they are build on the host machine we could do > with out it. So we have: > 1) Intel + 64 > 2) Intel + 32 > 3) PowerPC + 64 (G5 only) > 4) PowerPC + 32 > > I believe that which version to build can be guess by looking at > the CPU. Should not autoconfig > handle that? > > regards > Keith. I don't think now is the time to second-guess MacPorts's universal support, which has been around since r22313 10 months ago and is being improved on a port by port basis as problems are discovered. MacPorts's universal support is explained in the first item of the FAQ: http://trac.macports.org/projects/macports/wiki/FAQ#IsMacPortsUniversal True, most users do not need universal ports. But some do. Some install MacPorts on an external hard drive that they might connect to either a PowerPC- or an Intel-based Mac. Or some users may install MacPorts on their current PowerPC Mac, then later use Migration Assistant to migrate the content of their hard drive to a newly- bought Intel-based Mac. Users who have installed +universal versions of all ports can continue unhindered, while those who did not will have to blow away their MacPorts installation, reinstall MacPorts and re-build all their ports. A goal of MacPorts is to eventually distribute binaries of ports, rather than make everyone compile things themselves. It would be inconvenient to have to maintain separate PowerPC and Intel binaries, hence the desire to have universal binaries so we can have just a single binary download for each port. If and when that ever happens. Therefore, we certainly don't want to now increase the number of binary ways the software can be built, so we don't want separate ways to build fat Intel or fat PowerPC binaries. Rather, I would suggest, as I suggested before, that we should have the default, which builds for the local host architecture only, which most users today will use, and we should have +universal, as we do now, but which can be extended to support all 4 binary types that one might conceivably want, if indeed 64-bit binaries are useful to have. As far as I know, autoconf was conceived without having considered multiple-architecture binaries, so I don't know that it's going to be any help in building fat or universal binaries.

3 3

Re: sudo port install whois
by Ryan Schmidt 13 Dec '07

13 Dec '07

On Dec 12, 2007, at 21:06, Charles Darwin wrote: > On Dec 12, 2007, at 9:49 PM, Ryan Schmidt wrote: > >> On Dec 12, 2007, at 20:37, Charles Darwin wrote: >> >>> $ uname -r ;arch >>> 8.11.0 >>> ppc >>> $ sudo port install whois >>> ---> Fetching whois >>> ---> Attempting to fetch whois_4.7.23.tar.gz from http:// >>> ftp.debian.org/debian/pool/main/w/whois/ >>> ---> Attempting to fetch whois_4.7.23.tar.gz from http:// >>> svn.macports.org/repository/macports/distfiles/whois >>> ---> Attempting to fetch whois_4.7.23.tar.gz from http:// >>> svn.macports.org/repository/macports/distfiles/general/ >>> ---> Attempting to fetch whois_4.7.23.tar.gz from http:// >>> svn.macports.org/repository/macports/downloads/whois >>> Error: Target org.macports.fetch returned: fetch failed >>> Error: Status 1 encountered during processing. >>> $ >> >> Thanks for reporting this. I just fixed it. Wait 12 hours, then >> "sudo port selfupdate", then try again. >> >> Looks like they updated the software to 4.7.24 and removed the old >> version from their server (how rude). > > sudo port selfupdate or sudo port -d sync ? Either would be fine. Please keep replies on the mailing list. Thanks.

2 2

gimp/gail, Leopard on MacBook Pro
by Joseph C. Slater PE, PhD 13 Dec '07

13 Dec '07

I tried to install gimp on my MBP and got the following: gailtreeview.c:22:22: error: gdk/gdkx.h: No such file or directory gailtreeview.c: In function 'gail_tree_view_grab_cell_focus': gailtreeview.c:2231: warning: implicit declaration of function 'gdk_x11_get_server_time' make[2]: *** [gailtreeview.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error: Status 1 encountered during processing. Any thoughts on this? Is this working for others? Thanks, Joe \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ (+1) 937-775-5085 http://www.cs.wright.edu/~jslater http://www.cs.wright.edu/~jslater/JosephSlater.vcf.zip

2 1

Fwd: sudo port install xboard
by Charles Darwin 13 Dec '07

13 Dec '07

Begin forwarded message: > From: Paymon Marandi <pmarandy(a)gmail.com> > Date: December 13, 2007 9:48:18 AM EST (CA) > To: macports-users(a)lists.macosforge.org > Subject: sudo port install xboard > > > > Begin forwarded message: > >> From: Paymon Marandi <pmarandy(a)gmail.com> >> Date: December 13, 2007 9:47:01 AM EST (CA) >> To: macports-users(a)lists.macosforge.org >> Subject: Fwd: sudo port install xboard >> >> >> >> Begin forwarded message: >> >>> From: Charles Darwin <darwinskernel(a)gmail.com> >>> Date: December 13, 2007 9:46:32 AM EST (CA) >>> To: Ryan Schmidt <ryandesign(a)macports.org> >>> Subject: Re: sudo port install xboard >>> >>> xcode2.5 >>> $ uname -r;arch >>> 8.11.0 >>> ppc >>> >>> On Dec 13, 2007, at 8:25 AM, Ryan Schmidt wrote: >>> >>>> All of these errors you're now seeing (make not found, gcc not >>>> found, cc not found) point to a missing or improperly installed >>>> Xcode. These commands would all be provided by the Xcode >>>> installation. What version of Xcode did you install, nad what >>>> version of Mac OS X do you have again? >>>> >>>> On Dec 13, 2007, at 06:56, Charles Darwin wrote: >>>> >>>>> $ cd /opt/local/var/macports/build/ >>>>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_g >>>>> ames_xboard/work/xboard-4.2.6 >>>>> /opt/local/var/macports/build/ >>>>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_g >>>>> ames_xboard/work/xboard-4.2.6 $ make >>>>> make: Nothing to be done for `all'. >>>>> /opt/local/var/macports/build/ >>>>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_g >>>>> ames_xboard/work/xboard-4.2.6 $ sudo make clean >>>>> rm -f xboard zic2xpm *.o *.doc lex.yy.c >>>>> rm -f xboard_*.html xboard.aux* xboard.cp* xboard.dvi xboard.fn* >>>>> rm -f xboard.ky* xboard.log xboard.pg* xboard.toc xboard.tp* >>>>> rm -f xboard.vr* xboard.ps >>>>> :/opt/local/var/macports/build/ >>>>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_g >>>>> ames_xboard/work/xboard-4.2.6 $ sudo make >>>>> gcc -DHAVE_CONFIG_H -I. -I. -I/usr/X11R6/include -O2 -I/opt/ >>>>> local/include -no-cpp-precomp -I/usr/X11R6/include -DINFODIR= >>>>> \"/opt/local/share/info\" -c parser.c >>>>> make: gcc: Command not found >>>>> make: *** [parser.o] Error 127 >>>>> :/opt/local/var/macports/build/ >>>>> _opt_local_var_macports_sources_rsync.macports.org_release_ports_g >>>>> ames_xboard/work/xboard-4.2.6 $ >>>>> >>>>> >>>>> On Dec 12, 2007, at 10:17 PM, Andre-John Mas wrote: >>>>> >>>>>> >>>>>> On 12-Dec-07, at 22:13 , Ryan Schmidt wrote: >>>>>> >>>>>>> On Dec 12, 2007, at 21:11, Charles Darwin wrote: >>>>>>> >>>>>>> Nothing in MacPorts will install anything into /usr/share, so >>>>>>> installing a port through MacPorts won't fix this problem. / >>>>>>> usr/share/libtool/config.guess is a file that, as far as I >>>>>>> have been able to determine, is provided by Apple and should >>>>>>> be on every Mac (or at least every Mac with Xcode, I'm not >>>>>>> sure) and I don't know why it's not there on your system. >>>>>>> >>>>>> >>>>>> I think this is one of those cases where if in doubt install >>>>>> XCode again, and if you can install >>>>>> the latest version, even better :) >>> >> >

1 0

cdparanoia missing an option
by list_usr＠spacebox.net 13 Dec '07

13 Dec '07

I'm trying to use abcde to rip and encode some CDs but it's failing due to a command line option missing from cdparanoia. The "-d" option in cdparanoia is used to specify a device to rip from. It seems the macports code has removed this option from the original cdparanoia code but references to it have not been removed from other macports (or at least not from abcde.) Using the macports version, the -d option prints out usage information which is what causes abcde to fail. At least I assume that macports specifically removed the option - I downloaded the original cdparanoia code and the -d option is present. If this is the case, I really think the -d option should be left in but made a "placebo" option so its absence doesn't break other programs like abcde. Or maybe the -d option should just be left in - is there something in OS X that prevents cdparanoia from being able to select a different device from which to rip a disc?

1 0

sudo port install xboard
by Charles Darwin 13 Dec '07

13 Dec '07

$uname -r;arch 8.11.0 ppc $ sudo port install xboard ---> Configuring xboard Error: Target org.macports.configure returned: error copying "/usr/ share/libtool/config.guess": no such file or directory Error: Status 1 encountered during processing. $

2 3

First port installation fails
by Richard Tobin 13 Dec '07

13 Dec '07

I installed MacPorts-1.5.0.pkg, did a self-update, then did port install firefox-x11 After installing several ports, it aborted with: ---> Activating p5-pathtools 3.25_0 Error: Target org.macports.activate returned: Image error: /opt/local/lib/perl5/5.8.8/darwin-2level/auto/Cwd/Cwd.bs is being used by the active perl5.8 port. Please deactivate this port first, or use the -f flag to force the activation. Error: The following dependencies failed to build: gnome-icon-theme icon-naming-utils p5-getopt-long p5-pathtools p5-xml-simple p5-test-simple p5-test-harness p5-xml-namespacesupport p5-xml-sax p5-xml-parser gnome-vfs dbus docbook-xml-4.1.2 xmlcatmgr libxml2 xmlto docbook-xml-4.2 docbook-xsl getopt libxslt dbus-glib gconf gtk2 atk gtk-doc scrollkeeper docbook-xml docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 jpeg pango Xft2 xorg-xproto xorg-util-macros tiff intltool orbit2 libidl gnome-mime-data howl neon openssl zip Error: Status 1 encountered during processing. Presumably this should not happen. There was no /opt/local before I started, so it can't be some stale port. -- Richard

4 5

Re: sudo port install xboard
by Ryan Schmidt 13 Dec '07

13 Dec '07

On Dec 12, 2007, at 21:05, Charles Darwin wrote: > On Dec 12, 2007, at 10:03 PM, Ryan Schmidt wrote: > >> On Dec 12, 2007, at 20:58, Charles Darwin wrote: >> >>> $uname -r;arch >>> 8.11.0 >>> ppc >>> $ sudo port install xboard >>> ---> Configuring xboard >>> Error: Target org.macports.configure returned: error copying "/ >>> usr/share/libtool/config.guess": no such file or directory >>> Error: Status 1 encountered during processing. >>> $ >> >> Why don't you have /usr/share/libtool/config.guess on your system? >> It should be there. >> >> We had one report of this before, for a different port I think >> (there are many that employ the technique of copying that file) >> but I don't think we ever found out why the user was missing that >> file. > > where can I get one? It's provided by Apple, but I don't know whether it's part of the Mac OS X install or the Xcode install. Please keep replies on the mailing list. Thanks.

1 0