Re: Problem build 4.0.3 on Tru64 5.1A

[Jeff Johnson <jbj JBJ ORG>]

On Sun, Dec 23, 2001 at 06:43:40PM -0600, Tim Mooney wrote:
> 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.

Yes, the integration between rpm and db3 is quite minimal, and I think
that's the right thing to do, as rpm != db3. The main reason for incorporating
db3 in to rpm was to integrate a "standard" API rather than chasing various
and sundry db3 API nit-picks across multiple platforms, and, in addition, to be
able to uniqify db3 symbols to avoid symbol pollution in complicated toolchains
like apache/perl that can link with rpmlib. FWIW, Support for multiple versions
of db3 is not exactly an rpm feature, and causes endless support problems.

Yup, "updated versions" of autoconf/automake/libtool are quite painful
at the moment. I suggest using the same versions that I use, documented
in the top-level autogen.sh, as those versions work for me. I can/will
update to later versions as soon as I can detect some resolution to
the sorry mess of incompatibilities that I see at the moment.

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

Why are you removing --enable-shared? There's more than just db3 that
will need to be jiggered if you do so.

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

Hmmm, -pthread is odd. What are you using for locking? Even though the
pthread locking is very much The Right Thing To Do, the lack of support
for certain POSIX optional calls in the linux kernel necessitates using
other locking schemes for rpm. Remember, rpm is developed on linux, and
I simply cannot even attempt to debug dynamic locking problems on platforms
I do not have access (or the mandate) to support.

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

Nod, --disable-shared is the "jigger" I mentioned earlier.

> >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'?

There are pthread libraries and such, but, again, the support is incomplete
(technically, the appropriate term is POSIX "optional") on linux.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC