Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#541547: pcp: FTBFS on alpha: aggregate value used where an integer was expected

14 views
Skip to first unread message

Petter Reinholdtsen

unread,
Aug 30, 2009, 11:20:05 PM8/30/09
to
Looking at the source, the problem seem to be that the struct stat
member st_mtime is not the same type as time_t.

I've flagged the problematic lines with **:


static time_t last_mtim;
[...]
struct stat statbuf;

if (stat(f, &statbuf) == 0) {
/* If the modification times have changed */
#if defined(HAVE_ST_MTIME_WITH_E) && defined(HAVE_STAT_TIME_T)
#ifdef PCP_DEBUG
if (pmDebug & DBG_TRACE_PMNS) {
fprintf(stderr, "__pmHasPMNSFileChanged(%s) -> %s last=%d now=%d\n",
filename == PM_NS_DEFAULT || (__psint_t)filename == 0xffffffff ? "PM_NS_DEFAULT" : filename,
** f, (int)last_mtim, (int)statbuf.st_mtime);
}
#endif
** return ((statbuf.st_mtime == last_mtim) ? 0 : 1);
[...]
{
struct stat statbuf;
if (stat(fname, &statbuf) == 0) {
#if defined(HAVE_ST_MTIME_WITH_E)
** last_mtim = statbuf.st_mtime; /* possible struct assignment */
#elif defined(HAVE_ST_MTIME_WITH_SPEC)
last_mtim = statbuf.st_mtimespec; /* possible struct assignment */
#else
last_mtim = statbuf.st_mtim; /* possible struct assignment */
#endif
}
}

last_mtime can't be converted to int, compared to statbuf.st_mtime or
get an assignment from statbuf.st_mtime. I'm not quite sure how the
st_mtime membe variable can end up being different from time_t.
Perhaps some missing include file? The stat(2) manual page state that
these are needed:

#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

The pmns.c source only include <sys/stat.h>. If that is the solution,
here is a patch:

diff -ur pcp-2.9.0/src/libpcp/src/pmns.c pcp-2.9.0-pere/src/libpcp/src/pmns.c
--- pcp-2.9.0/src/libpcp/src/pmns.c 2009-04-24 02:20:09.000000000 +0200
+++ pcp-2.9.0-pere/src/libpcp/src/pmns.c 2009-08-31 05:06:41.000000000 +0200
@@ -16,7 +16,9 @@
* Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
*/

+#include <sys/types.h>
#include <sys/stat.h>
+#include <unistd.h>
#include <stddef.h>
#include <assert.h>
#include <ctype.h>

Happy hacking,
--
Petter Reinholdtsen

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Nathan Scott

unread,
Aug 31, 2009, 7:00:13 AM8/31/09
to

----- "Petter Reinholdtsen" <pe...@hungry.com> wrote:

> Looking at the source, the problem seem to be that the struct stat
> member st_mtime is not the same type as time_t.
>
> I've flagged the problematic lines with **:

> ...


> last_mtime can't be converted to int, compared to statbuf.st_mtime or
> get an assignment from statbuf.st_mtime. I'm not quite sure how the
> st_mtime membe variable can end up being different from time_t.

I'm not sure either.

> Perhaps some missing include file? The stat(2) manual page state
> that these are needed:

> #include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
>
> The pmns.c source only include <sys/stat.h>. If that is the
> solution, here is a patch:

It pulls in sys/types.h and unistd.h via "impl.h". But perhaps the
order is important... we really need to run a build on an alpha but
I have not been able to get access to one.

Do you have one handy? Can you confirm either resolution, if so I'm
happy to make the change, but feel like we're guessing a bit too much
here at the moment.

cheers.

--
Nathan

Petter Reinholdtsen

unread,
Aug 31, 2009, 7:30:13 AM8/31/09
to
[Nathan Scott]

> It pulls in sys/types.h and unistd.h via "impl.h". But perhaps the
> order is important... we really need to run a build on an alpha but
> I have not been able to get access to one.

I would not rule out that the ordering is important.

> Do you have one handy? Can you confirm either resolution, if so I'm
> happy to make the change, but feel like we're guessing a bit too
> much here at the moment.

I do not have an alpha available, sorry. Just saw the build error in
BTS while looking at the dependency based boot issues with pcp, and
had a look in the source to see if I had a clue how to fix it. :)

Happy hacking,
--
Petter Reinholdtsen

--

Nathan Scott

unread,
Aug 31, 2009, 4:30:11 PM8/31/09
to

----- "Petter Reinholdtsen" <pe...@hungry.com> wrote:

> [Nathan Scott]
> > It pulls in sys/types.h and unistd.h via "impl.h". But perhaps the
> > order is important... we really need to run a build on an alpha but
> > I have not been able to get access to one.
>
> I would not rule out that the ordering is important.

I was thinking about it some more last night, and I think if this
were a header/types related issue then the build would fail when
we include <sys/stat.h> because struct timespec would be undefined
as yet (and its use in struct stat is not as a pointer where it'd
be ok to forward-declare it).

Ugh. So, also, alpha headers must have something peculiar about
them in this area, as the pcp build is successful on every other
platform... just a mystery as to what that oddity is atm.

> > Do you have one handy? Can you confirm either resolution, if so
> I'm
> > happy to make the change, but feel like we're guessing a bit too
> > much here at the moment.
>
> I do not have an alpha available, sorry. Just saw the build error in
> BTS while looking at the dependency based boot issues with pcp, and
> had a look in the source to see if I had a clue how to fix it. :)

Thanks, I appreciate the effort!

cheers.

--
Nathan

0 new messages