Re: Problem build 4.0.3 on Tru64 5.1A

[Chris Adams <cmadams hiwaay net>]

Once upon a time, Tim Mooney <mooney@dogbert.cc.ndsu.NoDak.edu> said:
> In regard to: Re: Problem build 4.0.3 on Tru64 5.1A, Chris Adams said (at...:
> 
> >To follow up to my own message (since nobody else has):
> 
> I started to, since I was able to compile 4.0.3 with the vendor compiler
> on 5.1 (I don't have 5.1A at this point), but I got interrupted.

What did you have to do to make rpm compile with the Compaq compiler?
It probably doesn't matter (since I don't have a license for the DEC
C++, I have to use gcc anyway).

> >Once upon a time, Chris Adams <cmadams@hiwaay.net> said:
> >> I am trying to build rpm 4.0.3 on a new install of Compaq Tru64 5.1A.  I
> >> built gcc-3.0.2 and zlib-1.1.3 (in a special directory; I'm trying to
> ><snip>
> >> db3.c:601:45: macro "stat" passed 3 arguments, but takes just 2
> >
> >This happens because on Tru64, stat() is defined as a macro (with two
> >arguments).  The referenced line in rpmdb/db3.c is:
> >
> >    rc = db->stat(db, &dbi->dbi_stats, flags);
> >
> >which the C preprocessor tries to expand with the stat() macro.
> 
> Hmmm, I don't see any warnings related to this from the Compaq C compiler
> or preprocessor.  That means either:
> 
> 1) Gcc's cpp is doing something it *shouldn't* be by treating
> db->stat() as a call to the macro `stat()'.
> 
> or
> 
> 2) Compaq's cpp isn't doing something it should be (either warning about
> the questionable use if it's actually expanding the stat above as the
> stat() macro, or perhaps it's not expanding the db->stat as the stat macro
> and it should be {I'm skeptical about *that*, though}).

or

3) The sys/stat.h header file only declares stat as a macro if you are
not using the Compaq C compiler (they use a Compaq exentsion to change
stat() into __F64_stat() for their compiler).

I ended up "fixing" this with:

diff -urN rpm-4.0.3-dist/rpmdb/db3.c rpm-4.0.3/rpmdb/db3.c
--- rpm-4.0.3-dist/rpmdb/db3.c	Sat Sep 15 16:22:36 2001
+++ rpm-4.0.3/rpmdb/db3.c	Sun Dec 23 12:55:24 2001
@@ -587,6 +587,11 @@
 {
     DB * db = dbi->dbi_db;
     int rc = 0;
+#if DB_VERSION_MAJOR == 3 && DB_VERSION_MINOR == 3
+    int (*stfunc) (DB *, void *, u_int32_t);
+#else
+    int (*stfunc) (DB *, void *, void *(*)(size_t), u_int32_t);
+#endif
 
     if (db == NULL) return -2;
 #if defined(DB_FAST_STAT)
@@ -596,11 +601,12 @@
 #endif
 	flags = 0;
     dbi->dbi_stats = _free(dbi->dbi_stats);
+    stfunc = db->stat;
 /* XXX 3.3.4 change. */
 #if DB_VERSION_MAJOR == 3 && DB_VERSION_MINOR == 3
-    rc = db->stat(db, &dbi->dbi_stats, flags);
+    rc = stfunc(db, &dbi->dbi_stats, flags);
 #else
-    rc = db->stat(db, &dbi->dbi_stats, NULL, flags);
+    rc = stfunc(db, &dbi->dbi_stats, NULL, flags);
 #endif
     rc = cvtdberr(dbi, "db->stat", rc, _debug);
     return rc;

Not pretty, but it works.

The other problem I've run into is that when building with the included
db3, no check is made to see if the thread library is needed (-lpthread
is needed with db3 on Tru64), so the make bombs trying to link
tools/dumpdb.  For my build, I've changed configure to always link with
the thread library, but I don't know what the "best" way to do this
would be (since you can't do the test at configure time for the included
library).

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.