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.

Sign up for GitHub

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

Jump to bottom

Public releases and release candidates should be packaged for older Linux distributions #145

Open
milesrout opened this issue Nov 20, 2019 · 5 comments
Open

Public releases and release candidates should be packaged for older Linux distributions #145

milesrout opened this issue Nov 20, 2019 · 5 comments
Assignees
@milesrout
Labels
build-process issues relating to the build, development or release processes enhancement very small feature or non-feature enhancement stale issues that are very old and the original reporter may no longer be able to verify
Milestone
0.2

Comments

@milesrout
Copy link
Member

Currently our 'releases' for Linux don't run on CentOS 7 for example.

We will need an automated build process to package Trillek for lots of different distros and versions of distros.

We could also look into snap/flatpak.
@milesrout milesrout added enhancement very small feature or non-feature enhancement build-process issues relating to the build, development or release processes labels Nov 20, 2019
@milesrout milesrout added this to the 0.12 milestone Nov 20, 2019
@milesrout milesrout self-assigned this Nov 20, 2019
@milesrout
Copy link
Member Author

This is related to #144

@ghost
Copy link

ghost commented Nov 24, 2019 •
edited by ghost
Loading

All third-party dependencies are linked statically, so this already resolves a lot of distribution issues. Was this intentional?

#144 seems to be about the CI builds being built with a too recent version of GCC, causing ABI incompatibility. Maybe we should consider using -static-libstdc++ or a different compiler.

@adam4813
Copy link
Member

Yeah static was intentional for the releases as the barrier to use is much lower. Once the build process was fixed and more actual development had started the goal was to refine the build process more or expand the docs on how to build it in other ways so that older linux, for example, could play.

@adam4813 adam4813 added stale issues that are very old and the original reporter may no longer be able to verify and removed stale issues that are very old and the original reporter may no longer be able to verify labels May 16, 2020
@adam4813
Copy link
Member

adam4813 commented Apr 1, 2021

@milesrout is this still something to work towards, or what's the thoughts on it?

I am just trying to remove stale issues (even if they maybe still valid) just to help with focus on the now.

@adam4813 adam4813 added the stale issues that are very old and the original reporter may no longer be able to verify label Apr 1, 2021
@milesrout
Copy link
Member Author

You can filter out stale issues in searches. I do not think we should get rid of issues just because they're a bit old if they're still valid.

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

@milesrout milesrout

Labels
build-process issues relating to the build, development or release processes enhancement very small feature or non-feature enhancement stale issues that are very old and the original reporter may no longer be able to verify
Projects
None yet
Milestone
0.2
Development

No branches or pull requests
2 participants
@adam4813 @milesrout