macport/ installing on OS X

[coke]

Need to update the portfile in our repo, test it, and update macports with the new version.

[coke]

Be sure to incoporate any changes (if necessary) made to the Portfile by the macports team:

 http://trac.macports.org/browser/trunk/dports/lang/parrot/Portfile

[coke]

macport is stalled, as I cannot install on OS X / intel for some time now. Errors with, e.g.:

/usr/bin/ld: Undefined symbols:
_u_charFromName_4_0 referenced from libparrot expected to be defined in /opt/local/lib/libicuuc.40.dylib
_u_isalnum_4_0 referenced from libparrot expected to be defined in /opt/local/lib/libicuuc.40.dylib

$ icu-config --version
4.2.1
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.4.11
BuildVersion:   8S2167

[coke]

Note that the build of installable_parrot is failing with:

{_u_charFromName_4_0 referenced from libparrot expected to be defined in /opt/local/lib/libicuuc.40.dylib}

but there is no /opt/local/lib/libicuuc.40.dylib, only

$ ls /opt/local/lib/libicuuc*
/opt/local/lib/libicuuc.42.1.dylib      /opt/local/lib/libicuuc.dylib
/opt/local/lib/libicuuc.42.dylib

(here's the failing build command:)

c++ -o installable_parrot \
    src/main.o src/install_config.o \
    -L/Users/coke/bird/lib -L/Users/coke/research/parrot/blib/lib -lparrot -lpth
read -lm   -L/opt/local/lib  -licuuc -licudata  -lpthread -lm    -lm -lgmp -lrea
dline -lintl -undefined dynamic_lookup -L/opt/local/lib
/usr/bin/ld: warning can't open dynamic library: /opt/local/lib/libicuuc.40.dyli
b referenced from: /Users/coke/bird/lib/libparrot.dylib (checking for undefined
symbols may be affected) (No such file or directory, errno = 2)
/usr/bin/ld: warning can't open dynamic library: /opt/local/lib/libicudata.40.dy
lib referenced from: /Users/coke/bird/lib/libparrot.dylib (checking for undefine
d symbols may be affected) (No such file or directory, errno = 2)

So why is installable parrot trying to open them? Apparently because there was a parrot 1.2.0 built against the 4.0 version of ICU, and this c++ command is picking up that dependency. If I move the ~/bird directory out of the way, the install works just fine.

So, this is YA variant on the "installed parrot conflicts with building parrot" problem.

[doughera]

Replying to coke:

Note that the build of installable_parrot is failing with: {_u_charFromName_4_0 referenced from libparrot expected to be defined in /opt/local/lib/libicuuc.40.dylib} but there is no /opt/local/lib/libicuuc.40.dylib, only

> $ ls /opt/local/lib/libicuuc*
> /opt/local/lib/libicuuc.42.1.dylib      /opt/local/lib/libicuuc.dylib
> /opt/local/lib/libicuuc.42.dylib

(here's the failing build command:)

> c++ -o installable_parrot \
>     src/main.o src/install_config.o \
>     -L/Users/coke/bird/lib -L/Users/coke/research/parrot/blib/lib -lparrot -lpth
> read -lm   -L/opt/local/lib  -licuuc -licudata  -lpthread -lm    -lm -lgmp -lrea
> dline -lintl -undefined dynamic_lookup -L/opt/local/lib

The problem is likely the -L/Users/coke/bird/lib near the beginning of the link command. I suspect that came from the invalid setting rpath='-L' currently in the hints file. If you edit config/init/hints/darwin.pm and change that to rpath='' it should remove that flag. Of course it might break something else earlier in the build. I don't know how Mac OS binaries are supposed to find shared libraries in non-standard locations.

I actually thought that Mac OS now supported -rpath (based on the links in TT #344), but I have no way of testing any of that myself. If it does, then copying the Linux setting of rpath = '-Wl,-rpath=' might work. If it doesn't, then somebody somewhere has to figure out the equivalent set of flags to tell the runtime loader where to find shared libraries.

So, this is YA variant on the "installed parrot conflicts with building parrot" problem.

Yes, it's TT #344 revisted.

[coke]

default compiler with OS X 10.4 doesn't support -rpath; the one with 10.5 does.

So, if the OS is >= 10.5, we should be able to use the rpath setting from the linux hints file, no problem. For 10.4, we need to have the install process use install_name_tool (as in previous versions of the macport). (We can probably just setup a specific Makefile target for this that we can invoke from the portfile.)

[doughera]

Replying to coke:

default compiler with OS X 10.4 doesn't support -rpath; the one with 10.5 does. So, if the OS is >= 10.5, we should be able to use the rpath setting from the linux hints file, no problem. For 10.4, we need to have the install process use install_name_tool (as in revious versions of the macport).

Ok. Makes sense. For OS < 10.5, the hints file should probably set rpath='' to avoid the problem you ran into here. (Incidentally, one of the motivations behind my 2nd rpath patch in TT #476 was to allow end users to work around bugs of this sort without patching parrot themselves or waiting for a new release, and to also make it easier for developers to experiment with different settings while trying to figure out what will work.)

[coke]

I'm pretty sure this ticket is no longer an issue - been installing on os x for some time with no problems now, and there's a 3.0.0 version of the macport just waiting for someone to approve it.