New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-566] NSTask should forward a valid environment #815
Comments
cc: @ddunbar |
I haven't tried the docker test, but I tried this locally with your launch.swift and it works. I suspect the problem you are hitting is related to the opening of the database. Will swift-build-tool have permissions to open .atllbuild/build.db? |
Oh, actually that wouldn't explain why the same swift-build-tool invocation works inside the container. I verified I can repro w/ your docker container, investigating... |
The problem is in your launch.swift, it has the wrong path to swift-build-tool, which is at /usr/local/bin, not /usr/bin. If you fix that then you will get further (link still fails, probably because container doesn't have /usr/bin/clang++ I would guess?) |
Updating path in reproduction case to /usr/local/bin. clang++ is installed; and can link programs, otherwise this would never work. In reality this always works, except when NSTask spawned the process. I don't know why the linker fails in this situation; that is the bug. I have also tested if we can do NSTask->shell->sbt->linker, and the answer appears to be that any use of NSTask will break the linker. I have no theories for why that is so; the obvious candidates like environment variables (even if NSTask tries to break them) would be restored by the shell. I am currently working around successfully with the POSIX "system(3)" call which is not affected by this issue. |
In this case the problem is simply that NSTask isn't preserving the environment, so PATH isn't propagated to subprocess by NSTask. Going NSTask -> shell works for me, but you have to remember to use "sh -l" to cause the environment to be reinitialized. /cc @parkera |
Thanks for tracking that down. Philippe, maybe you can take a look at this one? |
Hmm looks like we don't do anything with the env but pass nil. Seems like an easy fix. |
I pushed a change that should resolve this: apple/swift-corelibs-foundation@b3637a7 It would be good if this could be verified that the environment passing is correct. I did not get a chance yet to try it out with docker. |
Needs verification |
Attachment: Download
Environment
I've provided a portable Docker image to reproduce this issue.
However the affected config is Linux/64 running swift-2.2-SNAPSHOT-2016-01-11-a
Additional Detail from JIRA
md5: 8d5ae1975f299ee92516cc443b1a116f
Issue Description:
....this is an odd bug.
swift-build-tool returns error code 127 when it happens to be invoked via NSTask.
An identical invocation that isn't via NSTask works fine. ...I am as puzzled as you.
To assist with reproducing this issue, I've created a portable Docker image that exactly matches my environment. Reproduction steps:
1. Extract the files to some directory
2.
docker build .
Expected results: Container builds
Actual results: Docker container fails to build
Essentially:
1. The docker container tries to invoke
launch.swift
2.
launch.swift
creates an NSTask that callsswift-build-tool
3.
swift-build-tool
returns error code 127 tolaunch.swift
4.
launch.swift
hitsfatalError
codepathIf you instead invoke
swift-build-tool
in exactly the same way without NSTask, everything's fine:Theories:
1. Maybe corelibs-Foundation is doing something strange?
2. could swift-build-tool be expecting a tty / stdin / stdout?
The text was updated successfully, but these errors were encountered: