Skip to content

Backporting fixed boost::python::exec_file to v1.58.0 - #183

Closed
aambrosano wants to merge 2 commits into
boostorg:developfrom
aambrosano:backport-exec_file-crash
Closed

Backporting fixed boost::python::exec_file to v1.58.0#183
aambrosano wants to merge 2 commits into
boostorg:developfrom
aambrosano:backport-exec_file-crash

Conversation

@aambrosano

Copy link
Copy Markdown

Backporting src/exec.cpp from boost 1.59 to 1.58 to fix segmentation fault. It should allow any Ubuntu 16.04 (shipping boost 1.58) user to run boost::python::exec_file without segmentation faults.

The fix is related to #15 and #19.

I guess boost 1.59 has been already tested so there shouldn't be any problem, but in any case here is a script for testing the change with python 2.7.

@stefanseefeld

Copy link
Copy Markdown
Member

I don't quite understand what you are trying to do here. You mention "backporting from 1.59 to 1.58", but you submit a PR against develop, which is in sync with the latest release, i.e. 1.66. If you want to backport anything, shouldn't it be from develop, to some other stable branch somewhere else ?

@aambrosano

Copy link
Copy Markdown
Author

What I am trying to do is to update only boost 1.58 related commits, but as I see there isn't any branch for old releases, just the "boost_1_xx_0" tags, that's where I got it wrong.

Everything went apparently fine on my side until I got to the pull request phase (I forked and patched starting from boost_1_58_0), but now I would need to merge on top of a "boost_1_58_0" branch in order to update only the source code for the old version. Do you think anything like this is possible?

@stefanseefeld

Copy link
Copy Markdown
Member

If I understand correctly you want to patch the 1.58 release (with commits from the develop branch). What do you want to do with that patched version ? Will that be the basis for new Ubuntu packages ? Or just your personal build ?
As a start, you may want to fork this repo, then you can add a "1.58" branch to which you can backport (or "cherry-pick") any later commits. As you say, this repo doesn't have stable branches for past releases which would serve similar purposes, it only has tags.
If such branches become useful to more people, we may consider merging them back into this repo. But as of now, I'm hesitant, as this implies additional maintenance work, which I'd prefer to delegate to those who need it (e.g., you).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants