Closed Bug 738790 Opened 8 years ago Closed 8 years ago

error "Library not loaded: @executable_path/libmozglue.dylib" in Moz 11.0 from inside standard app bundle as advertised on mdc

Categories

(Toolkit Graveyard :: XULRunner, defect)

11 Branch
x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla14

People

(Reporter: passfree, Assigned: mossop)

References

Details

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1068.1 Safari/536.3

Steps to reproduce:

In version before 11.0 I was able to create the following app bundle. 

Contents/ 
  MacOS/ 
    xulrunner 
  Frameworks 
    XUL.framework
  ...
  ...
  ...

The procedures are advertised on MDC: https://developer.mozilla.org/en/XULRunner/Deploying_XULRunner_1.8. These notes relate to 1.8 but the process hasn't changed at all since 1.2 even before that. In fact they are working fine for the 10.0 branch.

Now with 11.0 I get an error "dyld: Library not loaded: @executable_path/libmozglue.dylib". This error is understandable when analysing the binaries.

I found a way around this by instead of copying the xulrunner binary into MacOS folder I just create a symlink. This works perfectly fine. However, I also want to sign the bundle with codesign. Unfortunately codesign will resolve the symlink and copy the physical binary resulting in the same stupid situation. That being said the change that has been made in 11.0 is simply not compatible with the way most things work under os x. Copying all files under MacOS (framework + app), which is the way Firefox ships on Mac OS X, also doesn't work with the distributable xulrunner binaries.
Are you sure you're copying the correct xulrunner binary (xulrunner, not xulrunner-bin is the one you want)?

What does the output of "otool -L xulrunner" look like?
Component: General → XULRunner
Product: Core → Toolkit
QA Contact: general → xulrunner
Indeed. This is what I am using. It is working just fine up until version 8.0.1. 9 and above are broken. 

Here is what 9 looks like:

	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
	/System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling (compatibility version 1.0.0, current version 10.0.0)
	@executable_path/libmozutils.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.6.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook (compatibility version 1.0.0, current version 862.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)

Compared to 8.0.1:

	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
	/System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling (compatibility version 1.0.0, current version 10.0.0)
	/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.6.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook (compatibility version 1.0.0, current version 862.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)
Yeah I'd expect it to be broken and look like that in 9 but it should have been fixed in 11. What does the otool command look like for the binary from XULRunner 11 that you're seeing the issue with?
Aren't you supposed to use xulrunner-stub instead of xulrunner?
Dava, I see.

otool shows:

runner:
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
	/System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling (compatibility version 1.0.0, current version 10.0.0)
	/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.6.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
	/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook (compatibility version 1.0.0, current version 862.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)

In 11.0 you get the following after executing:

XPCOMGlueLoad error 4:0 for file /Users/user/path/to/my.app/Contents/Frameworks/XUL.framework/libxpcom.dylib:
Library not loaded: @executable_path/libmozglue.dylib
  Referenced from: /Users/user/path/to/my.app/Contents/Frameworks/XUL.framework/libxpcom.dylib
  Reason: image not found
Couldn't load XPCOM.

This looks like crash but I should have been more careful with the observations next time. It is not crash.

$ otool -L libxpcom.dylib
libxpcom.dylib:
	@executable_path/libxpcom.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
	/System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling (compatibility version 1.0.0, current version 10.0.0)
	@executable_path/libmozglue.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/XUL (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libplds4.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libplc4.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libnspr4.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libmozalloc.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
btw, I am using the redistributable binaries from http://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/11.0/runtimes/
(In reply to Mike Hommey [:glandium] from comment #4)
> Aren't you supposed to use xulrunner-stub instead of xulrunner?

xulrunner is the stub on OSX
Getting kinda stumped here. This definitely broke between 8.0 and 9.0. The problem stems from the XULRunner dylibs using @executable_path to reference the shared libraries when the stub executable loading the libraries is in a different directory.

The correct solution is probably to do bug 578751 just for the main libraries but I don't think there is a straightforward way to do that.

However in 8.0 the linking seems to be just the same so I don't know how it worked, I'd guess that the stub was loading libxpcom.dylib differently somehow but using an 8.0 stub with a 9.0 XUL.framework shows the same issue so I'm a bit confused at this point.
There are several differences... at least from binary point of view... between 8 and 11.

The first major difference is that libmozglue.dylib does not exist in 8 at all. It was introduced after 8. The second difference is that now libmozglue.dylib is used everywhere. The libraries which make use of libmozglue.dylib are:

libmozalloc.dylib
libplugin_child_interpose.dylib
libxpcom.dylib

Some of the other executable that come with xulrunner also make use of the library.

The last difference, although I am not sure if it is of concern, is that libplugin_child_interpose.dylib also now links to CoreServices.framework and CoreFoundation.framework. This is probably insignificant but I thought I may as well mention it.

The problem from the stack trace is that when libxpcom.dylib is loaded it will try to link to libmozglue.dylib but from the @executable_path. The executable path in this instance is Contents/MacOS/xulrunner. Obviously the libmozglue.dylib is nowhere to be found in this folder. But if you make a symbolic link to the xulrunner binary from the XUL.framework, then everything will work fine because the link will be resolved and therefore the dependencies satisfied.

Now, the question is how to fix this. The easy fix is to copy libmozglue.dylib into the Contents/MacOS/ folder next to the xulrunner binary. This will work although I find this quite dirty thing to do and I am not sure if it will have other side-effects. Please someone advise.

Another way to solve this is to instead of linking to libmozglue.dylib at compile time, to load it dynamically at runtime. This however will require some code change.

Now, bug 578751 does propose the usage of @loader_path but I think this is the wrong way forward. Although I haven't tested this with the mozilla code base the correct form is to use @rpath instead. @rpath is supported from 10.5 and up and it should be considered safe. I don't think that Firefox is not supporting 10.4 these days anyway.

Out of all options, @executable_path, @loader_path and @rpath, the last one is most flexible.

However, there might be something else that I am missing.
(In reply to passfree from comment #9)
> The problem from the stack trace is that when libxpcom.dylib is loaded it
> will try to link to libmozglue.dylib but from the @executable_path. The
> executable path in this instance is Contents/MacOS/xulrunner. Obviously the
> libmozglue.dylib is nowhere to be found in this folder. But if you make a
> symbolic link to the xulrunner binary from the XUL.framework, then
> everything will work fine because the link will be resolved and therefore
> the dependencies satisfied.
> 
> Now, the question is how to fix this. The easy fix is to copy
> libmozglue.dylib into the Contents/MacOS/ folder next to the xulrunner
> binary. This will work although I find this quite dirty thing to do and I am
> not sure if it will have other side-effects. Please someone advise.

Does it work though? I experimented by fixing the relative patch to libmozglue.dylib from libxpcom.dylib (by replacing @executable_path with @loader_path) but then just hit the same problem with XUL which is also referenced as @executable_path. I don't think libmozglue is the problem here, it just happened to get introduced at the same time.

> Now, bug 578751 does propose the usage of @loader_path but I think this is
> the wrong way forward. Although I haven't tested this with the mozilla code
> base the correct form is to use @rpath instead. @rpath is supported from
> 10.5 and up and it should be considered safe. I don't think that Firefox is
> not supporting 10.4 these days anyway.
> 
> Out of all options, @executable_path, @loader_path and @rpath, the last one
> is most flexible.

I couldn't follow the information on rpath very well but it seemed to suggest that the application had to define a set of search paths, which doesn't work very well when XUL.framework could be in a couple of different places I think.
I am not quite sure what is going on but now everything works as it should? Could this be due to updates? I am not downloading xulrunner. I am using an old build which I used to report this bug. Now, however, everything works as it should and I am not quite sure what is going on.

Is this bug still occurring for you?
(In reply to passfree from comment #11)
> I am not quite sure what is going on but now everything works as it should?
> Could this be due to updates? I am not downloading xulrunner. I am using an
> old build which I used to report this bug. Now, however, everything works as
> it should and I am not quite sure what is going on.
> 
> Is this bug still occurring for you?

It was happening for me yesterday with 9.0 and a latest nightly build, was fine with 8.0
> Now, bug 578751 does propose the usage of @loader_path but I think this is the wrong way forward. 

Actually, @loader_path is exactly what we want: it makes library dependencies be searched in the directory containing the library. @rpath also requires a search path to be set, and guess what, you'd need to set that search path to @loader_path anyways.
(In reply to Dave Townsend (:Mossop) from comment #10)
> Does it work though? I experimented by fixing the relative patch to
> libmozglue.dylib from libxpcom.dylib (by replacing @executable_path with
> @loader_path) but then just hit the same problem with XUL which is also
> referenced as @executable_path. I don't think libmozglue is the problem
> here, it just happened to get introduced at the same time.

You need to change all libraries if you want that to work.
(In reply to Mike Hommey [:glandium] from comment #14)
> (In reply to Dave Townsend (:Mossop) from comment #10)
> > Does it work though? I experimented by fixing the relative patch to
> > libmozglue.dylib from libxpcom.dylib (by replacing @executable_path with
> > @loader_path) but then just hit the same problem with XUL which is also
> > referenced as @executable_path. I don't think libmozglue is the problem
> > here, it just happened to get introduced at the same time.
> 
> You need to change all libraries if you want that to work.

Yeah that's what I figured, I just don't understand how it worked in 8.0 where @executable_path was still used, which suggests there is an alternative
(In reply to Dave Townsend (:Mossop) from comment #15)
> Yeah that's what I figured, I just don't understand how it worked in 8.0
> where @executable_path was still used, which suggests there is an alternative

The executable loads all libraries listed in dependentlibs.list "manually". The difference is that now, the executable itself needs a library that is in the XRE directory, and all the others libraries need that library too. In practice, this means only libmozglue.dylib really needs to use @loader_path. However, if we use @loader_path everywhere, we can actually empty dependentlibs.list (although some adjustments might be needed in nsGlueLinkingOSX.cpp).
> The difference is that now, the executable itself needs a library that is in the XRE directory.

Except we changed that.

So, actually, adding libmozglue to dependentlibs.list could work, too, except it's only really needed for the stub, not the normal executable, nor Firefox.
(In reply to Mike Hommey [:glandium] from comment #16)
> (In reply to Dave Townsend (:Mossop) from comment #15)
> > Yeah that's what I figured, I just don't understand how it worked in 8.0
> > where @executable_path was still used, which suggests there is an alternative
> 
> The executable loads all libraries listed in dependentlibs.list "manually".
> The difference is that now, the executable itself needs a library that is in
> the XRE directory, and all the others libraries need that library too. In
> practice, this means only libmozglue.dylib really needs to use @loader_path.
> However, if we use @loader_path everywhere, we can actually empty
> dependentlibs.list (although some adjustments might be needed in
> nsGlueLinkingOSX.cpp).

Not sure I really follow this. As far as I can see the stub executable has always manually loaded libxpcom.dylib from the XRE directory. That has built-in dependencies on a bunch of other libraries all referenced through @executable_path so I'd expect the stub's attempt to load libxpcom.dylib to fail because of missing dependencies before it even gets to loading things from dependentlibs.list.
(In reply to Dave Townsend (:Mossop) from comment #18)
> Not sure I really follow this. As far as I can see the stub executable has
> always manually loaded libxpcom.dylib from the XRE directory. That has
> built-in dependencies on a bunch of other libraries all referenced through
> @executable_path so I'd expect the stub's attempt to load libxpcom.dylib to
> fail because of missing dependencies before it even gets to loading things
> from dependentlibs.list.

The way it works is that libraries listed in dependentlibs.list are loaded *before* loading libxpcom.
(In reply to Mike Hommey [:glandium] from comment #19)
> (In reply to Dave Townsend (:Mossop) from comment #18)
> > Not sure I really follow this. As far as I can see the stub executable has
> > always manually loaded libxpcom.dylib from the XRE directory. That has
> > built-in dependencies on a bunch of other libraries all referenced through
> > @executable_path so I'd expect the stub's attempt to load libxpcom.dylib to
> > fail because of missing dependencies before it even gets to loading things
> > from dependentlibs.list.
> 
> The way it works is that libraries listed in dependentlibs.list are loaded
> *before* loading libxpcom.

Ah got it. And yes adding libmozglue to dependentlibs.list does seem solve the problem. I presume if we did that everywhere there would be a perf hit as we attempt to load it a second time? Maybe we could hardcode the stub to manually load just that library?
> I presume if we did that everywhere there would be a perf hit as we attempt to load it a second time?

Since the library would have been loaded just moments ago, and since many other system libs are also loaded "several times" as being dependencies of many other system libs, I doubt this would be noticeable.
Attached patch patch rev 1 (obsolete) — Splinter Review
So the simple fix is to just add it to dependentlibs.list. This does it for all apps, all platforms right now. We could easily just do it for xulrunner if we wanted using a xulrunner/extradependlibs.mk file.
Attachment #612401 - Flags: review?(mh+mozilla)
We should do this for all apps so that WebRT works correctly in Firefox.
Blocks: 725408
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment on attachment 612401 [details] [diff] [review]
patch rev 1

Review of attachment 612401 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/stub/Makefile.in
@@ +80,5 @@
>  DEPENDENT_LIBS_LIST += \
>  	$(DLL_PREFIX)nspr4$(DLL_SUFFIX) \
>  	$(DLL_PREFIX)plc4$(DLL_SUFFIX) \
>  	$(DLL_PREFIX)plds4$(DLL_SUFFIX) \
> +	$(DLL_PREFIX)mozglue$(DLL_SUFFIX) \

This needs to be conditional on whether MOZ_GLUE_LDFLAGS is defined, because when it's not (such as on linux), then there is no $(DLL_PREFIX)mozglue$(DLL_SUFFIX)
Attachment #612401 - Flags: review?(mh+mozilla) → review-
Attached patch patch rev 2 (obsolete) — Splinter Review
Verified that this adds libmozglue.dylib on OSX but not linux
Assignee: nobody → dtownsend+bugmail
Attachment #612401 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #612663 - Flags: review?(mh+mozilla)
Comment on attachment 612663 [details] [diff] [review]
patch rev 2

Review of attachment 612663 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/stub/Makefile.in
@@ +80,5 @@
> +ifdef MOZ_GLUE_LDFLAGS
> +DEPENDENT_LIBS_LIST += \
> +	$(DLL_PREFIX)mozglue$(DLL_SUFFIX) \
> +	$(NULL)
> +endif

In principle, this should go above extradependlibs.mk, but I'm not sure what the TB and SM files do wrt DEPENDENT_LIBS_LIST. Do they assign or append?

Nit: you can make DEP_LIBS_LIST += ... a one-liner.
Attachment #612663 - Flags: feedback?(mbanner)
Attachment #612663 - Flags: feedback?(bugspam.Callek)
(In reply to Mike Hommey [:glandium] from comment #26)
> In principle, this should go above extradependlibs.mk, but I'm not sure what
> the TB and SM files do wrt DEPENDENT_LIBS_LIST. Do they assign or append?

We append: http://mxr.mozilla.org/comm-central/search?string=DEPENDENT_LIBS_LIST
Comment on attachment 612663 [details] [diff] [review]
patch rev 2

 -include $(topsrcdir)/$(MOZ_BUILD_APP)/extradependlibs.mk

This alone will break c-c apps, we do more than GLUE here. We have to make LDAP work by getting the LDAP libs added in.

See e.g. http://mxr.mozilla.org/comm-central/source/suite/extradependlibs.mk

And of course we will need to make sure the ordering is right, since the DEPENDENT_LIBS_LIST is completely order dependent! (see https://bugzilla.mozilla.org/show_bug.cgi?id=722262#c22 )
Attachment #612663 - Flags: feedback?(bugspam.Callek) → feedback-
Comment on attachment 612663 [details] [diff] [review]
patch rev 2

Review of attachment 612663 [details] [diff] [review]:
-----------------------------------------------------------------

So, this really needs to go above extradependlibs.mk, but doesn't require more changes than the move, fortunately.
Attachment #612663 - Flags: review?(mh+mozilla)
Attachment #612663 - Flags: review-
Attachment #612663 - Flags: feedback?(mbanner)
Comment on attachment 612663 [details] [diff] [review]
patch rev 2

Err wait -- stupid visual reading of the raw diff, | -| is not === |-| which means that it was not actually removed and is fine (assuming ordering is correct)
Attachment #612663 - Flags: feedback- → feedback+
Attached patch patch rev 3Splinter Review
Attachment #612663 - Attachment is obsolete: true
Attachment #612698 - Flags: review?(mh+mozilla)
Attachment #612698 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/39fc4711349c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
Is it possible to push this for 13?
This bug was fixed in 14. It was reintroduced between 15b1 and 15b2, which was (perhaps not coincidentally) when xulrunner-bin went away. It's still there today.
This bug was fixed in build 17.0.1, but was re-introduced in version 18 and later.  It is still reproducible in the latest stable build (23.0).  Can you fix it again?
(In reply to Thai Rath from comment #36)
> This bug was fixed in build 17.0.1, but was re-introduced in version 18 and
> later.  It is still reproducible in the latest stable build (23.0).  Can you
> fix it again?

File a new bug please. Bug you may not get much support unless you're willing to step up and do some of the debugging yourself, XULRunner is no longer maintained.
(In reply to Dave Townsend (:Mossop) from comment #37)
> (In reply to Thai Rath from comment #36)
> > This bug was fixed in build 17.0.1, but was re-introduced in version 18 and
> > later.  It is still reproducible in the latest stable build (23.0).  Can you
> > fix it again?
> 
> File a new bug please. Bug you may not get much support unless you're
> willing to step up and do some of the debugging yourself, XULRunner is no
> longer maintained.

CC me on that bug if/when you file it.  I filed bug 747597 and bug 448069 to ensure that once XULRunner SDK's are usable again on Mac, they never break again without our knowing.
I get the same issue just building Firefox on Mac (not even XUL Runner).  I've tried with 10.6, 10.7 and 10.8 SDKs, all the same problem.  I'm on Xcode 4.6.3, OSX 10.8.4.  Using the latest moz tools with Homebrew.  The build runs fine on my dev machine, but it generates the the "Library not loaded: @executable_path/libmozglue.dylib" on other machines when run.

Curious, can you tell me the exact software tool versions that Mozilla uses to build the Mac version of Firefox?  Clearly you are able to build on Mac there, so this would help isolate the problem.
So at this point, am I to understand that XULRunner simply doesn't work properly on Mac anymore?
(In reply to Mike Kaply (:mkaply) from comment #40)
> So at this point, am I to understand that XULRunner simply doesn't work
> properly on Mac anymore?

It keeps breaking in new ways, it's been fixed many times but until we actually have automated tests in place it's liable to keep breaking. I wouldn't rely on XULRunner.
Bug 923979 is where the latest fix has landed, slated for XULRunner 28.
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.