Davide Italiano via llvm-dev
2017-Oct-04 22:17 UTC
[llvm-dev] Minimal glibc version supported by LLVM build
On Oct 4, 2017 2:31 PM, "Rui Ueyama via llvm-dev" <llvm-dev at lists.llvm.org> wrote: On Wed, Oct 4, 2017 at 2:19 PM, Philip Reames <listmail at philipreames.com> wrote:> Our build system is setup to deliberately use a very old environment. > We've found that's one of the most reliable easy ways to ensure we don't > accidentally introduce a dependency on a newer system library than > intended. This lets us ship prebuilt binaries which run on a wide spectrum > of systems. We're going to chat internally and check to see if we can roll > this forward a bit, but supporting an older glibc is definitely going to be > somewhat we want. Exactly *how* old might be flexible, but I have to check. > > Rui, let me turn your question around on you. What version of glibc would > you like to be our minimum? And why? Is there a good reason to move this > forward? >I don't have a clear answer to your question, and I don't think I'm a person who can set a standard, but maybe, 11 years is a bit too old. I don't think we want to intentionally break it, and if it can be supported by adding a few lines to CMakeFiles, we probably should. However, IMO, this should be done by best-effort basis. I don't think we need to immediately revert a patch if broke a 11 year old system. I don't necessarily agree with the last point. I think a policy would help here, and it should be based on the number of annoyances supporting an old version cause. This is akin to what we did for, e.g. VS 2013. If supporting a old version doesn't allow the project to reasonably move forward, we should consider an upgrade. FWIW, in this case I don't think the feature introduced is worth the bump, but your mileage may vary. I'd like to add that "11 years old system" means nothing. In fact, I think we should aim supporting even older systems whenever possible. Thanks, -- Davide I think we need to establish and document a minimum supported version> here. I'm open to debating what that version should be, but the current > lack of clarity is clearly problematic. > > Philip > > p.s. Sorry about the confusion earlier about CentOS. I'd misunderstood an > statement in internal conversation and repeated the information without > checking. While true that the build failed on a CentOS 6.4 system, it was > being built against a non-default (older) glibc. > > p.p.s. This brought up the point internally that we really should have a > public build bot for the configuration we care about. I need to talk that > over internally, but this seems like something we can make happen. > > On 10/04/2017 12:38 PM, Rui Ueyama via llvm-dev wrote: > > Serguei, > > glibc 2.5 was released 11 years ago, so I wonder what operating system you > are using now. > > On Wed, Oct 4, 2017 at 12:08 AM, Serguei Katkov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi All, >> >> >> >> The landed patch https://reviews.llvm.org/D38481 introduced the usage of >> CPU_COUNT defined in glibc sched.h header. >> >> I failed to find this symbol in sched.h of glibc version 2.5-24, so >> compilation just fails. >> >> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: >> In function ‘unsigned int llvm::hardware_concurrency()’: >> >> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26: >> error: ‘CPU_COUNT’ was not declared in this scope >> >> return CPU_COUNT(&Set); >> >> ^ >> >> >> >> It is buildable with newest version of glibc. >> >> I tried to find a requirements for glibc version in LLVM documentation >> but failed. >> >> So I wonder whether there is such requirement or not. >> >> Could anyone point me to this documentation? >> >> >> >> I'm trying to understand whether patch is wrong which relies on >> availability of library but does not check the symbol itself or this >> version of glibc is not supported. >> >> >> >> Thank you, >> >> Serguei. >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/9e9629d8/attachment.html>
Rui Ueyama via llvm-dev
2017-Oct-04 22:48 UTC
[llvm-dev] Minimal glibc version supported by LLVM build
On Wed, Oct 4, 2017 at 3:17 PM, Davide Italiano <davide.italiano at gmail.com> wrote:> > > On Oct 4, 2017 2:31 PM, "Rui Ueyama via llvm-dev" <llvm-dev at lists.llvm.org> > wrote: > > On Wed, Oct 4, 2017 at 2:19 PM, Philip Reames <listmail at philipreames.com> > wrote: > >> Our build system is setup to deliberately use a very old environment. >> We've found that's one of the most reliable easy ways to ensure we don't >> accidentally introduce a dependency on a newer system library than >> intended. This lets us ship prebuilt binaries which run on a wide spectrum >> of systems. We're going to chat internally and check to see if we can roll >> this forward a bit, but supporting an older glibc is definitely going to be >> somewhat we want. Exactly *how* old might be flexible, but I have to check. >> >> Rui, let me turn your question around on you. What version of glibc >> would you like to be our minimum? And why? Is there a good reason to move >> this forward? >> > I don't have a clear answer to your question, and I don't think I'm a > person who can set a standard, but maybe, 11 years is a bit too old. I > don't think we want to intentionally break it, and if it can be supported > by adding a few lines to CMakeFiles, we probably should. However, IMO, this > should be done by best-effort basis. I don't think we need to immediately > revert a patch if broke a 11 year old system. > > > I don't necessarily agree with the last point. > I think a policy would help here, and it should be based on the number of > annoyances supporting an old version cause. This is akin to what we did > for, e.g. VS 2013. If supporting a old version doesn't allow the project to > reasonably move forward, we should consider an upgrade. FWIW, in this case > I don't think the feature introduced is worth the bump, but your mileage > may vary. > I'd like to add that "11 years old system" means nothing. In fact, I think > we should aim supporting even older systems whenever possible. >I agree that we should support old systems whenever possible. There's no reason to intentionally break it, and it is generally good if it works on a large number of systems including old ones. But speaking of this instance, I feel like reverting a patch as well as other related patches immediately when it's found it broke a very old system was a bit too hasty. If we want to keep everything work with an old system all the time, we should set up a buildbot with an old version of an operating system. Otherwise, I think a more time should be given to developers to discuss and fix an issue in the main repository.> Thanks, > > -- > Davide > > > I think we need to establish and document a minimum supported version >> here. I'm open to debating what that version should be, but the current >> lack of clarity is clearly problematic. >> >> Philip >> >> p.s. Sorry about the confusion earlier about CentOS. I'd misunderstood >> an statement in internal conversation and repeated the information without >> checking. While true that the build failed on a CentOS 6.4 system, it was >> being built against a non-default (older) glibc. >> >> p.p.s. This brought up the point internally that we really should have a >> public build bot for the configuration we care about. I need to talk that >> over internally, but this seems like something we can make happen. >> >> On 10/04/2017 12:38 PM, Rui Ueyama via llvm-dev wrote: >> >> Serguei, >> >> glibc 2.5 was released 11 years ago, so I wonder what operating system >> you are using now. >> >> On Wed, Oct 4, 2017 at 12:08 AM, Serguei Katkov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi All, >>> >>> >>> >>> The landed patch https://reviews.llvm.org/D38481 introduced the usage >>> of CPU_COUNT defined in glibc sched.h header. >>> >>> I failed to find this symbol in sched.h of glibc version 2.5-24, so >>> compilation just fails. >>> >>> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: >>> In function ‘unsigned int llvm::hardware_concurrency()’: >>> >>> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26: >>> error: ‘CPU_COUNT’ was not declared in this scope >>> >>> return CPU_COUNT(&Set); >>> >>> ^ >>> >>> >>> >>> It is buildable with newest version of glibc. >>> >>> I tried to find a requirements for glibc version in LLVM documentation >>> but failed. >>> >>> So I wonder whether there is such requirement or not. >>> >>> Could anyone point me to this documentation? >>> >>> >>> >>> I'm trying to understand whether patch is wrong which relies on >>> availability of library but does not check the symbol itself or this >>> version of glibc is not supported. >>> >>> >>> >>> Thank you, >>> >>> Serguei. >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> >> >> _______________________________________________ >> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/f62ea3bf/attachment.html>
Philip Reames via llvm-dev
2017-Oct-05 16:31 UTC
[llvm-dev] Minimal glibc version supported by LLVM build
On 10/04/2017 03:48 PM, Rui Ueyama wrote:> On Wed, Oct 4, 2017 at 3:17 PM, Davide Italiano > <davide.italiano at gmail.com <mailto:davide.italiano at gmail.com>> wrote: > > > > On Oct 4, 2017 2:31 PM, "Rui Ueyama via llvm-dev" > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Wed, Oct 4, 2017 at 2:19 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> > wrote: > > Our build system is setup to deliberately use a very old > environment. We've found that's one of the most reliable > easy ways to ensure we don't accidentally introduce a > dependency on a newer system library than intended. This > lets us ship prebuilt binaries which run on a wide > spectrum of systems. We're going to chat internally and > check to see if we can roll this forward a bit, but > supporting an older glibc is definitely going to be > somewhat we want. Exactly *how* old might be flexible, > but I have to check. > > Rui, let me turn your question around on you. What > version of glibc would you like to be our minimum? And > why? Is there a good reason to move this forward? > > I don't have a clear answer to your question, and I don't > think I'm a person who can set a standard, but maybe, 11 years > is a bit too old. I don't think we want to intentionally break > it, and if it can be supported by adding a few lines to > CMakeFiles, we probably should. However, IMO, this should be > done by best-effort basis. I don't think we need to > immediately revert a patch if broke a 11 year old system. > > > I don't necessarily agree with the last point. > I think a policy would help here, and it should be based on the > number of annoyances supporting an old version cause. This is akin > to what we did for, e.g. VS 2013. If supporting a old version > doesn't allow the project to reasonably move forward, we should > consider an upgrade. FWIW, in this case I don't think the feature > introduced is worth the bump, but your mileage may vary. > I'd like to add that "11 years old system" means nothing. In fact, > I think we should aim supporting even older systems whenever possible. > > > I agree that we should support old systems whenever possible. There's > no reason to intentionally break it, and it is generally good if it > works on a large number of systems including old ones. > > But speaking of this instance, I feel like reverting a patch as well > as other related patches immediately when it's found it broke a very > old system was a bit too hasty. If we want to keep everything work > with an old system all the time, we should set up a buildbot with an > old version of an operating system. Otherwise, I think a more time > should be given to developers to discuss and fix an issue in the main > repository.In retrospect, I think I agree. We were probably too quick to revert here. When I asked Daniel to do so, I was working with the flawed assumption that this was relevant for any REHL 6 based distro, but I should have checked that more thoroughly before we acted.> Thanks, > > -- > Davide > > > I think we need to establish and document a minimum > supported version here. I'm open to debating what that > version should be, but the current lack of clarity is > clearly problematic. > > Philip > > p.s. Sorry about the confusion earlier about CentOS. I'd > misunderstood an statement in internal conversation and > repeated the information without checking. While true that > the build failed on a CentOS 6.4 system, it was being > built against a non-default (older) glibc. > > p.p.s. This brought up the point internally that we really > should have a public build bot for the configuration we > care about. I need to talk that over internally, but this > seems like something we can make happen. > > > On 10/04/2017 12:38 PM, Rui Ueyama via llvm-dev wrote: >> Serguei, >> >> glibc 2.5 was released 11 years ago, so I wonder what >> operating system you are using now. >> >> On Wed, Oct 4, 2017 at 12:08 AM, Serguei Katkov via >> llvm-dev <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi All, >> >> The landed patch https://reviews.llvm.org/D38481 >> <https://reviews.llvm.org/D38481> introduced the >> usage of CPU_COUNT defined in glibc sched.h header. >> >> I failed to find this symbol in sched.h of glibc >> version 2.5-24, so compilation just fails. >> >> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp: >> In function ‘unsigned int llvm::hardware_concurrency()’: >> >> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26: >> error: ‘CPU_COUNT’ was not declared in this scope >> >> return CPU_COUNT(&Set); >> >> ^ >> >> It is buildable with newest version of glibc. >> >> I tried to find a requirements for glibc version in >> LLVM documentation but failed. >> >> So I wonder whether there is such requirement or not. >> >> Could anyone point me to this documentation? >> >> I'm trying to understand whether patch is wrong which >> relies on availability of library but does not check >> the symbol itself or this version of glibc is not >> supported. >> >> Thank you, >> >> Serguei. >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/78de1084/attachment.html>