MacPorts: More Info

Resources

MacPorts can understood from a variety of resources. These include, ahead of some personal and compiled users list notes below:

Below are notes, and a distillation of extracts from the MacPorts users mailing list.

Architectures: PowerPC, Intel, endianness, bits and cores

Computers are manufactured using a variety of chips. Chip architectures vary in an attribute endianness, a property of memory storage. They also vary in other chip specifics, and in comprising single or multiple processor cores. Apple's Macintosh computers were manufactured with PowerPC chips from Motorola and now Intel chips with single or (now) multiple processor "cores".

The operating system will have been designed to support one or more (e.g. 32-bit, 64-bit) memory architectures, on one or more of these chips. In Terminal, you can find out
  • your processor bitness (this what matters to MacPorts) using the following, where "1" means 64-bit, "0" means 32-bit:
    sysctl hw.cpu64bit_capable
  • EFI bitness can be queried using the following, where EFI64 means "yes" and EFI32 means "no":
    ioreg -l -p IODeviceTree? | awk -F'"' '/firmware-abi/{print $4}'

Ports – software in the MacPorts context – may need to be compiled for one or more of the above architectures before they can run, often as dependents on other ports which need to have pre-compiled in a compatible way. Even then, the machine on which they are to operate would have to support the architecture(s). Copying ports precompiled to run on one architecture onto a different machine (or one with a changed operating system) may have delivered the ports into an environment which, by capacity or default or configuration, runs an incompatible architecture. It can be a very good reason why ports may not run properly, or even at all.

Ports can often be compiled into "universal" or "fat" (multi-architecture) build files, thereby enabling multi-architectural operation and/or linkage. More in MacPorts Guide for example build_arch and global variables.

On a multi-core computer, you can instruct MacPorts to build using a single core if a build would otherwise make the machine too slow for other tasks:
sudo port install portName build.jobs=1

Building "Universal", Universal 2-way and 4-way

As of MacPorts 1.8.0 and higher, the easiest way to install a port (say, portName) "universal" when some of its dependencies had not been installed as universal is as follows:

  1. Install portName non-universal:
    sudo port install portName
  2. Upgrade portName and any necessary dependencies to universal:
    sudo port upgrade --enforce-variants portName +universal

You can also reinstall all ports universal (at least, those which can) using:
sudo port selfupdate
sudo port sync
sudo port upgrade --enforce-variants installed +universal
which will only rebuild the ports that aren't already universal but which can be built universal. In regard to sudo ports upgrade --enforce-variants installed:
  • you can omit "+universal" if it's already in your variants.conf (see below)
  • it is preferable to add the modifier installed sudo port upgrade --force installed because using --force will instead rebuild all ports, including those that are already universal and those that cannot be built universal, both of which would just waste time.

To build universal without having to remember to add it to every port install command:
  1. Set universal_archs as desired in macports.conf.
  2. and add +universal in variants.conf
  3. noting that the automatic (default) building of a universal variant:
    • assumes configure-based programs, and is therefore circumventable by "use_configure no" in a portfile) – see macports ticket 12170
    • can also be circumvented by "universal_variant no" in a portfile
    • is orthogonal to portgroups (e.g. cmake, xcode) which provide their own universal variants

If you're on Intel, there's probably no need to build for PowerPC? and vice versa. On Snow Leopard there is a good reason to build 2-way universal for x86_64 and i386 because ports build 64-bit by default but some ports can only be built 32-bit so the only way to use both kinds in the same prefix is to install as many ports as possible 2-way universal. On Leopard, which builds 32-bit by default, it can still be advantageous to build 2-way x86_64 i386 universal because 64-bit software on Intel can be faster and can address more memory. There's probably no reason to build 4-way universal, and not all ports will support it; particularly ports using the muniversal portgroup often have trouble cross-compiling.

To identify the architectures within a multi-architecture file, use the =lipo -info $ lipo -info /usr/bin/make Architectures in the fat file: /usr/bin/make are: x86_64 i386

Some information is also gained from file -L fileName

Coherence lost across major OS or architecture changes

From: Ryan Schmidt <ryandesign@macports.org> Date: October 14, 2009 2:33:04 AM PDT To: Lenore Horner <LenoreHorner@sbcglobal.net> Cc: MacPorts Users <macports-users@lists.macosforge.org> Subject: Re: Snow Leopard ate my ports

On Oct 13, 2009, at 19:15, Lenore Horner wrote:

Whenever you make a major OS or architecture change (PowerPC? to Intel, 32-bit to 64-bit, one OS version to another) you must uninstall all ports and reinstall them. MacPorts will not detect these changes, and will assume all ports currently installed were installed with the current arch and OS version, which is obviously not correct if you go and change them. So please uninstall and reinstall all ports now.

Really naive question: The goal seems to be to have MacPorts use no OS libraries, however we seem to live in an awkward in-between state where MacPorts uses enough OS libraries to break with (at least) major OS upgrades but still requires a lot of stuff to be duplicated. Is it impossible for MacPorts to be entirely independent or is the restriction people time to fix/write stuff? If it's theoretically impossible, it seems like trying to use as few as possible puts us in a worst of both worlds of having to reinstall MacPorts and having to take the time and disk space to duplicate many OS things.

(Compile time is an issue for me. So is disk space since I need to keep my disk usage under 40GB so I have enough swap space.)

It is not a goal for a set of ports installed on one Mac / Mac OS X version to be usable on another Mac / Mac OS X version. It is a goal for MacPorts to be able to notice when you have moved from one Mac / Mac OS X version to another, and to offer to rebuild your ports for you. But that's probably far down the road.

As far as I'm concerned, compile time is not a major source of concern for us in general because computers are getting faster and faster, and disk usage is not a consideration because disks are getting bigger and bigger.

The FAQ explains why we like using our own libraries. It gives consistency across OS releases and lets us update things on our schedule instead of having it dictated to us by Apple. Take X11 for example. It was an exception to the rule before; we used to use Apple's X11. But in Tiger Apple's X11 was based on XFree86 and on Leopard it was based on X.org. They're different, and we encountered a lot of bugs -- first, bugs on Leopard from software that wasn't expecting X.org. Later, once Leopard had been out for awhile, bugs on Tiger from software that had been updated to work with X.org. Now that we have an X.org-based X11 in MacPorts and always use it, no more problems. Software builds the same on all OSes.

Ports are allowed to declare "platform" variants to do things on different OS versions, e.g. a "platform darwin 9" section to take effect only on Darwin 9 (a.k.a. Mac OS X 10.5 Leopard). MacPorts does not know whether these differences will result in the files on the hard drive being different. Perhaps for some port, the "platform darwin 9" section enables a feature only applicable to Leopard. If you move this installation over to Snow Leopard, you're now running a program with a feature enabled on an OS that feature doesn't work on.

Aside from what can be done in a portfile, the software itself might detect things about the OS and build itself differently as a result. For example, CoreText? was introduced in Leopard. If software is built on Tiger, it might detect CoreText? is not available and thus not use it, whereas if you were to build it on Leopard, it would use it. Or, a more modern example, Snow Leopard introduces OpenCL?, and something similar could happen there. In these examples, you would merely be missing useful functionality on the newer OS, but it goes both ways: APIs that used to exist get deprecated and removed. It happens all the time that ports that used to work on one OS don't work on the next.

Snow Leopard has the additional distinction of being the first Mac OS X version to build things 64-bit by default, instead of 32-bit as before. This isn't a matter of using or not using some system libraries. MacPorts adopts this default as well (because it is error prone not to do so) so anything you had installed from Leopard will be 32-bit but now that you're on Snow Leopard anything you build will be 64-bit. Try to build 64-bit software against 32-bit dependencies and you won't get very far. You must rebuild everything first.

Dependencies, Dependencies of dependencies, and Dependents

I am a little confused with this: $port dependents php5-mcrypt php5-mcrypt has no dependents!

But the Portfile shows: depends_lib-append port:libmcrypt port:libtool

Correct: php5-mcrypt has no dependents (ports that depend on php5-mcrypt) but it has dependencies (ports php5-mcrypt depends on). You can see the latter with: port deps php5-mcrypt … dependents and dependencies are different (opposite) things.

It is possible to list the hierarchical dependencies of a port, not just a port's immediate dependencies (i.e. to generate a list of the dependencies of dependencies) of a port, for example mcrypt. The port-rdeps script provides that list:

http://trac.macports.org/browser/contrib/port-rdeps/

Unfortunately nobody has yet created a port for that script, so it must be installed manually.

Here is example output of "port-rdeps -r php5-mcrypt":

Dependencies of php5-mcrypt: php5 gsed gettext libiconv gperf ncurses ncursesw expat libtool automake perl5 perl5.8 autoconf m4 help2man p5-locale-gettext libxml2 zlib bzip2 mhash pcre readline apache2 apr apr-util db46 sqlite3 openssl pkgconfig autoconf213 gawk libmcrypt

On 2010-02-01 04:49 , Harald Hanche-Olsen wrote: But then I come up with oddities like the following:

; port dependents p5-pathtools p5-pathtools has no dependents!

; port deps intltool Full Name: intltool @0.40.6 Build Dependencies: gnome-common Library Dependencies: expat, perl5, p5-xml-parser, p5-getopt-long, p5-pathtools, p5-scalar-list-utils

So intltool depends on p5-pathtools, but it is not among the dependents of p5-pathtools.

Is intltool really being installed at the moment? The dependents command only checks for ports which are installed at the moment. Check with 'port installed intltool'.

On my system, it is correct:

$ port installed p5-pathtools intltool The following ports are currently installed: intltool @0.40.6_0 (active) p5-pathtools @3.31_0 (active) $ port dependents p5-pathtools intltool depends on p5-pathtools

Patching files

This tip is not about creating patches, only to explain that the MacPorts guide section on Manually Applying Patches cannot always be used literally. In this example, there resided (for postgresql84) an uncommitted patch at http://trac.macports.org/ticket/21358. After downloading the three files by clicking on their adjacent download icons – not on the filenames since that displays them in markup – I moved them to a folder "patches" within my desktop folder. If I would then follow the guide precisely I would do, and get:
port cd $(port dir postgresql84)
patch -p0 < /Users/djb/Desktop/patches/Portfile.diff 
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- Portfile.orig   2009-09-13 09:11:36.000000000 +0200
|+++ Portfile   2009-09-13 18:12:53.000000000 +0200
--------------------------
File to patch: 

The problem is that nowhere in the downloaded Portfile.diff does it "know" (specify) on your drive the location of the portfile that is to be patched. You can scrounge around and find it manually and even drag and drop it from the Finder into the Terminal, or you can open an new Terminal tab (Command + T) in which to combine the find and grep commands to specify that we want to find, within the directory /opt (and all subdirectories) files of name"Portfile" but also to filter these to display only those lines containing the port name of interest, postgresql84:

find /opt -name Portfile | grep postgresql84
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql84/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql84-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql84-server/Portfile

Ah! There it is – the first one. So now we can just copy the text string /opt/local.../Portfile and into the original Terminal pane paste, in answer to "File to patch:"
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql84/Portfile

File to patch: /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql84/Portfile
patching file /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql84/Portfile

(this needs more work, as the patch files may in fact need to go into a .../files directory inside a port tree)

Portfile Phases Overview

MacPorts runs many more phases than the early Guide paragraph suggests. They are:

  • fetch
  • checksum
  • extract
  • patch
  • configure
  • build
  • test
  • destroot
  • deactivate (if this was an upgrade of an already installed port)
  • archive
  • install
  • activate

If your port defines distfiles, you must define their checksums.

All phases are run unless you either set something which causes them to be skipped (like clearing distfiles skips fetch, checksum, and extract) or by overriding the phase completely.

MacPorts will fetch the files, compare their checksums and, if they match, extract them. If there are patchfiles, MacPorts will fetch them if necessary and apply them. Unless you've told it not to, MacPorts will then run the configure script, run make, and run make install, which puts files into the destroot directory.

In the install phase, MacPorts copies things from the destroot directory to the install directory and records them in the registry. In the activate phase, MacPorts makes hardlinks from the install directory to the place where the files ultimately reside.

Note that (with a couple of important exceptions), installing files outside of ${prefix} (/opt/local by default) is very much frowned upon.

A port can override these phases if needed. No port should ever override the checksum, deactivate, install or activate phases. The
extract.suffix
statement value is used for fetch, checksum, and extract since it is usually appended to distname to build the full file name. Very few ports should have the need to override the fetch or extract phases (MacPorts includes code to handle all the common fetch and extract scenarios).

Ports commonly override the patch phase. They may eliminate the configure, build and destroot phases (which correspond to standard configure, make, and make install steps) and may override them as required by that particular piece of software however, where possible, ports should strive to not override any phases. Most ports should be able to conform.

To eliminate the configure phase, do not use "configure {}" about which port lint will complain. Instead, use the global section statement line
use_configure       no

To eliminate build, declaring
build {}
is the right way.

You want to setup your own destroot phase, and install the files in that step, to ${destroot}${prefix}/... so that port sees what files are considered to be part of the final install. See the mediawiki port for one example, which simply copies everything in destroot:

<http://trac.macports.org/browser/trunk/dports/www/mediawiki/Portfile>

The stuff installed into var/macports/software is what's called an image, which is the full (from destroot) set of the port's files. When a port is activated, the stuff in var/macports/software is then hardlinked into just ${prefix} (and removed when deactivated). Hence, if you properly do the destroot, installing the port will populate var/macports/software.

Depending on what's actually needed in someone's homedir, you may be able to either use ui_msg to tell the user what to do, or perhaps install a script with the port which does any necessary setup. Note that whatever that script would do would obviously not be part of the port itself. I do something similar to this (though into /usr instead of ~) with the cups-pdf port, which installs ${prefix}/libexec/cups-pdf_links.sh:

<http://trac.macports.org/browser/trunk/dports/print/cups-pdf/Portfile>=

active and inactive quartz variants, and symbols expected to be defined

From: Wolf Drechsel <drechsel@verkehrsplanung.com> Date: November 29, 2009 10:06:27 AM PST To: macports-users@lists.macosforge.org Subject: file: -lgdk-quartz-2.0 is not an object file (not allowed in a library)

thanks for the reply, Ryan guessed exactly what I did... I didnt see that there was a +quartz variant of gtk2 on my machine - so deactivating it and than compiling gtk2 did the job.  I get: Undefined symbols: _cairo_quartz_surface_create_for_cg_context referenced from libgdk-quartz-2 expected to be defined in libcairo

I can install the poppler +quartz variant, I deactivated the cairo +quartz variant before:

sudo port installed cairo Password: The following ports are currently installed:  cairo @1.8.8_0+macosx (active)  cairo @1.8.8_0+macosx+no_x11+quartz

Some hints would be appreciated.

If you build anything with the quartz variant, you should probably build everything with the quartz variant, and vice versa.

It looks like you originally built gtk2 with the quartz variant, but have now deactivated the cairo with the quartz variant and activated the cairo without the quartz variant. Therefore the quartz symbols gtk2 expects to be there now aren't. Reactivate the cairo with the quartz variant. Or, rebuild everything without the quartz variant if you've decided you don't want it anymore.

KDE, Koffice

From: Vlado Plaga <rechner@vlado-do.de> Date: November 4, 2009 11:40:24 AM PST To: macports-users@lists.macosforge.org Subject: Re: KOffice 2.1 RC1

Anyway, to me it seems like KDE in MacPorts is in quite a bad state. Maybe you should try Fink instead. I got a working digiKam 0.10 from Fink without hassles (apart from the endless compile time: expect more than a day, if your system still is a PowerPC?). Fink also seems to have a newer KOffice (no 2.1 yet, though). http://pdb.finkproject.org/pdb/package.php/koffice2-mac

I haven't used KOffice yet, LIbreOffice.org is ok for me.

Apple's builds on PowerPC? for multiple architectures 

From: Ryan Schmidt <ryandesign@macports.org> Date: October 22, 2009 6:25:00 PM PDT To: Bayard Bell <buffyg@mac.com> Cc: macports-users@lists.macosforge.org Subject: Re: include problem building BDB 4.6.21 w/ /usr/local

On Oct 22, 2009, at 19:07, Bayard Bell wrote:

Did a bit more digging. The problem looks to be with Apple's build of make. Extracted from "make -dp" output:

# default .INCLUDE_DIRS = /usr/include /usr/local/include /usr/include

Filing bug report now.

I guess they've fixed that already; this is what I get on Snow Leopard:

$ /usr/bin/make -dp | grep INCLUDE make: * No targets specified and no makefile found.  Stop. .INCLUDE_DIRS = /usr/include /usr/include

Again dtruss gives me a clue to put it together. Looking at the top of the output, there's some other sloppiness in how Apple is maintaining their make port:

# GNU Make 3.81 # Copyright (C) 2006  Free Software Foundation, Inc. # This is free software; see the source for copying conditions. # There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE.

# This program built for powerpc-apple-darwin9.0

Pretty sure it wasn't built for PPC, at least not PPC alone:

precious:Downloads bayard$ file -L /usr/bin/make /usr/bin/make: Mach-O universal binary with 2 architectures /usr/bin/make (for architecture i386):  Mach-O executable i386 /usr/bin/make (for architecture ppc7400):       Mach-O executable ppc

Doesn't look sloppy; looks like what is totally expected to happen if you build a program on PowerPC? for multiple architectures. The build machine was powerpc-apple-darwin9.0 and it was told to build for both -arch i386 and -arch ppc. It's the fault of the developers of make for assuming that printing the triple of the build machine in the version output would be useful for anything.

For comparison, on Snow Leopard, I get:

$ /usr/bin/make -v GNU Make 3.81 Copyright (C) 2006  Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This program built for i386-apple-darwin10.0

And of course it contains not only i386 but also x86_64 code.

$ lipo -info /usr/bin/make Architectures in the fat file: /usr/bin/make are: x86_64 i386

unrecognized command line option "-arch", C compiler cannot create executables, Error: Status 1 encountered during processing. 

From: "Frank J. R. Hanstick" <trog24@comcast.net> Date: October 17, 2009 3:09:28 PM PDT To: Ryan Schmidt <ryandesign@macports.org> Cc: MacPorts Users <macports-users@lists.macosforge.org> Subject: Re: gnustep-make failed to install

Hello, In the log is:

cc1
error: unrecognized command line option "-arch"

Attached is the log.

On Oct 17, 2009, at 1:20 PM, Ryan Schmidt wrote:

On Oct 17, 2009, at 05:31, Frank J. R. Hanstick wrote:

When trying to install gnustep, the following error occurred:


>  Building gcc42
>  Staging gcc42 into destroot
>  Installing gcc42 @4.2.4_1
>  Activating gcc42 @4.2.4_1
>  Cleaning gcc42
>  Fetching gnustep-make
>  Attempting to fetch gnustep-make-2.2.0.tar.gz from http://distfiles.macports.org/gnustep-make
>  Verifying checksum(s) for gnustep-make
>  Extracting gnustep-make
>  Configuring gnustep-make Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnustep_gnustep-make/work/gnustep-make-2.2.0" && ./configure --prefix=/opt/local/GNUstep CC=gcc-mp-4.2 --with-library-combo=gnu-gnu-gnu --with-objc-lib-flag=-lobjc-gnu --with-config-file=/opt/local/GNUstep/System/Library/GNUstep.conf " returned error 77 Command output: checking for gcc... gcc-mp-4.2 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details.

Error: The following dependencies failed to build: ArtResources? gnustep-core gnustep-back gnustep-gui gnustep-base gnustep-make libffi libxslt libxml2 gnutls libgcrypt libgpg-error libtasn1 lzo opencdk libungif libart_lgpl GMastermind GMines GNUMail Etoile SQLClient Performance oniguruma5 poppler gtk2 atk glib2 gtk-doc docbook-xml docbook-xml-4.1.2 xmlcatmgr docbook-xml-4.2 docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl gnome-doc-utils iso-codes p5-xml-parser py26-libxml2 python26 gdbm rarian getopt intltool gnome-common p5-getopt-long p5-pathtools p5-scalar-list-utils cairo libpixman jasper pango shared-mime-info xorg-libXcomposite xorg-compositeproto xorg-fixesproto xorg-libXfixes xorg-libXcursor xorg-libXdamage xorg-damageproto xorg-libXinerama xorg-xineramaproto openjpeg poppler-data Pantomime PRICE TalkSoup? netclasses Yap.app ImageMagick? p7zip a2ps psutils gworkspace system-preferences PreferencePanes? windowmaker giflib xpm Error: Status 1 encountered during processing.

I searched the bug data base and found #43915 which says the gnustep is not universal.  Does that mean that it will not install on a PPC even though gcc42 installed?

No, it means it will not install with the +universal variant, on any Mac, but should install without the +universal variant, on any may.

I am running MacOS? 10.5.8 on a PPC G4.

What does the config.log say? Can you attach it here?

Major OS / architecture upgrades

From: Ryan Schmidt <ryandesign@macports.org> Date: October 13, 2009 4:53:53 PM PDT To: Alexy Khrabrov <deliverable@gmail.com> Cc: MacPorts Users <macports-users@lists.macosforge.org> Subject: Re: Snow Leopard ate my ports

On Oct 13, 2009, at 14:26, Alexy Khrabrov wrote:

OK, for the Snow Leopard on top of Leopard case, I went back and did the following:

-- put back my old /opt/local -- ran the new 1.8.1 installer, which dropped the new port command and friends on top if it

Now port installed shows stuff, and they seemed to work as before.  In fact they did work, at least those I used, under SL, it's just the port command itself was broken by the upgrade, and now fixed by install-over.  My question is, do I really need to reinstall all ports, or this SL on top of L is OK?

It is not ok. You really do need to uninstall all ports and reinstall them, exactly as stated in the Migration page.

Last time, I migrated from 32-bit Leopard to 64-bit one (moving to a new MBP), and then I felt I had to do it, although 32-bit stuff still worked -- but there was a presumable advantage of getting thing recompiled under 64-bit gcc and stuff.  But are there any caveats why one should recompile a 64-bit Leopard-fathered ports setup after SL upgrade?

Whenever you make a major OS or architecture change (PowerPC? to Intel, 32-bit to 64-bit, one OS version to another) you must uninstall all ports and reinstall them. MacPorts will not detect these changes, and will assume all ports currently installed were installed with the current arch and OS version, which is obviously not correct if you go and change them. So please uninstall and reinstall all ports now.

build configure compiler variable OS Tiger Leopard Snow Leopard

From: Ryan Schmidt <ryandesign@macports.org> Date: October 7, 2009 5:36:11 AM PDT To: Michael Franz <mvfranz@gmail.com> Cc: Macports-users <macports-users@lists.macosforge.org> Subject: Re: Ticket #21500 - IcedTea? 1.11

On Oct 7, 2009, at 07:25, Michael Franz wrote:

On Tue, Oct 6, 2009 at 9:16 PM, Ryan Schmidt wrote:

gcc-4.0 is the default on Tiger and Leopard, and is available on Snow Leopard, so you could simply add this line to the portfile:

configure.compiler gcc-4.0

You should probably preface that with a comment explaining why:

# IcedTea? 1.11 doesn't compile with gcc-4.2 configure.compiler gcc-4.0

I have found that adding that does not work.  I also had to add build.args CC=gcc-4.0 CXX=g++-4.0 otherwise it still using gcc 4.2. Is this normal?

MacPorts passes these variables to the configure script, which is supposed to record those values and use them later. If IcedTea?'s configure script does not do this, then yes, you will have to pass them again, e.g. in the build.args or build.env. The proper way would be:

build.args CC=${configure.cc} CXX=${configure.cxx}

-- after setting configure.compiler as above.vailable when I started this process.  This should work on PowerPC? once Zero and Shark are integrated into the BSD port thus bringing JDK 7 to PowerPC? macs.

build rebuild upgrade set universal_archs --enforce-variants

From: Ryan Schmidt <ryandesign@macports.org> Date: October 1, 2009 1:50:30 PM PDT To: Scott Haneda <talklists@newgeo.com> Cc: "Patel, Viren" <vcpatel@emory.edu>, "macports-users@lists.macosforge.org" <macports-users@lists.macosforge.org> Subject: Re: Php 64 ... Was Re: Apache + php + gd not working at all - PARTIAL SUCCESS

What do you think about using this patch as opportunity to rebuild php5 in 64 bit mode on PPC dual G5? Do I have to change macports.conf to do so as per the previous suggestions to the list, or can I just ...upgrade +universal and get this one at 64 bit?

I build php5 x86_64/i386 universal on Snow Leopard and it seems to work. Hopefully that means it should work ppc64/ppc for you too. I don't have a 64-bit PowerPC? machine to test on.

If I want to go for it and update, can you tell me the commands to do so as 64 bit?  I assume to update now I just: sudo port selfupdate port info php5 php5 @5.3.0, Revision 3 That tells me that is the right one correct?

Yes.

So next would be the safe road: sudo port upgrade php5

Right, that would build using your build_arch from macports.conf, like it has before.

Or, the 64 bit maybe road: sudo port upgrade php5 +universal

Do I have my facts correct?

That would attempt to build the universal version. By default, universal_archs is ppc i386 so that's not what you want. To get 32-bit/64-bit universal builds, you would set universal_archs to ppc ppc64 in macports.conf first. Then, note that you will need all of php5's dependencies universal before you can build php5 itself universal. To do that, you could:

sudo port upgrade --enforce-variants php5 +universal

This will rebuild a whole lot of stuff.

build_arch added ≥ 1.8.0 compiler default precautions --force --enforce-variants

From: Ryan Schmidt <ryandesign@macports.org> Date: September 30, 2009 2:22:47 PM PDT To: Scott Haneda <talklists@newgeo.com> Cc: "macports-users@lists.macosforge.org Users" <macports-users@lists.macosforge.org> Subject: Re: build_arch

On Sep 30, 2009, at 14:28, Scott Haneda wrote:

On Sep 30, 2009, at 12:18 PM, Scott Haneda wrote:

I do not see build_arch in macports.conf

That option was added to macports.conf in 1.8.0. If you originally installed MacPorts before that version, your conf will not have that value. You can compare your macports.conf with the macports.conf.default in the same directory to see what other changes have occurred which you might want to merge into your conf file. MacPorts does not update your conf file for you.

I am trying to go all 64 on a PowerMac? Dual PPC G5

If I set universal_archs to ppc ppc64 does that means that default will build ppc, and a flag will tell it to be ppc64?

The compiler default build arch is ppc on PowerPC? Macs, with 10.4 and less, ppc7400 on PowerPC? Macs with 10.5, i386 on Intel Macs with 10.5 and less, and x86_64 on 10.6.

The build_arch setting in MacPorts defaults to ppc or i386 on 10.5 and less and x86_64 on 10.6.

You can change the build_arch setting, but if you want to build one port with a particular arch, all its library and runtime dependencies must have the same arch, and MacPorts does not check this for you. I just created the archcheck portgroup a few days ago, to alert users who try to install ports with one arch when their dependencies are not built with that arch, as a crutch to get us through this situation until MacPorts base does these checks, but individual ports would have to be updated to use the archcheck portgroup for this to be of any use. So far I have only updated a handful of my ports to do this, so you must be alert for this yourself.

I would like to default to ppc64,

You can set build_arch to ppc64. It would then probably be best to uninstall all ports and reinstall them. Note that not all ports support changing the build_arch. In particular all those specifying "use_configure no" will have to have their portfiles specially altered to allow this (just as they have to be specially altered to support a universal build).

if that does not work, how do I tell MP to go back to the usual way?

To go back, you would set build_arch back to ppc, and again uninstall and reinstall all ports.

Also, if I do not want to edit the conf file, is there a way for me to just hand pick which will get 64 bit?  Can I simply sudo port install php5 +universal?  Or are most ports not ready for that type of variant?

You can compile individual ports universal if you want. You could set universal_archs to ppc ppc64 to get 32-bit/64-bit PowerPC? builds. Again, any dependencies of the port you're installing that way need to be built the same way. ppc/ppc64 universal builds have never been the default for any version of MacPorts so you may encounter ports that don't work that way.

If I have php as a 32 bit now, and would like to just rebuild that one and maintain all my configs and settings, but have it be 64 bit, what is the procedure?

sudo port upgrade --enforce-variants php5 +universal

will rebuild php5 and all its dependencies with the universal variant. Set universal_archs first.

If instead of universal you really want only 64-bit, then you'll change build_conf and force a rebuild.

sudo port upgrade --force php5

From: Joshua Root <jmr@macports.org> Date: September 30, 2009 2:27:55 PM PDT

On 2009-10-1 05:18, Scott Haneda wrote: I do not see build_arch in macports.conf

It was added in 1.8.0, and we don't change pre-existing config files. You can diff against macports.conf.default to see what's new/changed.

I am trying to go all 64 on a PowerMac? Dual PPC G5

If I set universal_archs to ppc ppc64 does that means that default will build ppc, and a flag will tell it to be ppc64?

The usual behaviour will be to build for $build_arch, which defaults to ppc on all PowerPC? machines. If you select the universal variant (which not all ports have), then the port will be built for $universal_archs instead.

I would like to default to ppc64, if that does not work, how do I tell MP to go back to the usual way?

You should really only change build_arch when nothing is installed, since dependencies have to have the arch(s) used by their dependents. If you want to change it again later, you should uninstall all ports first (or at least all those that are not installed with +universal).

install failure missing dependency; reporting one's environment; X11

From: Ryan Schmidt <ryandesign@macports.org> Date: September 25, 2009 9:33:52 AM PDT To: Lars Sonchocky-Helldorf <lars.sonchocky-helldorf@hamburg.de> Cc: macports-users@lists.macosforge.org Subject: Re: xorg-libxkbui installation problem / general X11 question

when doing an 'sudo port -v upgrade outdated' I got a failure for xorg-libxkbui which I have attached:

my environment (a PowerBook? G4):

Lars-Sonchocky-Helldorfs-Computer:~ lars$ uname -a Darwin Lars-Sonchocky-Helldorfs-Computer.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc Lars-Sonchocky-Helldorfs-Computer:~ lars$ port version Version: 1.8.0

Thanks for letting us know. xorg-libxkbui was missing a dependency on xorg-libXt, which I have now added (in r58301). Please wait 30 minutes from the time of this message, then "sudo port sync" and try again.

What makes me wonder here is why macports tries to install X11/Xorg at all, given I already have installed X11.app from Apple. Is this the case because the X11.app from Apple is to old (I got version 1.1.3) or because it is incompatible or not detected? I'd rather use Apple's X11.app (because it works and I have no problems installing it) but if this is not sufficient please let me know.

MacPorts installs its own X11 libraries for the same reason it installs its own version of every other library: to avoid bugs in older versions included with Mac OS X, and to provide a consistent experience for MacPorts users across all versions of Mac OS X.

http://trac.macports.org/wiki/FAQ#ownlibs

X11 had previously been an exception to this rule because X11 in MacPorts had not been maintained and did not work. But now a lot of effort has been put in to make X11 in MacPorts work. For a time, we allowed users the option of using either the MacPorts X11 or the system's X11, but this caused a large number of problems so this option was removed.

You can continue to use Apple's X11.app in /Applications/Utilities to run software you install using MacPorts. However, the version of X11.app on Tiger is very old and contains many bugs which have since been fixed. So especially for Tiger, I recommend you install the ports xorg-server and quartz-wm and use X11.app in /Applications/MacPorts instead.

Note also that the X11 system Apple shipped in Tiger and earlier is based on XFree86 while the X11 system Apple ships in Leopard and later, and the one we now use in MacPorts, is based on X.Org. That's another reason to prefer the MacPorts version on Tiger -- to upgrade you to the same X11 the rest of the Mac world is using.

Preview what will be installed

What's the proper way to check for surprises like that beforehand? (I'm finding out by repeating port echo leaves, port info leaves, sudo port uninstall leaves, and making notes of what to reinstall later.)

"sudo port -y install" will do a dry-run and show what will be installed.

Also possible: "port echo rdepof:python26 and not installed" will list ports that are not already installed.

Python dependencies

http://trac.macports.org/wiki/FAQ#pydeps

also a thread July 1, 2010 Eliminating X dependency from python

2.

Temporary disable MacPorts?

From: Ryan Schmidt <ryandesign@macports.org> Date: January 19, 2010 12:33:15 PM PST To: Stacey <cardcaptorstacey@gmail.com> Subject: Re: Temporary disable MacPorts?

On Jan 19, 2010, at 14:23, Stacey wrote:

I need to temporary disable MacPorts but I don't know how to. I've tried searching but couldn't find anything. I'm trying to compile something in Fink but it seems like they are conflicting with each other. Also I need to know how to re-enable it after it's done smile

You can move MacPorts' directory aside. For example, if you're using the usual MacPorts /opt/local prefix, you could:

sudo mv /opt/local /opt/local-off

Do your thing in Fink, then later, bring MacPorts back:

sudo mv /opt/local-off /opt/local

Note that you should really do this anytime you want to use Fink. Similarly, anytime you use MacPorts, you should be moving Fink's /sw aside.

It is not supported (by MacPorts, anyway; not sure about Fink's policies) to have MacPorts and Fink installed at the same time, since they conflict, as you've noticed. It would probably be easier in the long run to pick either MacPorts or Fink, and remove the other.

Unneeded ports

MacPorts offers a script to help with getting rid of ports that are not needed. Install the port_cutleaves port and run port_cutleaves to be guided through a process of uninstalling unneeded ports.

User ~/.macports directory

From: Joshua Root <jmr@macports.org> Date: June 29, 2010 10:56:09 PM PDT To: Scott Haneda <talklists@newgeo.com> Cc: MacPorts Users <macports-users@lists.macosforge.org> Subject: Re: What is ~/.macports for

On 2010-6-30 15:39 , Scott Haneda wrote: Subject pretty much says it all, just curious, and could not locate it in the docs/wiki. Thanks

You can put a per-user macports.conf in there that will selectively override the settings in the global one. It's also used for work dirs when running with insufficient privileges to write to the normal location.

old versions obsolescence incompatible

From: Ryan Schmidt <ryandesign@macports.org> Date: January 18, 2010 6:22:59 PM PST To: Thomas De Contes <d.l.tDeContes@free.fr> Cc: MacPorts Users <macports-users@lists.macosforge.org> Subject: Re: versions of a port

Old versions of MacPorts and snapshots of the ports tree are available via http from <http://distfiles.macports.org/MacPorts/> or <http://svn.macports.org/repository/macports/downloads/>.

You can save yourself the trouble of setting up an rsync server. If all you want is to get the last ports tree that works with an OS version, you're only going to be checking it out once, so you can just copy that over to your older machine and set your sources.conf to point to that directory.

so, the ports won't stay compatible with 10.4 ? i'll have to get and keep them too ?

Ports are already beginning to become incompatible with 10.4. Port maintainers and upstream software developers are testing on Snow Leopard now, and sometimes still on Leopard, but on Tiger less often. 10.4-specific bugs and incompatibilities are thus more likely to slip in. Whether they can or do get fixed depends on maintainer or developer willingness.

If a future version of MacPorts base becomes incompatible with 10.4, yes, you should then stick with the last set of ports made at that time. Not only will later portfiles assume you are running a supported OS version, later portfiles will also likely use features only available in that later version of MacPorts, so you would otherwise start encountering errors about unknown commands.

I personally am in favor of retaining 10.4 support as long as possible, and at this point we have no concrete plans to stop 10.4 support in base. But there may come a day when a feature is added to base that doesn't work on 10.4 -- like the privilege escalation code that was added last year which made base incompatible with 10.3. Or we may follow our existing habits and make 10.4 unsupported as soon as 10.7 comes out.
Topic revision: 23 Jan 2014, KarstenHilbert
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark