Re: Problem build 4.0.3 on Tru64 5.1A

[Tim Mooney <mooney dogbert cc ndsu NoDak edu>]

In regard to: Re: Problem build 4.0.3 on Tru64 5.1A, Chris Adams said (at...:

>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).

Well, AFAIK rpm doesn't require a C++ compiler, so at least for rpm you
could get by with just a C compiler.  Note that DB 3.x has C++ and
Java components, but I don't believe RPM builds those bits so you
shouldn't need a C++ or Java compiler.

Comments about RPM's build:

1) Because of various issues with `configure' from sub-packages,
especially the configure wrapper Jeff has for the db3 configure, it's
non-trivial to try rebuild any of the configure machinery with updated
versions of autoconf/automake/libtool.  I ended up giving up on that
route.

2) I edited the db/configure (it's a wrapper for the real configure
script) and removed the

	--enable-shared

that's passed to db3's configure, as well as the

	-g -O2

that's stuffed into the Makefile via sed.

3) I set

	CC='cc -pthread -Wl,-oldstyle_libookup'

The -pthread handles linking with all the libraries needed for threading.
The -Wl,-oldstyle_liblookup probably isn't needed with 4.0.3, but it was
needed with older versions of RPM because the Digital/Tru64 linker always
prefers shared libraries (even if they're found later in the directories
it searches, after a static library), and with the `libdb.so' being part
of the OS, it would use that one in preference to a locally-installed
copy.

4) I generally build with `-portable' and
`-msg_disable embedcomment,longlongtype' in CFLAGS.  There's a couple
other warnings I disable, simply because the compiler generates too many
unimportant warnings when `-portable' is used on RPM's sources.

5) I configured with

	--disable-shared --disable-python --disable-nls

in addition to standard --prefix, --exec-prefix, etc.

>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 thought the comments in the header indicated there was a way to get
other compilers to use the macro, but I only took a cursory look at it
after your explanation of the problem.

>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).

Does gcc support a logical equivalent to the Compaq compiler's `-pthread'?

Tim
-- 
Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164