Closed Bug 1562684 Opened 5 years ago Closed 5 years ago

[10.15][Mac] PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina

Categories

(Firefox Build System :: General, defect, P2)

Product:
Firefox Build System
Component:
General
Platform:
Unspecified
macOS
Type:
defect

Tracking

(firefox-esr60 fixed, firefox-esr68 fixed, firefox69 fixed, firefox70 fixed)

Status:
RESOLVED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox-esr60 --- fixed
firefox-esr68 --- fixed
firefox69 --- fixed
firefox70 --- fixed

People

(Reporter: haik, Assigned: haik)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1562684 - PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina
47 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-beta+
RyanVM
: approval-mozilla-release-
RyanVM
: approval-mozilla-esr60+
RyanVM
: approval-mozilla-esr68+
Details | Review

With macOS 10.15 Beta 2, local builds crash at startup. With a debug build, we assert in InitializeNSSWithFallbacks(). This is a build using the 10.11 SDK (MacOSX10.11.sdk). See stack below.

MOZ_LOG=pipnss:4

[Parent 75861: Main Thread]: D/pipnss nsNSSComponent::ctor
[Parent 75861: Main Thread]: D/pipnss Beginning NSS initialization
[Parent 75861: Main Thread]: D/pipnss nsNSSComponent::InitializeNSS
[Parent 75861: Main Thread]: D/pipnss NSS Initialization beginning
[Parent 75861: Main Thread]: D/pipnss NSS profile at '/Users/haftandilian/r/unified/obj-dbg.noindex/tmp/profile-default'
[Parent 75861: Main Thread]: D/pipnss inSafeMode: 0
[Parent 75861: Main Thread]: D/pipnss failed to initialize NSS with codes -5977 -5925
[Parent 75861: Main Thread]: D/pipnss last-resort NSS_NoDB_Init

Hit MOZ_CRASH(InitializeNSSWithFallbacks failed: -5925) at /Users/haftandilian/r/unified/security/manager/ssl/nsNSSComponent.cpp:1658
#01: InitializeNSSWithFallbacks(nsTSubstring<char> const&, bool, bool)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x8e686ad]
#02: nsNSSComponent::InitializeNSS()[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x8e67427]
#03: nsNSSComponent::Init()[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x8e68fa1]
#04: mozilla::xpcom::CreateInstanceImpl(mozilla::xpcom::ModuleID, nsISupports*, nsID const&, void**)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x21cfba]
#05: mozilla::xpcom::StaticModule::CreateInstance(nsISupports*, nsID const&, void**) const[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x215e75]
#06: (anonymous namespace)::EntryWrapper::CreateInstance(nsISupports*, nsID const&, void**)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x274877]
#07: nsComponentManagerImpl::GetServiceLocked((anonymous namespace)::MutexLock&, (anonymous namespace)::EntryWrapper&, nsID const&, void**)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x26b573]
#08: nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x265966]
#09: CallGetService(char const*, nsID const&, void**)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x2701ae]
#10: nsGetServiceByContractIDWithError::operator()(nsID const&, void**) const[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x2708bf]
#11: nsCOMPtr_base::assign_from_gs_contractid_with_error(nsGetServiceByContractIDWithError const&, nsID const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x10082e]
#12: nsCOMPtr<nsISupports>::nsCOMPtr(nsGetServiceByContractIDWithError const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x5008ae]
#13: nsCOMPtr<nsISupports>::nsCOMPtr(nsGetServiceByContractIDWithError const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x4c48fd]
#14: net_EnsurePSMInit()[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x5b54eb]
#15: mozilla::net::nsHttpHandler::NewProxiedChannel(nsIURI*, nsIProxyInfo*, unsigned int, nsIURI*, nsILoadInfo*, nsIChannel**)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0xb68bcd]
#16: mozilla::net::nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI*, nsIURI*, unsigned int, nsILoadInfo*, nsIChannel**)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x574757]
#17: mozilla::net::nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI*, nsIURI*, unsigned int, nsINode*, nsIPrincipal*, nsIPrincipal*, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsig[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x5743a1]
#18: mozilla::net::nsIOService::NewChannelFromURIWithClientAndController(nsIURI*, nsINode*, nsIPrincipal*, nsIPrincipal*, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, unsigned int,[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x574158]
#19: NS_NewChannelInternal(nsIChannel**, nsIURI*, nsINode*, nsIPrincipal*, nsIPrincipal*, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, unsigned int, nsICookieSettings*, mozilla::do[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x5a60da]
#20: NS_NewChannel(nsIChannel**, nsIURI*, nsIPrincipal*, unsigned int, unsigned int, nsICookieSettings*, mozilla::dom::PerformanceStorage*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, nsIIOService*)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x5a5dba]
#21: mozilla::dom::XMLHttpRequestMainThread::CreateChannel()[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x602e5a2]
#22: mozilla::dom::XMLHttpRequestMainThread::Open(nsTSubstring<char> const&, nsTSubstring<char> const&, bool, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x602df72]
#23: mozilla::dom::XMLHttpRequestMainThread::Open(nsTSubstring<char> const&, nsTSubstring<char16_t> const&, bool, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, mozilla::ErrorResult&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x602d512]
#24: mozilla::dom::XMLHttpRequest_Binding::open(JSContext*, JS::Handle<JSObject*>, mozilla::dom::XMLHttpRequest*, JSJitMethodCallArgs const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x3f3d373]
#25: bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x44b2a39]
#26: CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95deb41]
#27: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95de6c0]
#28: InternalCall(JSContext*, js::AnyInvokeArgs const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95df11a]
#29: js::CallFromStack(JSContext*, JS::CallArgs const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95deefd]
#30: Interpret(JSContext*, js::RunState&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95d25be]
#31: js::RunScript(JSContext*, js::RunState&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95c7169]
#32: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95de87e]
#33: InternalCall(JSContext*, js::AnyInvokeArgs const&)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95df11a]
#34: js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x95df1c1]
#35: JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x9e3369a]
#36: nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x1acc71d]
#37: PrepareAndDispatch[/Users/haftandilian/r/unified/obj-dbg.noindex/toolkit/library/XUL +0x304ea2]
2019-07-01 16:02:15.325854+0000 plugin-container[77675:353086] [default] SLSGetSpaceManagementMode: No connection with id 0x   2ea17
Process 77618 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000010b4e46b9 XUL`InitializeNSSWithFallbacks(nsTSubstring<char> const&, bool, bool) [inlined] MOZ_Crash(aFilename="/Users/haftandilian/r/unified/security/manager/ssl/nsNSSComponent.cpp", aLine=1658, aReason="InitializeNSSWithFallbacks failed: -5925") at Assertions.h:313:3
   310 	  MOZ_ReportCrash(aReason, aFilename, aLine);
   311 	#endif
   312 	  MOZ_CRASH_ANNOTATE(aReason);
-> 313 	  MOZ_REALLY_CRASH(aLine);
   314 	}
   315 	#define MOZ_CRASH_UNSAFE(reason) MOZ_Crash(__FILE__, __LINE__, reason)
   316 	
Target 0: (firefox) stopped.
Blocks: catalina
Assignee: nobody → kjacobs.bugzilla
Status: NEW → ASSIGNED
Priority: -- → P2

I haven't been able to reproduce this. I have a Parallels VM running the same OSX/SDK versions, but mach run gives me an OpenGL error and crashes. Oddly, I can execute mochitests which should be calling the same initalization, and they pass.

Has this been reproduced on more than one machine? Could you provide an strace (mac equivalent) output?

(In reply to Kevin Jacobs [:kjacobs] from comment #1)

I haven't been able to reproduce this. I have a Parallels VM running the same OSX/SDK versions, but mach run gives me an OpenGL error and crashes. Oddly, I can execute mochitests which should be calling the same initalization, and they pass.

Has this been reproduced on more than one machine? Could you provide an strace (mac equivalent) output?

Just the one machine that I have 10.15 Beta installed on. However, Apple just released 10.15 Beta 3 so I will retest with that once I get it installed.

Flags: needinfo?(haftandilian)

(In reply to Haik Aftandilian [:haik] from comment #2)

(In reply to Kevin Jacobs [:kjacobs] from comment #1)

I haven't been able to reproduce this. I have a Parallels VM running the same OSX/SDK versions, but mach run gives me an OpenGL error and crashes. Oddly, I can execute mochitests which should be calling the same initalization, and they pass.

Has this been reproduced on more than one machine? Could you provide an strace (mac equivalent) output?

Just the one machine that I have 10.15 Beta installed on. However, Apple just released 10.15 Beta 3 so I will retest with that once I get it installed.

This reproduces on my machine as well. I have not tested with Beta 3 yet.

Still reproduces with 10.15 Beta 3.

Blocks: 1556846
Flags: needinfo?(haftandilian)

Thanks - I was able to reproduce this on a physical machine. Debug in progress.

We fail out while loading libsftokn3.dylib from different paths:

  • Mojave: mozilla-unified/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libsoftokn3.dylib
  • Catalina: mozilla-unified/obj-x86_64-apple-darwin19.0.0/security/libsoftokn3.dylib (File does not exist)

This follows libnss3.dylib being loaded from the latter path on Catalina (where the file does exist). It also exists and should be loading from (along with the other dependencies) mozilla-unified/obj-x86_64-apple-darwin19.0.0/dist/Nightly.app/Contents/MacOS/

I'm not sure why this happens yet, but posting the finding in case anyone on the thread knows where to look.

Root cause is that dladdr returns the resolved target path (mozilla-unified/obj-ff-dbg/security/libnss3.dylib) on Catalina, but the unresolved path (mozilla-unified/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libnss3.dylib) on Mojave. We use this output to determine where to load libsoftokn3.dylib from.

image list/dtruss show they both load the symlink, and I can reproduce the dladdr behavior with a small test program and my own links.

I'm not sure how to debug this further since it seems to be outside of NSS, but a workaround is to copy all the dylibs from the symlink path to the target.

Haik, how should we proceed?

The regression is visible in dli.dli_fname after https://searchfox.org/mozilla-central/source/nsprpub/pr/src/linking/prlink.c#1219

Flags: needinfo?(haftandilian)

(In reply to Kevin Jacobs [:kjacobs] from comment #8)

Haik, how should we proceed?

The regression is visible in dli.dli_fname after https://searchfox.org/mozilla-central/source/nsprpub/pr/src/linking/prlink.c#1219

Thanks for looking into this. I'll ask our Apple contact if this is an intended change for 10.15. If it is, I think we'll have to change our logic to assume absolute paths, assuming we can derive the path to libsoftokn3.dylib from the absolute path to libnss3.dylib.

This might mean that ./mach build package is a workaround for this problem. Once my build finishes, I'll test that and update the bug.

Leaving the needinfo here for myself.

(In reply to Haik Aftandilian [:haik] from comment #9)

(In reply to Kevin Jacobs [:kjacobs] from comment #8)
This might mean that ./mach build package is a workaround for this problem. Once my build finishes, I'll test that and update the bug.

I tested this and it works. In addition to the workaround Kevin mentioned on comment 7, developers can use a package build to launch Firefox built from their repo. This should only be necessary on 10.15. For example,

$ ./mach build package
...
 0:32.63 created: /Users/haftandilian/mozilla-unified/obj-opt.noindex/dist/firefox-69.0a1.en-US.mac.dmg
...
$ open /Users/haftandilian/mozilla-unified/obj-opt.noindex/dist/firefox-69.0a1.en-US.mac.dmg

And digressing a bit here, but due to bug 1428409, ./mach build package can sometimes fail after the tree changes and files are removed. To workaround that problem, you need to remove broken symlinks from your object dirs. I use the following find command which needs to be updated with your own object dir paths. It removes files so be careful.

$ cd mozilla-unified
$ find obj-opt.noindex/ obj-dbg.noindex/ -type l ! -exec test -e {} \; -print -exec rm {} \;

Moving over to NSPR for now and cc'ing Glandium

Component: Libraries → NSPR
Product: NSS → NSPR
Summary: [10.15][Mac] local builds MOZ_ASSERT crash on startup in InitializeNSSWithFallbacks → [10.15][Mac] PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina
Version: 3.45 → other

Is mozilla-unified/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libnss3.dylib a symbolic link?

(In reply to Mike Hommey [:glandium] from comment #12)

Is mozilla-unified/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libnss3.dylib a symbolic link?

Yes, it is.

That would be the problem then, which is a build system problem.

Component: NSPR → General
Product: NSPR → Firefox Build System
QA Contact: jjones
Version: other → unspecified

Can someone building on 10.14 or 10.13 confirm whether their equivalent file is a regular file rather than a symlink?

(In reply to Mike Hommey [:glandium] from comment #15)

Can someone building on 10.14 or 10.13 confirm whether their equivalent file is a regular file rather than a symlink?

It is a symlink too. I think this is intentional to not make full copies of a bunch of files in local builds.

it's a symlink to where?

(In reply to Mike Hommey [:glandium] from comment #17)

it's a symlink to where?

[...]/objdir-ff-debug/security/libnss3.dylib

Flags: needinfo?(haftandilian)
See Also: → 1380416

If you compile the following with something like clang -o foo foo.c -ldl:

#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
  Dl_info info;
  void *handle = dlopen(argv[1], RTLD_GLOBAL | RTLD_LAZY);
  void *sym = dlsym(handle, argv[2]);
  dladdr(sym, &info);
  printf("%s\n", info.dli_fname);
  return 0;
}

and run ./foo /path/to/dist/bin/libnss3.dylib NSS_GetVersion, it tells you the dist/bin path on 10.14 and the security path on 10.15?

Bwarf, that command doesn't even work because those are symlinks. Try ./foo /path/to/dist/bin/libmozglue.dylib malloc

(In reply to Mike Hommey [:glandium] from comment #19)

it tells you the dist/bin path on 10.14 and the security path on 10.15?

I tested on 10.14 and 10.15 and in both cases it prints the resolved path.

So... how does this work on 10.14? We do define HAVE_DLADDR, so we should be using the dladdr variant of PR_GetLibraryFilePathname (USE_DLFCN is defined in _darwin.h)

Haik, did you by chance pass a relative path to the dylib? I'm seeing:

10.14:

kjacobs-44776:~ kjacobs$ ./foo /Users/kjacobs/repos/mozilla-unified/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libmozglue.dylib  malloc
/Users/kjacobs/repos/mozilla-unified/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libmozglue.dylib
kjacobs-44776:~ kjacobs$ ./foo repos/mozilla-unified/obj-ff-dbg/dist/NightlyDebug.app/Contents/MacOS/libmozglue.dylib  malloc
/Users/kjacobs/repos/mozilla-unified/obj-ff-dbg/mozglue/build/libmozglue.dylib
kjacobs-44776:~ kjacobs$

10.15:

mozilla-nwh03y:~ mozilla$ ./foo /Users/mozilla/mozilla-unified/obj-x86_64-apple-darwin19.0.0/dist/Nightly.app/Contents/MacOS/libmozglue.dylib malloc
/Users/mozilla/mozilla-unified/obj-x86_64-apple-darwin19.0.0/mozglue/build/libmozglue.dylib
mozilla-nwh03y:~ mozilla$ ./foo mozilla-unified/obj-x86_64-apple-darwin19.0.0/dist/Nightly.app/Contents/MacOS/libmozglue.dylib malloc
/Users/mozilla/mozilla-unified/obj-x86_64-apple-darwin19.0.0/mozglue/build/libmozglue.dylib

(In reply to Kevin Jacobs [:kjacobs] from comment #23)

Haik, did you by chance pass a relative path to the dylib? I'm seeing:

Yes, I did use a relative path. I'll retest with absolute paths.

(In reply to Haik Aftandilian [:haik] from comment #24)

(In reply to Kevin Jacobs [:kjacobs] from comment #23)

Haik, did you by chance pass a relative path to the dylib? I'm seeing:

Yes, I did use a relative path. I'll retest with absolute paths.

With absolute paths, I get the differing results on 10.14 vs 10.15: 10.15 returns the resolved path while 10.14 returns the symlink.

I haven't asked Apple about this yet due to glandium's comments about this being a build system bug. But it sounds like that was in reference to a symlinks being used, but that is expected on Mac builds and now it's clear dladdr is working differently on 10.15.

I thought it was fair that the behavior of dladdr changed. In any case, there's nothing nspr can do about that. It's however been a longstanding issue that libraries are symbolic links, and ideally, we'd create them directly in the right location, which would solve these problems.
Now, the fact that there's a difference between absolute and relative paths shows there may be something unintended happening in 10.15's libdl.

Note that this only really causes problems for running firefox from a local build tree, but if you mach package and run the result of that, it should work.

(In reply to Mike Hommey [:glandium] from comment #26)

I thought it was fair that the behavior of dladdr changed. In any case, there's nothing nspr can do about that. It's however been a longstanding issue that libraries are symbolic links, and ideally, we'd create them directly in the right location, which would solve these problems.
Now, the fact that there's a difference between absolute and relative paths shows there may be something unintended happening in 10.15's libdl.

It seems more like an existing bug that was fixed. In 10.15, absolute paths are always returned. In 10.14, it depends on whether or not the dlopen'd path was a relative path.

On 10.14 absolute paths were returned too. What changed in 10.15 is that if you start from an absolute path, you get the resolved path of symbolic link.

Scrap that, I misread which did what.

Assignee: kjacobs.bugzilla → nobody
Status: ASSIGNED → NEW

I have an issue open with Apple about the dladdr behavior change and it's being looked at, but this could turn out to be intentional or not resolved in time for Catalina.

I think the best way to resolve this is going to be to change the build scripts so that the dylibs are copied from their respective build directories to $OBJDIR/dist/Nightly{Debug}.app/Contents/MacOS/ instead of symlinked. That would let the existing logic that assumes certain dylibs are in the same directory continue to work. The alternative would be to add logic in libnss and libsoftokn3 to look in additional locations.

If we copy all the dylibs in the dist/bin directory, that works about to be about 12M for a debug build. The listing below shows the dylib sizes after manually copying to the .app/Contents/MacOS dir.

$ du -shc *.dylib
752K	libfreebl3.dylib
 88K	liblgpllibs.dylib
3.5M	libmozavcodec.dylib
336K	libmozavutil.dylib
2.0M	libmozglue.dylib
4.5M	libnss3.dylib
600K	libnssckbi.dylib
300K	libnssdbm3.dylib
 12K	libplugin_child_interpose.dylib
460K	libsoftokn3.dylib
 12M	total
Assignee: nobody → haftandilian

Instead of using symlinks, copy .dylib files to the ${OBJDIR}/dist/Nightly{Debug}.app/Contents/MacOS dir for local builds.

Attachment #9085380 - Attachment description: Bug 1562684 - PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina r?glandium → Bug 1562684 - PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina
No longer blocks: 1556846
Pushed by haftandilian@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2908769da8be PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina r=froydnj

I'll file an uplift request after this has been on Nightly for a few days.

Flags: needinfo?(haftandilian)

https://hg.mozilla.org/mozilla-central/rev/2908769da8be

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox70: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Flags: needinfo?(haftandilian)
Keywords: regression
Flags: needinfo?(haftandilian)

Comment on attachment 9085380 [details]
Bug 1562684 - PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina

Beta/Release Uplift Approval Request

  • User impact if declined: None.

This is build script change that allows developers to run "./mach run" launch Firefox on macOS Catalina. Developers mostly build Nightly, but sometimes have to build Beta, Release, or the ESRs. This could also be deferred until Catalina actually ships. The workaround is to use "./mach build package" and use the binary from the .dmg.

  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Build script change only.
  • String changes made/needed:

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is build script change that allows developers to run "./mach run" to launch Firefox on macOS Catalina. Developers mostly build Nightly, but sometimes have to build Beta, Release, or the ESRs. This could also be deferred until Catalina actually ships. The workaround is to use "./mach build package" and use the binary from the .dmg.
  • User impact if declined: None.
  • Fix Landed on Version: 70
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Build script change only.
  • String or UUID changes made by this patch:
Flags: needinfo?(haftandilian)
Attachment #9085380 - Flags: approval-mozilla-release?
Attachment #9085380 - Flags: approval-mozilla-esr68?
Attachment #9085380 - Flags: approval-mozilla-esr60?
Attachment #9085380 - Flags: approval-mozilla-beta?

Comment on attachment 9085380 [details]
Bug 1562684 - PR_GetLibraryFilePathname is returning absolute paths in MacOS Catalina

Makes life easier for developers to run builds locally on macOS 10.15. No affect on the packaged builds we ship. Approved for 69rc1, 68.1esr, and 60.9esr. No need to land this on m-r since 69 is being merged there in a couple days anyway.

Attachment #9085380 - Flags: approval-mozilla-release?
Attachment #9085380 - Flags: approval-mozilla-release-
Attachment #9085380 - Flags: approval-mozilla-esr68?
Attachment #9085380 - Flags: approval-mozilla-esr68+
Attachment #9085380 - Flags: approval-mozilla-esr60?
Attachment #9085380 - Flags: approval-mozilla-esr60+
Attachment #9085380 - Flags: approval-mozilla-beta?
Attachment #9085380 - Flags: approval-mozilla-beta+
See Also: → 1772395
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: