Skip to content
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

Fedora 27/glibc 2.26 support #126

Closed
omajid opened this issue Aug 31, 2017 · 8 comments
Closed

Fedora 27/glibc 2.26 support #126

omajid opened this issue Aug 31, 2017 · 8 comments
Assignees

Comments

@omajid
Copy link
Member

omajid commented Aug 31, 2017

Fedora 27 uses glibc 2.26. This introduces some incompatible build-time changes. See https://sourceware.org/glibc/wiki/Release/2.26#Packaging_Changes for more details.

So Fedora 27 (as well as any other distribution using glibc 2.26) will need some additional fixes:

For now, we are carrying these as: https://pagure.io/fedora-dotnet/blob/f0c2fa0abb63c100a494d417c26036879e65f8f1/f/f27-libc.patch

@omajid omajid changed the title Fedora 27 support Fedora 27/glibc 2.26 support Aug 31, 2017
@dleeapho
Copy link
Contributor

dleeapho commented Sep 5, 2017

Fedora 27 GAs in October (probably).

@dleeapho dleeapho added this to the S124 Sept 11- Sept 29 (9/11/2017) milestone Sep 5, 2017
@omajid
Copy link
Member Author

omajid commented Nov 21, 2017

I am going to look into opening a PR for this. Should I just add the fixes under patches or would it be better to update coreclr and core-setup to newer commits that include this fix?

@dagood
Copy link
Member

dagood commented Nov 21, 2017

Thanks! Best to update the submodules--they should generally be able to stay in sync with release/2.0.0 for CoreCLR/CoreFX/Core-Setup now.

@omajid
Copy link
Member Author

omajid commented Nov 21, 2017

Those fixes were merged into master for coreclr and core-setup. They are not in release/2.0.0. Do you think it would be better to try and get those merged into the release/2.0.0 branches for both? And master of source-build tracks release/2.0.0 for both of those?

@dagood
Copy link
Member

dagood commented Nov 21, 2017

The default source-build branch is dev/release/2.0, which points to core* release/2.0.0 for 2.0 servicing.

  • If this issue needs to be fixed for 2.0 servicing, the fix should be ported to the core* release/2.0.0 branches and source-build dev/release/2.0 updated.
  • If it needs to be fixed for 2.1+, updating source-build master to the newest core* masters is correct.

@omajid
Copy link
Member Author

omajid commented Nov 21, 2017

Thanks for the hints.

It looks to me like source-builds's master branch points to core-setup commit 1732b0a which is the release/2.0.2 branch. coreclr also points to the release/2.0.0 branch. Updating to master would be more disruptive and will probably introduce more changes.

I will work on porting the fixes to the release/2.0.0 branches of core-setup and coreclr.

@dagood
Copy link
Member

dagood commented Nov 21, 2017

Ah, sorry about that, I remembered #268 (updating source-build master to track masters) and assumed it had gone in. Yeah, that Core-Setup commit is 2.0.2 which is built out of the Core-Setup release/2.0.0 branch. (The Core-Setup branch name ideally would be release/2.0 to be clearer.)

@markwilkie markwilkie removed this from the S124 Sept 11- Sept 29 (9/11/2017) milestone Nov 22, 2017
@omajid
Copy link
Member Author

omajid commented Apr 12, 2018

As far as I can tell, we now use recent enough versions of coreclr and corefx that all the fixes are now available out of the box.

@omajid omajid closed this as completed Apr 12, 2018
@markwilkie markwilkie added this to the S134 Apr 09 - Apr 27 (4/9/2018) milestone Apr 12, 2018
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

No branches or pull requests

4 participants