Bug 198904 - REGRESSION (r242686): Paths in XPC services’ LC_DYLD_ENVIRONMENT are incorrect in built products directory
Summary: REGRESSION (r242686): Paths in XPC services’ LC_DYLD_ENVIRONMENT are incorrec...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 198646 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-06-16 09:06 PDT by mitz
Modified: 2019-07-11 09:36 PDT (History)
8 users (show)

See Also:


Attachments
Use correct relative paths in load commands when not installing (6.38 KB, patch)
2019-06-16 09:17 PDT, mitz
mitz: review-
Details | Formatted Diff | Diff
Use correct relative paths in load commands when not installing (7.52 KB, patch)
2019-06-16 11:32 PDT, mitz
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2019-06-16 09:06:16 PDT
<https://trac.webkit.org/r242686> changed the location of the XPC service executables relative to the frameworks and libraries in the built product directories, but didn’t update the load commands that set DYLD_FRAMEWORK_PATH and DYLD_LIBRARY_PATH. Consequently, the services don’t load the built frameworks, libraries and shim unless something sets the __XPC_DYLD_… environment variables to point to the right place.

Patch forthcoming.
Comment 1 mitz 2019-06-16 09:17:31 PDT
Created attachment 372223 [details]
Use correct relative paths in load commands when not installing

<https://trac.webkit.org/r245965> should also be reverted after this.
Comment 2 Darin Adler 2019-06-16 09:41:53 PDT
Comment on attachment 372223 [details]
Use correct relative paths in load commands when not installing

View in context: https://bugs.webkit.org/attachment.cgi?id=372223&action=review

Is there a good way to test this?

> Source/WebKit/ChangeLog:16
> +          frameworkâs XPCServices directory predicated on whether this is an install build, rathher

rather unusual spelling (extra h typo)
Comment 3 mitz 2019-06-16 10:02:43 PDT
(In reply to Darin Adler from comment #2)
> Comment on attachment 372223 [details]
> Use correct relative paths in load commands when not installing
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=372223&action=review
> 
> Is there a good way to test this?

Download the build product from EWS, and execute the XPC service binary in a shell (it will crash, but there should not be errors about symbols missing). Doing this just now I see that the patch is wrong, so I am going to rework it.

> 
> > Source/WebKit/ChangeLog:16
> > +          frameworkâs XPCServices directory predicated on whether this is an install build, rathher
> 
> rather unusual spelling (extra h typo)
Comment 4 mitz 2019-06-16 11:32:08 PDT
Created attachment 372225 [details]
Use correct relative paths in load commands when not installing
Comment 5 Alex Christensen 2019-06-17 11:04:50 PDT
Comment on attachment 372225 [details]
Use correct relative paths in load commands when not installing

DEPLOYMENT_LOCATION doesn't seem to be a yes/no kind of variable name to me.
Comment 6 mitz 2019-06-17 11:22:41 PDT
(In reply to Alex Christensen from comment #5)
> Comment on attachment 372225 [details]
> Use correct relative paths in load commands when not installing
> 
> DEPLOYMENT_LOCATION doesn't seem to be a yes/no kind of variable name to me.

It’s documented as having Value Type of Boolean, and offers a Yes/No pop-up menu in Xcode’s Build Settings Editor.

Thanks for the review!
Comment 7 WebKit Commit Bot 2019-06-17 11:53:37 PDT
Comment on attachment 372225 [details]
Use correct relative paths in load commands when not installing

Clearing flags on attachment: 372225

Committed r246506: <https://trac.webkit.org/changeset/246506>
Comment 8 WebKit Commit Bot 2019-06-17 11:53:39 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Radar WebKit Bug Importer 2019-06-17 11:54:20 PDT
<rdar://problem/51814778>
Comment 10 Darin Adler 2019-06-17 11:56:11 PDT
(In reply to mitz from comment #1)
> <https://trac.webkit.org/r245965> should also be reverted after this.

Are you going to do that? Should Alex do that? Is someone else volunteering to do it?
Comment 11 mitz 2019-06-17 12:02:43 PDT
(In reply to Darin Adler from comment #10)
> (In reply to mitz from comment #1)
> > <https://trac.webkit.org/r245965> should also be reverted after this.
> 
> Are you going to do that? Should Alex do that? Is someone else volunteering
> to do it?

I intend to do it.
Comment 12 mitz 2019-06-17 13:46:20 PDT
(In reply to mitz from comment #11)
> (In reply to Darin Adler from comment #10)
> > (In reply to mitz from comment #1)
> > > <https://trac.webkit.org/r245965> should also be reverted after this.
> > 
> > Are you going to do that? Should Alex do that? Is someone else volunteering
> > to do it?
> 
> I intend to do it.

Just confirmed with an r246507 archive from nightly.webkit.org that it’s safe to removed.
Comment 13 Darin Adler 2019-07-11 09:36:59 PDT
*** Bug 198646 has been marked as a duplicate of this bug. ***