From: Vineet G. <Vin...@sy...> - 2012-11-23 11:09:57
|
Hi, I'm building the current tip of OProfile (from git) against uClibc 0.9.30.3 - I know it's a dated a version, but the issue will happen on any recent uClibc. Build seems to be failing for not availability of query_module. -------------->8------------------- liblegacy/liblegacy.a(opd_kernel.o): In function `opd_drop_module_sample': /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:283: undefined reference to `query_module' /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:297: undefined reference to `query_module' -------------->8------------------- uClibc only provides this symbol if UCLIBC_LINUX_MODULE_24, but obvious that can't be enabled in my setup we are actually using a 3.2 kernel. The correct fix would be to have a configure option to disable any 2.4 isms at oprofile build time - which I presume doesn't already exist - from the looks of configure script. So in the short term will an equivalent of following be sufficient. diff --git a/daemon/liblegacy/p_module.h b/daemon/liblegacy/p_module.h index 9367508..06f1bad 100644 --- a/daemon/liblegacy/p_module.h +++ b/daemon/liblegacy/p_module.h @@ -182,7 +182,8 @@ struct module_info #define NEW_MOD_INITIALIZING 64 int sys_init_module(char const * name, const struct module *); -int query_module(char const * name, int which, void *buf, size_t bufsize, +int __attribute__((weak)) +query_module(char const * name, int which, void *buf, size_t bufsize, size_t *ret); I can cook a formal patch if people agree or a completely different one. Note that others have ran into this issue in the past as well. .e.g. http://lists.uclibc.org/pipermail/uclibc/2009-February/042054.html Other projects have to add their own workarounds. It would be nice if Oprofile fixes this once-n-for-all. FWIW this is for ARC architecture currently discussed on lkml for inclusion Thx, -Vineet |
From: Vineet G. <Vin...@sy...> - 2012-11-23 08:54:43
|
Hi, I'm building the current tip of OProfile (from git) against uClibc 0.9.30.3 - I know it's a dated a version, but the issue will happen on any recent uClibc. Build seems to be failing for not availability of query_module. -------------->8------------------- liblegacy/liblegacy.a(opd_kernel.o): In function `opd_drop_module_sample': /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:283: undefined reference to `query_module' /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:297: undefined reference to `query_module' -------------->8------------------- uClibc only provides this symbol if UCLIBC_LINUX_MODULE_24, but obvious that can't be enabled in my setup we are actually using a 3.2 kernel. I presume the correct fix would be to have a configure option to disable any 2.4 isms at oprofile build time - which I presume doesn't already exist - from the looks of configure script. So in the short term will an equivalent of following be sufficient. diff --git a/daemon/liblegacy/p_module.h b/daemon/liblegacy/p_module.h index 9367508..06f1bad 100644 --- a/daemon/liblegacy/p_module.h +++ b/daemon/liblegacy/p_module.h @@ -182,7 +182,8 @@ struct module_info #define NEW_MOD_INITIALIZING 64 int sys_init_module(char const * name, const struct module *); -int query_module(char const * name, int which, void *buf, size_t bufsize, +int __attribute__((weak)) +query_module(char const * name, int which, void *buf, size_t bufsize, size_t *ret); I can cook a formal patch if people agree. Note that others have ran into this issue in the past as well. .e.g. http://lists.uclibc.org/pipermail/uclibc/2009-February/042054.html Other projects have to add their own workarounds. It would be nice if Oprofile fixes this once-n-for-all. FWIW this is for ARC architecture currently discussed on lkml for inclusion Thx, -Vineet |
From: Maynard J. <may...@us...> - 2012-11-26 21:17:47
|
On 11/23/2012 05:03 AM, Vineet Gupta wrote: > Hi, > > I'm building the current tip of OProfile (from git) against uClibc > 0.9.30.3 - I know it's a dated a version, but the issue will happen on > any recent uClibc. > > Build seems to be failing for not availability of query_module. > > -------------->8------------------- > liblegacy/liblegacy.a(opd_kernel.o): In function `opd_drop_module_sample': > /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:283: > undefined reference to `query_module' > /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:297: > undefined reference to `query_module' > -------------->8------------------- > > uClibc only provides this symbol if UCLIBC_LINUX_MODULE_24, but obvious > that can't be enabled in my setup we are actually using a 3.2 kernel. > > The correct fix would be to have a configure option to disable > any 2.4 isms at oprofile build time - which I presume doesn't already > exist - from the looks of configure script. So in the short term will an > equivalent of following be sufficient. > > diff --git a/daemon/liblegacy/p_module.h b/daemon/liblegacy/p_module.h > index 9367508..06f1bad 100644 > --- a/daemon/liblegacy/p_module.h > +++ b/daemon/liblegacy/p_module.h > @@ -182,7 +182,8 @@ struct module_info > #define NEW_MOD_INITIALIZING 64 > > int sys_init_module(char const * name, const struct module *); > -int query_module(char const * name, int which, void *buf, size_t bufsize, > +int __attribute__((weak)) > +query_module(char const * name, int which, void *buf, size_t bufsize, > size_t *ret); > > I can cook a formal patch if people agree or a completely different one. Vineet, Thanks for bringing this to our attention. Support for linux version 2.4 was technically removed in OProfile 0.9.8 (see bug http://sourceforge.net/tracker/?func=detail&atid=116191&aid=3412940&group_id=16191), but apparently we missed the fact that liblegacy should have been removed as well. So, *Will* or anyone else . . . do you see any need for keeping liblegacy anymore? -Maynard > > Note that others have ran into this issue in the past as well. .e.g. > http://lists.uclibc.org/pipermail/uclibc/2009-February/042054.html > Other projects have to add their own workarounds. It would be nice if > Oprofile fixes this once-n-for-all. > > FWIW this is for ARC architecture currently discussed on lkml for inclusion > > Thx, > -Vineet > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Vineet G. <Vin...@sy...> - 2012-11-30 11:41:18
|
On Tuesday 27 November 2012 02:47 AM, Maynard Johnson wrote: > On 11/23/2012 05:03 AM, Vineet Gupta wrote: >> Hi, >> >> I'm building the current tip of OProfile (from git) against uClibc >> 0.9.30.3 - I know it's a dated a version, but the issue will happen on >> any recent uClibc. >> >> Build seems to be failing for not availability of query_module. >> >> -------------->8------------------- >> liblegacy/liblegacy.a(opd_kernel.o): In function `opd_drop_module_sample': >> /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:283: >> undefined reference to `query_module' >> /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:297: >> undefined reference to `query_module' >> -------------->8------------------- >> >> uClibc only provides this symbol if UCLIBC_LINUX_MODULE_24, but obvious >> that can't be enabled in my setup we are actually using a 3.2 kernel. >> >> The correct fix would be to have a configure option to disable >> any 2.4 isms at oprofile build time - which I presume doesn't already >> exist - from the looks of configure script. So in the short term will an >> equivalent of following be sufficient. >> >> diff --git a/daemon/liblegacy/p_module.h b/daemon/liblegacy/p_module.h >> index 9367508..06f1bad 100644 >> --- a/daemon/liblegacy/p_module.h >> +++ b/daemon/liblegacy/p_module.h >> @@ -182,7 +182,8 @@ struct module_info >> #define NEW_MOD_INITIALIZING 64 >> >> int sys_init_module(char const * name, const struct module *); >> -int query_module(char const * name, int which, void *buf, size_t bufsize, >> +int __attribute__((weak)) >> +query_module(char const * name, int which, void *buf, size_t bufsize, >> size_t *ret); >> >> I can cook a formal patch if people agree or a completely different one. > Vineet, > Thanks for bringing this to our attention. Support for linux version 2.4 was technically removed in OProfile 0.9.8 (see bug http://sourceforge.net/tracker/?func=detail&atid=116191&aid=3412940&group_id=16191), but apparently we missed the fact that liblegacy should have been removed as well. > > So, *Will* or anyone else . . . do you see any need for keeping liblegacy anymore? Ping ! -Vineet |
From: Maynard J. <may...@us...> - 2012-11-30 15:20:51
|
On 11/30/2012 05:25 AM, Vineet Gupta wrote: > On Tuesday 27 November 2012 02:47 AM, Maynard Johnson wrote: >> On 11/23/2012 05:03 AM, Vineet Gupta wrote: >>> Hi, >>> >>> I'm building the current tip of OProfile (from git) against uClibc >>> 0.9.30.3 - I know it's a dated a version, but the issue will happen on >>> any recent uClibc. >>> >>> Build seems to be failing for not availability of query_module. >>> >>> -------------->8------------------- >>> liblegacy/liblegacy.a(opd_kernel.o): In function `opd_drop_module_sample': >>> /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:283: >>> undefined reference to `query_module' >>> /home/vineetg/arc/github/oprofile/daemon/liblegacy/opd_kernel.c:297: >>> undefined reference to `query_module' >>> -------------->8------------------- >>> >>> uClibc only provides this symbol if UCLIBC_LINUX_MODULE_24, but obvious >>> that can't be enabled in my setup we are actually using a 3.2 kernel. >>> >>> The correct fix would be to have a configure option to disable >>> any 2.4 isms at oprofile build time - which I presume doesn't already >>> exist - from the looks of configure script. So in the short term will an >>> equivalent of following be sufficient. >>> >>> diff --git a/daemon/liblegacy/p_module.h b/daemon/liblegacy/p_module.h >>> index 9367508..06f1bad 100644 >>> --- a/daemon/liblegacy/p_module.h >>> +++ b/daemon/liblegacy/p_module.h >>> @@ -182,7 +182,8 @@ struct module_info >>> #define NEW_MOD_INITIALIZING 64 >>> >>> int sys_init_module(char const * name, const struct module *); >>> -int query_module(char const * name, int which, void *buf, size_t bufsize, >>> +int __attribute__((weak)) >>> +query_module(char const * name, int which, void *buf, size_t bufsize, >>> size_t *ret); >>> >>> I can cook a formal patch if people agree or a completely different one. >> Vineet, >> Thanks for bringing this to our attention. Support for linux version 2.4 was technically removed in OProfile 0.9.8 (see bug http://sourceforge.net/tracker/?func=detail&atid=116191&aid=3412940&group_id=16191), but apparently we missed the fact that liblegacy should have been removed as well. >> >> So, *Will* or anyone else . . . do you see any need for keeping liblegacy anymore? > > Ping ! I'll start working on a patch to remove liblegacy. -Maynard > > -Vineet > |