The default bug view has changed. See this FAQ.

update in-tree virtualenv to 1.7.2

RESOLVED FIXED in mozilla16

Status

()

Core
Build Config
--
blocker
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: kats, Assigned: Jeff Hammel)

Tracking

({regression})

Trunk
mozilla16
Other
Android
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Created attachment 627530 [details]
Build output

STR:
1. Update to latest m-c code (I'm using a git clone of https://github.com/mozilla/mozilla-central.git)
2. rm -rf objdir/*
3. make -f client.mk

Expected results:
- stuff builds

Actual results:
- build fails with python virtual env errors. See attached file for the full build output (error is at the end)
In case it matters, I'm running OS X 10.7.4 and python 2.7.1
Huh, I have no idea what's going on there.

Comment 3

5 years ago
Could be this error that causes the second.

Could not call install_name_tool -- you must have Apple's development tools installed

Comment 4

5 years ago
Yes, virtualenv requires Xcode (or the new Apple command-line developer tools package) on OS X, and that's the source of the problem.
AFAICT, this is what virtualenv does:
- It copies /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python to _virtualenv/bin/python
- It copies /System/Library/Frameworks/Python.framework/Versions/2.7/Python in _virtualenv/.Python
- It uses install_name_tool to change the reference in _virtualenv/bin/python from /System/Library/Frameworks/Python.framework/Versions/2.7/Python to @executable_path/../.Python (which, in practice, means _virtualenv/.Python)

If, instead of doing the latter, we call python with DYLD_INSERT_LIBRARIES=$(DEPTH)/_virtualenv/.Python, then it should work without needing install_name_tool.
I do have install_name_tool installed and on my path. The log output shows that it does run, but produces an error:

install_name_tool: object: ./_virtualenv/bin/python malformed object (unknown load command 4)
Is there something I can try or back out to get this working? This is blocking me from doing anything.
Updating XCode to the latest version (which presumably updated the version of install_name_tool) seems to have done the trick. At least, it's gotten past that first error, will WFM this bug if the build completes.
Build worked. Yay!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
(In reply to Kartikaya Gupta (:kats) from comment #8)
> Updating XCode to the latest version (which presumably updated the version
> of install_name_tool) seems to have done the trick. At least, it's gotten
> past that first error, will WFM this bug if the build completes.

What version did you have before/after?

(In reply to Mike Hommey [:glandium] from comment #5)
> If, instead of doing the latter, we call python with
> DYLD_INSERT_LIBRARIES=$(DEPTH)/_virtualenv/.Python, then it should work
> without needing install_name_tool.

Reoppening and assigning to Mike to figure out what the required way forward here is (if anything). Might be "we need to document that you need that version of XCode" might be "we need to back this out", might be "we need to do some magic DYLD_* change", but whatever it is I trust him to make that call.
Assignee: nobody → mh+mozilla
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
kats@kgupta-air ~$ pkgutil --file-info /usr/bin/install_name_tool
volume: /
path: /usr/bin/install_name_tool

pkgid: com.apple.pkg.DeveloperToolsCLILeo
pkg-version: 1.0.0.9000000000.1.1249367152
install-time: 1338237149
uid: 0
gid: 0
mode: 555

I had run this before and after doing the update, and the only thing that changed was the install time (in particular the pkg-version didn't change). When I fire up XCode now, it reports its version as 4.1 (4B110); I'm not sure what it was before I did the update.
Created attachment 633133 [details] [diff] [review]
Avoid relying on install_name_tool to modify the python binary on OSX
Attachment #633133 - Flags: review?(ted.mielczarek)
Attachment #633133 - Flags: review?(cmeyer)
(In reply to Mike Hommey [:glandium] from comment #12)
> Created attachment 633133 [details] [diff] [review]
> Avoid relying on install_name_tool to modify the python binary on OSX

Sent a pull request upstream, too. https://github.com/pypa/virtualenv/pull/289
Normally I'd just say if you got upstream review you'd be fine here, but I'm probably fairly qualified to review this actual code.

Carl: do you want me to review this to help you land it upstream?
(In reply to Ted Mielczarek [:ted] from comment #14)
> Normally I'd just say if you got upstream review you'd be fine here, but I'm
> probably fairly qualified to review this actual code.
> 
> Carl: do you want me to review this to help you land it upstream?

That would be great. The code looks fine to me, but I know next to nothing about OS X and Mach-O. Also, confirmation that it works, of course, especially if you have an older OS X available to test on.

Updated

5 years ago
Attachment #633133 - Flags: review?(cmeyer) → review-
A pull request based on this patch has been merged into virtualenv's "develop" branch, and released as part of virtualenv 1.7.2. Thanks very much for the contribution; it's something virtualenv users have been asking for for a long time.

I r-ed the patch attached here, as it's not up to date with what was actually committed (particularly in that everything was moved into virtualenv.py). I suppose the correct patch here would simply be a full upgrade of virtualenv.py to version 1.7.2, rather than applying single upstream patches piecemeal.
Summary: Build is broken with python virtualenv errors → update in-tree virtualenv to 1.7.2
Blocks: 767329
Note that the fix for bug 767329 was applied upstream just after the release of 1.7.2, so in order to fix both bugs virtualenv will need to be updated to the "develop" branch, not the 1.7.2 release.
(Assignee)

Comment 18

5 years ago
Created attachment 637288 [details] [diff] [review]
pointing to current tip

Taking virtualenv tip as of today
(Assignee)

Comment 19

5 years ago
(In reply to Jeff Hammel [:jhammel] from comment #18)
> Created attachment 637288 [details] [diff] [review]
> pointing to current tip
> 
> Taking virtualenv tip as of today

And pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=97ee967242b5
(Assignee)

Comment 20

5 years ago
(In reply to Jeff Hammel [:jhammel] from comment #19)
> (In reply to Jeff Hammel [:jhammel] from comment #18)
> > Created attachment 637288 [details] [diff] [review]
> > pointing to current tip
> > 
> > Taking virtualenv tip as of today
> 
> And pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=97ee967242b5

ABICT none of the failures are due to the new virtualenv.
(Assignee)

Updated

5 years ago
Attachment #637288 - Flags: review?(ted.mielczarek)
Attachment #637288 - Flags: review?(ted.mielczarek) → review+
(Assignee)

Comment 21

5 years ago
Thanks.  Now it needs to be pushed
Keywords: checkin-needed
(Assignee)

Comment 22

5 years ago
This should also fix bug 767329
Attachment #633133 - Attachment is obsolete: true
Attachment #633133 - Flags: review?(ted.mielczarek)
https://hg.mozilla.org/mozilla-central/rev/8534fbb1a5da
Assignee: mh+mozilla → jhammel
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Flags: in-testsuite-
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
You need to log in before you can comment on or make changes to this bug.