-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
bootloader: do not overwrite/lose LD_LIBRARY_PATH #2148
bootloader: do not overwrite/lose LD_LIBRARY_PATH #2148
Conversation
6724dc1
to
8707bd8
Compare
Thanks for this fix. Not being a C-programmer, this basically looks good for me. Would you please provide some doc-update, too describing the new env-var? |
*/ | ||
int first_len=0, sep_len=0, second_len=0; | ||
char *result; | ||
if(first) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a space in front of the parent and put the body into {…;}
. This is how it is done in the remaining code.
Looks good for me. @bjones1 What do you think? |
Note: I am currently running tests in vagrant VM (first on debian wheezy, where we discovered the problem with fakeroot, afterwards on freebsd). |
Looks fine. But @codewarrior0 is really the bootloader expert... |
borg.exe was (accidentally) built with the bundled and still as-before 32bit linux bootloader (because it first failed building it due to a missing --no-lsb option in my Vagrantfile). borg2.exe was built with the modified bootloader. Update: Yay, 14 test failures less (our tests were a bit disturbed by the unexpected output on stderr). |
VS("LOADER: %s=%s\n", env_var_orig, orig_path); | ||
|
||
/* prepend our path to the original path */ | ||
new_path = pyi_strjoin(path, ":", orig_path); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
new_path
needs to be freed somewhere...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, copies will be made, so we can free this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about this?
new_path = alloc(strlen(path) + 1 + strlen(orig_path) + 1);
sprintf(new_path, "%s:%s", path, orig_path);
I think this is the much simpler solution. (the double +1 could just be a +2, but I put it this way to signify why it's there)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for PlasmaPower.
we could even use alloca()
considering there's a practical limit on PATH
length which is, now, half of env
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this does not consider the case when the current env var value is empty.
(or when the first param is an empty string, which can not be the case for this caller)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (orig_path && *orig_path != '\0') {
new_path = alloca(strlen(path) + 1 + strlen(orig_path) + 1);
sprintf(new_path, "%s:%s", path, orig_path);
} else {
new_path = path;
}
Then don't free it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PlasmaPower (github @ completion does not like you, btw): i would not advocate for having 6 lines that need to be copy&paste at every place where string join is needed, but rather have the simple 1-line function call.
With alloca it can't be in a function as that memory is only valid within that function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense.
d26cbc7
to
271db7b
Compare
OK, I'm done. Decide yourself whether you rather like first or first+second changeset. First one is easier, first+second saves some cpu cycles, but has more LoC. Can we have this in a 3.2.1 soon? Without this our unit tests are partially broken and it would be nice not having to patch it and build the bootloaders with LSB stuff via vagrant. Please don't forget to rebuild all the bootloader binaries with this. |
In the docs for Other than that, looks good to me! |
rather: - prepend our path to the exisiting path - save the original path in the environment also: - update docs - implement pyi_strjoin (oh the joys of string processing in C!) Likely, this fixes pyinstaller#625 and helps with pyinstaller#1759.
bf0073d
to
6589af3
Compare
@codewarrior0 yup, added docs about return value. |
6589af3
to
4b1d81e
Compare
found a more compact way to compute the length values. |
4b1d81e
to
1fab36c
Compare
ok, now really finished. before merge, tell me whether you want to have it micro-optimized (see commits) or not, then I'll do a final rebase -i and collapse all the wanted changesets. |
Sure, I don't see why not. Let me know when it's ready. |
@codewarrior0 I'm done. |
see pyinstaller/pyinstaller#2148 also: use waf --no-lsb (the bootloader does not build without it on our wheezy32 vagrant VM)
Thanks! |
see pyinstaller/pyinstaller#2148 also: use waf --no-lsb (the bootloader does not build without it on our wheezy32 vagrant VM)
see pyinstaller/pyinstaller#2148 also: use waf --no-lsb (the bootloader does not build without it on our wheezy32 vagrant VM)
@htgoebel could you rebuild the Linux bootloader binaries please? Would make my Vagrantfile less complicated. :) |
@ThomasWaldmann done. Thanks for this fix. |
pyinstaller/pyinstaller#2148 This fixed a bug that was most apparent in the linux binary. It would manifest as being unable to launch openvpn as a subprocess shell commands because of the dirty environment.
rather:
also:
implement pyi_strjoin (oh the joys of string processing in C!)
for more info, see #625, #1759 and the comments in the changeset.