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

OpenDHT does not build on armel. #87

Closed
aviau opened this Issue Jul 1, 2016 · 9 comments

Comments

Projects
None yet
3 participants
@aviau
Member

aviau commented Jul 1, 2016

OpenDHT does not build on armel, see the following log:

This is the only Debian-supported architecture that OpenDHT does not build on.

Note: I am able to sponsor access to Debian porter machines. See the documentation on requesting access.

@sim590 sim590 added the bug label Jul 1, 2016

@sim590 sim590 self-assigned this Jul 1, 2016

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jul 1, 2016

Contributor

I've begun testing on armel archetecture in order to reproduce and find the bug. I'll update shortly.

Contributor

sim590 commented Jul 1, 2016

I've begun testing on armel archetecture in order to reproduce and find the bug. I'll update shortly.

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jul 1, 2016

Contributor

So the issue is definitely this, i.e. that std::future templates are not supported on armel archetecture.

@aberaud: A solution would be to use the following to disable std::future signatures when not supported.

#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) && (ATOMIC_INT_LOCK_FREE > 1)
// std::future code
#endif

I know that ring uses this feature. I'm looking for a solution for this too.

Contributor

sim590 commented Jul 1, 2016

So the issue is definitely this, i.e. that std::future templates are not supported on armel archetecture.

@aberaud: A solution would be to use the following to disable std::future signatures when not supported.

#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) && (ATOMIC_INT_LOCK_FREE > 1)
// std::future code
#endif

I know that ring uses this feature. I'm looking for a solution for this too.

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jul 1, 2016

Contributor

@aviau: Actually, if you look at DhtRunner, you can see that std::future is used for blocking on the dhtrunner internal ops queue. So, if I were to use the fix above, I'd have to implement handling of listen token return in another way which would mean a bit of code to write and it wouldn't be really beautiful with many ifdef statements. We have to ask ourselves if this is worth supporting armel archetecture.

Contributor

sim590 commented Jul 1, 2016

@aviau: Actually, if you look at DhtRunner, you can see that std::future is used for blocking on the dhtrunner internal ops queue. So, if I were to use the fix above, I'd have to implement handling of listen token return in another way which would mean a bit of code to write and it wouldn't be really beautiful with many ifdef statements. We have to ask ourselves if this is worth supporting armel archetecture.

@aviau

This comment has been minimized.

Show comment
Hide comment
@aviau

aviau Jul 1, 2016

Member

If the fix isn't too complicated, I would love to see it merged. Otherwise, I could even maintain it in Debian. All of the other Ring dependencies already build on armel. Future armel-incompatible changes will be spotted easily because the Debian CI will constantly build OpenDHT.

Member

aviau commented Jul 1, 2016

If the fix isn't too complicated, I would love to see it merged. Otherwise, I could even maintain it in Debian. All of the other Ring dependencies already build on armel. Future armel-incompatible changes will be spotted easily because the Debian CI will constantly build OpenDHT.

@aberaud

This comment has been minimized.

Show comment
Hide comment
@aberaud

aberaud Jul 2, 2016

Contributor

Do we need to support ARMv5 to be in Debian ?
This architecture is obsolete, every chip is at least ARMv7. If it doesn't support std::future it really shouldn't be our problem, we won't re-implement the weel just for that. OpenDHT requires C++11 support.

Ring makes use this OpenDHT API and of std::future in other places so it would also require work in Ring.

Contributor

aberaud commented Jul 2, 2016

Do we need to support ARMv5 to be in Debian ?
This architecture is obsolete, every chip is at least ARMv7. If it doesn't support std::future it really shouldn't be our problem, we won't re-implement the weel just for that. OpenDHT requires C++11 support.

Ring makes use this OpenDHT API and of std::future in other places so it would also require work in Ring.

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jul 2, 2016

Contributor

Do we need to support ARMv5 to be in Debian ?
This architecture is obsolete, every chip is at least ARMv7. If it doesn't support std::future it really shouldn't be our problem, we won't re-implement the weel just for that. OpenDHT requires C++11 support.

I'll let @aviau debate over this. IMO, I don't think this is necessary. Since our main page claims OpenDHT is a C++11 library, I think that the lack of support for the armel architecture is consistent.

Ring makes use this OpenDHT API and of std::future in other places so it would also require work in Ring.

OpenDHT is not binded to Ring. If the Ring project doesn't choose to support armel, this is fine. The discussion should stick to OpenDHT. If we want to speak about Ring we should do it there.

Contributor

sim590 commented Jul 2, 2016

Do we need to support ARMv5 to be in Debian ?
This architecture is obsolete, every chip is at least ARMv7. If it doesn't support std::future it really shouldn't be our problem, we won't re-implement the weel just for that. OpenDHT requires C++11 support.

I'll let @aviau debate over this. IMO, I don't think this is necessary. Since our main page claims OpenDHT is a C++11 library, I think that the lack of support for the armel architecture is consistent.

Ring makes use this OpenDHT API and of std::future in other places so it would also require work in Ring.

OpenDHT is not binded to Ring. If the Ring project doesn't choose to support armel, this is fine. The discussion should stick to OpenDHT. If we want to speak about Ring we should do it there.

@aviau

This comment has been minimized.

Show comment
Hide comment
@aviau

aviau Jul 2, 2016

Member

Do we need to support ARMv5 to be in Debian ?

No, this is not a requirement.

However, should somebody want to run OpenDHT on debian/armel and send us a patch, we will ship a patched version of OpenDHT in Debian.

Member

aviau commented Jul 2, 2016

Do we need to support ARMv5 to be in Debian ?

No, this is not a requirement.

However, should somebody want to run OpenDHT on debian/armel and send us a patch, we will ship a patched version of OpenDHT in Debian.

@aberaud

This comment has been minimized.

Show comment
Hide comment
@aberaud

aberaud Jul 2, 2016

Contributor

OpenDHT is not binded to Ring.

Sure, just wanted to make it clear that an OpenDHT patch woudn't be enough to support ARMv5 in Ring.

No, this is not a requirement. However, should somebody want to run OpenDHT on debian/armel and send us a patch, we will ship a patched version of OpenDHT in Debian.

Will OpenDHT have it's own Debian package ? 😀

The thing is, std::future is part of the core OpenDHT API. Not using it would mean to have a different core API between architectures which is very ugly and cumbersome for both us and API users. The only clean fix would be to add std::future support to armel (does clang have the same limitation?) or to cripple OpenDHT features.

Contributor

aberaud commented Jul 2, 2016

OpenDHT is not binded to Ring.

Sure, just wanted to make it clear that an OpenDHT patch woudn't be enough to support ARMv5 in Ring.

No, this is not a requirement. However, should somebody want to run OpenDHT on debian/armel and send us a patch, we will ship a patched version of OpenDHT in Debian.

Will OpenDHT have it's own Debian package ? 😀

The thing is, std::future is part of the core OpenDHT API. Not using it would mean to have a different core API between architectures which is very ugly and cumbersome for both us and API users. The only clean fix would be to add std::future support to armel (does clang have the same limitation?) or to cripple OpenDHT features.

@aberaud aberaud closed this Jul 2, 2016

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jul 2, 2016

Contributor

Will OpenDHT have it's own Debian package ?

@aviau was actually working on creating a package for OpenDHT if I'm not mistaken.

Contributor

sim590 commented Jul 2, 2016

Will OpenDHT have it's own Debian package ?

@aviau was actually working on creating a package for OpenDHT if I'm not mistaken.

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