Hi all, Since there is more than one user interested in old glibc versions, does that mean we might be able to get the support into mainline?
Thanks in advance, David > -----Original Message----- > From: yin sun [mailto:[email protected]] > Sent: Saturday, 18 May 2013 12:51 AM > To: David OShea > Cc: Brosseau, Yannick; [email protected] > Subject: Re: [lttng-dev] Patches to enable building on CentOS 5.x > (glibc 2.5) > > Support lower version of glibc does provide value. In my case, it will > enable me easily port to existing production system, which is always > several versions behind. > > Thanks, > /Yin > > On Thu, May 16, 2013 at 11:52 PM, David OShea <[email protected]> > wrote: > > Hi Yannick, > > > > > > > > Yes, we patched the latest (as of around a month ago) versions to > work on > > CentOS 5. Sorry, I neglected to mention that this is for UST only, > not > > kernel tracing, hence my not saying anything about the modules! > > > > > > > > If the changes aren't going to go upstream into the git repositories, > I > > imagine there is more chance of the CentOS 5 support becoming broken > - > > something could be committed upstream that requires further patching, > or > > conflicts with the patches. In this case, then, I don't think EPEL > packages > > would help us much, and quite possibly nobody else is interested in > CentOS 5 > > :) Also, we needed to backport some lttng-ust commits from master to > get > > support for dynamic trace providers to work, so we're more interested > in > > seeing future releases include the changes than seeing a patched > version of > > the current release, and therefore I don't think there would be any > value in > > us moving to an EPEL package for the same version of LTTng that we're > > already using. > > > > > > > > I can certainly provide the patches to you anyway, but I'm not so > keen to > > spend time improving them if they're not going upstream, e.g. one > thing I > > think needs to be investigated is whether the kernel versions > provided by > > CentOS 5 include the system calls that we had to add wrappers for; I > haven't > > paid any attention to what kernel version I'm using, I'm not sure if > it is a > > standard CentOS 5 one. > > > > > > > > Thanks! > > David > > > > > > > > > > > > From: Brosseau, Yannick [mailto:[email protected]] > > Sent: Friday, 17 May 2013 12:44 AM > > To: David OShea > > Cc: [email protected] > > Subject: Re: [lttng-dev] Patches to enable building on CentOS 5.x > (glibc > > 2.5) > > > > > > > > Hi, > > > > So you made it work with CentOS 5? > > > > I don't know if we want it upstream, but I could maybe use them to > build a > > package for EPEL5. > > > > Yannick > > > > > > > > On Wed, May 15, 2013 at 7:38 AM, David OShea > <[email protected]> > > wrote: > > > > Hi, > > > > Would contributions of patches to enable lttng-tools and lttng-ust to > build > > with glibc 2.5 (as is shipped with CentOS 5.x) and to enable lttng- > gen-tp to > > run with Python 2.4 (as shipped on CentOS 5.x) be accepted? > > > > What is missing from glibc 2.5 is: > > > > - a system call wrapper for sched_getcpu() > > - a system call wrapper for sync_file_range() > > - htobe32() and other similar endian conversion functions > > > > babeltrace and userspace-rcu did not require patching. > > > > Thanks in advance, > > David > > > > P.S. If you see this, thanks for all your recent replies, Mathieu, I > will > > try to get back to you soon! > > > > --------------------------------------------------------------------- > - > > The information contained in this transmission may be confidential. > Any > > disclosure, copying, or further distribution of confidential > information is > > not permitted unless such privilege is explicitly granted in writing > by > > Quantum. Quantum reserves the right to have electronic > communications, > > including email and attachments, sent across its networks filtered > through > > anti virus and spam software programs and retain such messages in > order to > > comply with applicable data security and retention requirements. > Quantum is > > not responsible for the proper and complete transmission of the > substance of > > this communication or for any delay in its receipt. > > > > _______________________________________________ > > lttng-dev mailing list > > [email protected] > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > > > > > > > > > -- > > Yannick Brosseau > > yannickbrosseau.com > > > > > > _______________________________________________ > > lttng-dev mailing list > > [email protected] > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > > _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
