Ticket #344 (closed bug: fixed)

Opened 6 years ago

Last modified 4 years ago

Can't create working installed parrot for macports

Reported by: coke Owned by: jkeenan
Priority: major Milestone: 1.1
Component: install Version:
Severity: medium Keywords:
Cc: Language:
Patch status: applied Platform: mac

Description

As 0.9.1 is due shortly, I'm trying to create a macport for 0.9.0

Using the port file template in r36803, parrot builds, and installs, but fails at runtime due to a linking problem.

$ which parrot
/opt/local/bin/parrot
$ ls -l /opt/local/bin/parrot
lrwxr-xr-x   1 root  admin  32 Feb 16 18:10 /opt/local/bin/parrot -> /opt/local/lib/parrot/bin/parrot
$ parrot -h
dyld: Library not loaded: /opt/local/var/macports/build/_Users_coke_research_macports_lang_parrot/work/parrot-0.9.0/blib/lib/libparrot.dylib
  Referenced from: /opt/local/bin/parrot
  Reason: image not found
Trace/BPT trap
$ otool -arch all -L /opt/local/bin/parrot
/opt/local/bin/parrot:
        /opt/local/var/macports/build/_Users_coke_research_macports_lang_parrot/work/parrot-0.9.0/blib/lib/libparrot.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11)
        /opt/local/lib/libicuuc.40.dylib (compatibility version 40.0.0, current version 40.0.0)
        /opt/local/lib/libicudata.40.dylib (compatibility version 40.0.0, current version 40.0.0)
        /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.4.0)
        /opt/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0)
        /opt/local/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
        /opt/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

So the installed version is built with a dependancy on the build directory.

If, when I install the port, I keep the build directory around (and then parrot runs, but only because the dynlib is in the build directory still) I see that the otool output for the 'parrot' and 'intallable_parrot' in the work build directory are identical.

Any suggestions?

Change History

  Changed 6 years ago by coke

perhaps we can leverage the rpath work for linux; Looks like it's defined for a few platforms, but not darwin.

If this is right:  http://www.codeshorts.ca/2007/nov/01/leopard-linking-making-relocatable-libraries-movin ; then it looks like we should be able to use -rpath on this platform.

  Changed 6 years ago by doughera

If changing rpath to "-Wl,-rpath=" in config/init/hints/darwin.pm (and then doing a full make distclean, perl Configure.pl run) doesn't fix it, then perhaps it would make sense to simply give up for now on making a shared libparrot for darwin. It's not ideal, but it ought to at least work.

  Changed 6 years ago by coke

It ought to, but it doesn't. =-)

Unfortunately, you can't make a static parrot on darwin (last time I was able to was for the 0.5.2 macport)

 http://rt.perl.org/rt3/Ticket/Display.html?id=53494

#53494: [BUG] --parrot_is_shared=0 IS shared?

  Changed 6 years ago by allison

Yes, the codeshorts.ca post is the correct fix. Given that 1.0.0 is so close, this may have to go in as a patch in the MacPorts package for 1.0, but can be added to trunk in 1.1.

  Changed 5 years ago by coke

  • status changed from new to closed
  • resolution set to fixed

Fix suggested in  http://trac.macports.org/ticket/18917 ; instead of using rpath ahead of time to create the installables properly, install them with the existing (wrong) paths and then use "install_name_tool" to fixup the installed binaries.

Tested, created a portfile for 1.0 that works based on that hint (thanks to jdfrens++ for the patch!); committed portfile to parrot; waiting for a commit to the macports repo, which should come in a day or so.

Resolving ticket.

  Changed 4 years ago by JadeNB

  • status changed from closed to reopened
  • resolution fixed deleted

This issue still occurs for me with Rakudo Star (built from source, not via Macports) on Mac OS 10.5.8; I build it and install it, but then cannot remove the build directory.

  Changed 4 years ago by tommyd

I'm currently trying to get Rakudo work on MP as well and also working on a MacPort for it. Being late to the game I wonder why we cannot simply hard-code the given --prefix instead of the build path in config/init/hints/darwin.pm? After all at least MacPorts installations are not meant to be relocatable, so all the complex path fiddling is not needed there anyways.

On the long run a proper fix might be nice though, e.g. when parrot gets bundled in a Quartz / GUI app and is not installed into a default location, but underkness Bundle.app/Contents/Libraries/, that would surely make the life of the app developer / packager easier then.

  Changed 4 years ago by coke

  • owner set to coke
  • status changed from reopened to new

  Changed 4 years ago by tommyd

To further explain what I think is the root issue: While the install name target is fixed on the actual parrot binaries, parrot_config, which is used by 3rd party tools like rakudo, still contains the wrong paths and this can unfortunately not easily be fixed e.g. in a rakudo port without a lot of hacks to query the currently active parrot installation. The following variables from parrot_config are affected:

$ parrot_config --dump | grep MacPorts
libparrot_linkflags => '-L/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib -lparrot'
rpath_blib => '-L/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib'
ldflags => '-L/opt/local/lib -L/usr/local/lib -L/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib'
libparrot_soname => '-install_name /opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib/libparrot.dylib'
build_dir => '/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0'

follow-up: ↓ 11   Changed 4 years ago by doughera

On Mon, 2 Aug 2010, Parrot wrote:

> #344: Can't create working installed parrot for macports

> Comment(by tommyd):
> 
>  To further explain what I think is the root issue: While the install name
>  target is fixed on the actual parrot binaries, `parrot_config`, which is
>  used by 3rd party tools like rakudo, still contains the wrong paths and
>  this can unfortunately not easily be fixed e.g. in a rakudo port without a
>  lot of hacks to query the currently active parrot installation. The
>  following variables from parrot_config are affected:
> 
>  {{{
>  $ parrot_config --dump | grep MacPorts
>  libparrot_linkflags =>
>  '-L/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib
>  -lparrot'

That one is irrelevant, since it's only supposed to be used within the 
parrot build directory.  The correct version to use with an installed 
parrot is inst_libparrot_linkflags.

>  rpath_blib =>
>  '-L/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib'

That one is also irrelevant, since it's only supposed to be used within the 
parrot build directory.  The correct version to use with an installed 
parrot is rpath_lib.

>  ldflags => '-L/opt/local/lib -L/usr/local/lib
>  -L/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib'

That one indeed looks wrong, but it probably doesn't matter, since I
don't think it should end up getting used in any important way.

>  libparrot_soname => '-install_name
>  /opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib/libparrot.dylib'

I don't what this is actually used for, so I don't know if it's a
problem or not.

>  build_dir =>
>  '/opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0'

This one is not a problem.   It simply records the build directory.
It shouldn't be used.

In short, there may well be problems, but it would be helpful if you
could be more specific about exactly what variable or variables are
causing a problem, so that we can help determine if the variable is
supplying the wrong information, or if rakudo is using the wrong
variables.

-- 
    Andy Dougherty		doughera@lafayette.edu

in reply to: ↑ 10   Changed 4 years ago by tommyd

Replying to doughera:

On Mon, 2 Aug 2010, Parrot wrote:

libparrot_soname => '-install_name /opt/local/var/macports/build/_Users_tommyd_Entwicklung_MacPorts_dports_lang_parrot/work/parrot-2.6.0/blib/lib/libparrot.dylib'

I don't what this is actually used for, so I don't know if it's a problem or not.

ld(1) states:

     -install_name name
                 Sets an internal "install path" (LC_ID_DYLIB) in a dynamic library. Any clients
                 linked against the library will record that path as the way dyld should locate this
                 library.  If this option is not specified, then the -o path will be used.  This
                 option is also called -dylib_install_name for compatibility.

All created binaries which link to libparrot.dylib record currently the wrong lib (build) path and therefor fail to execute once they're installed as the library loader of osx can't find the library under the old (temporary) build path anymore. Ideally, libparrot_soname should be something like "-install_name $PREFIX/lib/libparrot.dylib", where $PREFIX is replaced by the value of --prefix on installation time.

Note that this is not only a problem of rakudo, but of all supplied parrot binaries as well.

  Changed 4 years ago by jkeenan

  • platform set to mac

  Changed 4 years ago by coke

  • owner coke deleted

  Changed 4 years ago by coke

This is still an issue on 50c6137 with a standard build on OSX - "make install" generates binaries that need the build dir in place.

  Changed 4 years ago by jkeenan

Please see related problem in TT #1890. Please try out the  patch attached to that ticket.

Thank you very much.

kid51

  Changed 4 years ago by coke

This patch fixes the issue of the installed parrot pointing at the build directory for me - +1 on applying it.

  Changed 4 years ago by jkeenan

  • status changed from new to assigned
  • owner set to jkeenan

  Changed 4 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to fixed
  • patch set to applied

Patch applied in TT #1890 should fix:

[master 3f4a9c6] On Darwin, use installed dir, not build dir, for libparrot_soname.

Closing.

Note: See TracTickets for help on using tickets.