gjs @1.38.1: dyld: Library not loaded: ../../../../../../../../../lib/libmozjs-17.0.dylib

[jwhowse4]

On an Intel Mac Pro running Mountain Lion 10.8.5 and XCode 5.0.2, after the recent mozjs17 update, my gjs build fails with the attached error log. Any help would be greatly appreciated.

[jwhowse4]

Error log for gjs build

[juanrgar (Juan R. García Blanco)]

I think I managed to reproduce the issue. Please find attach my failed build log.

If I'm right the install_name of libmozjs-17.0.dylib points to a wrong location. In your case it's apparently set to ../../../../../../../../../lib/libmozjs-17.0.dylib (in my case it's @executable_path/libmozjs-17.0.dylib). The mozjs17 Portfile has a post-patch phase that sets the install_name that's going to be used when generating the dylib. From your build log I'd say that when you build mozjs17, ${prefix} pointed to ../../../../../../../../../

I'm not sure of this, and I don't know why ${prefix} could possibly point to that location. Maybe the fact that your macports tree is under /Volumes/ (possibly on an external unit) has something to do with this. Anyways, could you please paste here the output of otool -D PATH_TO_LIBMOZJS17/libmozjs-17.0.dylib? Could you please also comment on where is your macports tree located, and where is your system installation?

To check if I'm right and this is an install_name issue, you could change the install_name of your installed libmozjs-17.0.dylib manually, using install_name_tool -id PATH_TO_LIBMOZJS17/libmozjs-17.0.dylib PATH_TO_LIBMOZJS17/libmozjs-17.0.dylib

[juanrgar (Juan R. García Blanco)]

My attempt to reproduce the issue

[jeremyhu (Jeremy Huddleston Sequoia)]

FWIW, thinks look right here, but I'll take a look when I get some cycles

~ $ otool -L  /opt/local/lib/libmozjs-17.0.dylib
/opt/local/lib/libmozjs-17.0.dylib:
	/opt/local/lib/libmozjs-17.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
	/System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling (compatibility version 1.0.0, current version 10.0.0)
	/opt/local/lib/nspr/libplds4.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/nspr/libplc4.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/nspr/libnspr4.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
	/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)

~ $ otool -L /opt/local/lib/libgjs.dylib 
/opt/local/lib/libgjs.dylib:
	/opt/local/lib/libgjs.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libreadline.6.2.dylib (compatibility version 6.0.0, current version 6.2.0)
	/opt/local/lib/libcairo-gobject.2.dylib (compatibility version 11203.0.0, current version 11203.16.0)
	/opt/local/lib/libcairo.2.dylib (compatibility version 11203.0.0, current version 11203.16.0)
	/opt/local/lib/libgirepository-1.0.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.1.0)
	/opt/local/lib/libgmodule-2.0.0.dylib (compatibility version 3801.0.0, current version 3801.2.0)
	/opt/local/lib/libgthread-2.0.0.dylib (compatibility version 3801.0.0, current version 3801.2.0)
	/opt/local/lib/libgio-2.0.0.dylib (compatibility version 3801.0.0, current version 3801.2.0)
	/opt/local/lib/libgobject-2.0.0.dylib (compatibility version 3801.0.0, current version 3801.2.0)
	/opt/local/lib/libglib-2.0.0.dylib (compatibility version 3801.0.0, current version 3801.2.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0)
	/opt/local/lib/libmozjs-17.0.dylib (compatibility version 1.0.0, current version 1.0.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)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)

[jwhowse4]

Replying to juanrgar@…:

I think I managed to reproduce the issue. Please find attach my failed build log.

If I'm right the install_name of libmozjs-17.0.dylib points to a wrong location. In your case it's apparently set to ../../../../../../../../../lib/libmozjs-17.0.dylib (in my case it's @executable_path/libmozjs-17.0.dylib). The mozjs17 Portfile has a post-patch phase that sets the install_name that's going to be used when generating the dylib. From your build log I'd say that when you build mozjs17, ${prefix} pointed to ../../../../../../../../../

I'm not sure of this, and I don't know why ${prefix} could possibly point to that location. Maybe the fact that your macports tree is under /Volumes/ (possibly on an external unit) has something to do with this. Anyways, could you please paste here the output of otool -D PATH_TO_LIBMOZJS17/libmozjs-17.0.dylib? Could you please also comment on where is your macports tree located, and where is your system installation?

To check if I'm right and this is an install_name issue, you could change the install_name of your installed libmozjs-17.0.dylib manually, using install_name_tool -id PATH_TO_LIBMOZJS17/libmozjs-17.0.dylib PATH_TO_LIBMOZJS17/libmozjs-17.0.dylib

The result of your requested otool command.

otool -D /Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib 
/Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib:
../../../../../../../../../lib/libmozjs-17.0.dylib

My system is installed on an internal drive mounted as /. My macports is installed on a different internal drive mounted as /Volumes/User_Disk. The full path to my macports installation is /Volumes/User_Disk/opt/macports. This path is defined as 'prefix' in the file macports.conf.

I checked several other random dynamic libraries in /Volumes/User_Disk/opt/macports/lib using the command otool -D and all of them point to the correct directory. So whatever is going wrong seems to be unique to libmozjs.

Strangely there is a file called libmozjs185.1.0.dylib in the macports library directory.

otool -D /Volumes/User_Disk/opt/macports/lib/libmozjs185.1.0.dylib
/Volumes/User_Disk/opt/macports/lib/libmozjs185.1.0.dylib:
/Volumes/User_Disk/opt/macports/lib/libmozjs185.1.0.dylib

I am not sure whether this is a previous copy of libmozjs which was for some reason not removed when the package was upgraded or a library for another package.

After running the install_name_tool command

install_name_tool -id /Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib  /Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib
otool -D /Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib
/Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib:
/Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib

the package gjs builds properly.

If you need anything else, please let me know.

[juanrgar (Juan R. García Blanco)]

Thank you all for your feedback.

mozjs17 is a different port, gjs@1.38.1 is the first version of gjs that depends on it. Therefore, libmozjs185 is installed because spidermonkey wasn't removed during gjs upgrade. I didn't think of this until now. I don't know if this can be done at all, i.e. try to remove spidermonkey when upgrading to gjs@1.38.1.

Regarding the install_name issue it seems that my guess was correct. Now I need to figure out why ${prefix} was poinring to that extrange location during mozjs17 installation. It seems to be related to using an external drive. I'll try to come up wirh a universal solution, then I'll ask you to rry it :)

[juanrgar (Juan R. García Blanco)]

I just realised that the issue could be caused by OS X ld when it sets the install_name for the just build dylib; now I see this more feasible indeed than ${prefix} being a relative path. I need to investigate this deeper.

[juanrgar (Juan R. García Blanco)]

I've come up with a different solution that defers install_name fix until destroot phase. I've checked that setting the install_name of a dylib to point to a location on a different devices works ok, i.e. the absolute path is taken. I hope this helps. Attached there is a patch over the current Portfile, and also the updated Portfile in case jwhowse or somebody else that has installed the macports tree in a different device wants to give this a try.

[juanrgar (Juan R. García Blanco)]

diff with current Portfile

[jeremyhu (Jeremy Huddleston Sequoia)]

I'm curious why the existing is not working for you. Can you please attach the failing build log (that is the mozjs17 build log, not the gjs build log), so I can see how the linker is being called.

[jwhowse4]

Replying to jeremyhu@…:

I'm curious why the existing is not working for you. Can you please attach the failing build log (that is the mozjs17 build log, not the gjs build log), so I can see how the linker is being called.

The mozjs17 build does not fail for me, it is the gjs build which fails. My understanding is that the gjs build fails because the library libmozjs-17.0.dylib created by mozjs17 thinks it is installed in ../../../../../../../../../lib when it is actually installed in /Volumes/User_Disk/opt/macports/lib. So in short I do not have a failing build log (or in fact any build log) for mozjs17.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jwhowse4@…:

Replying to jeremyhu@…:

I'm curious why the existing is not working for you. Can you please attach the failing build log (that is the mozjs17 build log, not the gjs build log), so I can see how the linker is being called.

The mozjs17 build does not fail for me, it is the gjs build which fails. My understanding is that the gjs build fails because the library libmozjs-17.0.dylib created by mozjs17 thinks it is installed in ../../../../../../../../../lib when it is actually installed in /Volumes/User_Disk/opt/macports/lib. So in short I do not have a failing build log (or in fact any build log) for mozjs17.

Yes, thus mozjs17 failed to build correctly. You didn't get an error about it until gjs failed because of mozjs17 failing silently. Please add the mozjs17 build log. You can recreate it via:

sudo port -v -f uninstall mozjs17
sudo port -v -s -k install mozjs17

The -k will cause it to not be cleaned upon install.

[jwhowse4]

Replying to jeremyhu@…:

Replying to jwhowse4@…:

Replying to jeremyhu@…:

I'm curious why the existing is not working for you. Can you please attach the failing build log (that is the mozjs17 build log, not the gjs build log), so I can see how the linker is being called.

The mozjs17 build does not fail for me, it is the gjs build which fails. My understanding is that the gjs build fails because the library libmozjs-17.0.dylib created by mozjs17 thinks it is installed in ../../../../../../../../../lib when it is actually installed in /Volumes/User_Disk/opt/macports/lib. So in short I do not have a failing build log (or in fact any build log) for mozjs17.

Yes, thus mozjs17 failed to build correctly. You didn't get an error about it until gjs failed because of mozjs17 failing silently. Please add the mozjs17 build log. You can recreate it via:

sudo port -v -f uninstall mozjs17
sudo port -v -s -k install mozjs17

The -k will cause it to not be cleaned upon install.

My apologies for the confusion, your use of the phrase "failing build log" confused me. In any event, attached is the build log for mozjs17. I believe it will be unhelpful, since for some reason the following is now the case.

otool -D /Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib
/Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib:
/Volumes/User_Disk/opt/macports/lib/libmozjs-17.0.dylib

I have no idea why the library now thinks it is installed in the correct location, unless the mozjs17 Portfile has been changed since my last build. The only other possibility that occurs to me is that I had the package spidermonkey185 installed when I did the previous build of mozjs17, and I uninstalled it before performing this build.

With this thought in mind I uninstalled mozjs17, installed spidermonkey185 and then installed mozjs17. The resulting log file is identical except for the time and the result of 'otool -D' is the same. So I am afraid the mystery remains.

[jwhowse4]

mozjs17 build log

[juanrgar (Juan R. García Blanco)]

The good part is that now it builds ok for you. The Portfile received recently changes to support universal build, so this shouldn't affect you.

[cooljeanius (Eric Gallager)]

Cc Me!

[juanrgar@…]

Could this be closed?

[mascguy (Christopher Nielsen)]

Thanks to some great work by Evan Miller, all of this has been fixed. And gjs and friends have also been updated.