Unable to compile rpm 5.3.6

[Sébastien Luttringer]

've an issue like in this mail: ¤http://<email address hidden>/msg04346.html and the proposed solution doesn't work
system: archlinux, kernel 2.6.37-rc5, amd64. versions: berkeley db 5.1.19, beecrypt 4.2.1, pcre 8.11.

you can see the ouput of compilation on : http://pastebin.com/7ncybUZ8

$ ll /usr/lib/libdb*
-rw-r--r-- 1 root root 2,5M 2010-11-11 04:59 /usr/lib/libdb-5.1.a
-rwxr-xr-x 1 root root 1,6M 2010-11-11 04:59 /usr/lib/libdb-5.1.so
lrwxrwxrwx 1 root root 12 2010-11-11 04:59 /usr/lib/libdb-5.so -> libdb-5.1.so
-rw-r--r-- 1 root root 2,5M 2010-11-11 04:59 /usr/lib/libdb.a
-rw-r--r-- 1 root root 2,7M 2010-11-11 04:59 /usr/lib/libdb_cxx-5.1.a
-rwxr-xr-x 1 root root 1,7M 2010-11-11 04:59 /usr/lib/libdb_cxx-5.1.so
lrwxrwxrwx 1 root root 16 2010-11-11 04:59 /usr/lib/libdb_cxx-5.so -> libdb_cxx-5.1.so
-rw-r--r-- 1 root root 2,7M 2010-11-11 04:59 /usr/lib/libdb_cxx.a
lrwxrwxrwx 1 root root 16 2010-11-11 04:59 /usr/lib/libdb_cxx.so -> libdb_cxx-5.1.so
lrwxrwxrwx 1 root root 12 2010-11-11 04:59 /usr/lib/libdb.so -> libdb-5.1.so
lrwxrwxrwx 1 root root 18 2010-12-07 12:15 /usr/lib/libdbus-1.so -> libdbus-1.so.3.5.2
lrwxrwxrwx 1 root root 18 2010-12-07 12:15 /usr/lib/libdbus-1.so.3 -> libdbus-1.so.3.5.2
-rwxr-xr-x 1 root root 272K 2010-12-07 12:15 /usr/lib/libdbus-1.so.3.5.2
lrwxrwxrwx 1 root root 23 2010-11-10 14:07 /usr/lib/libdbus-glib-1.so -> libdbus-glib-1.so.2.1.0
lrwxrwxrwx 1 root root 23 2010-11-10 14:07 /usr/lib/libdbus-glib-1.so.2 -> libdbus-glib-1.so.2.1.0
-rwxr-xr-x 1 root root 153K 2010-11-10 14:07 /usr/lib/libdbus-glib-1.so.2.1.0
lrwxrwxrwx 1 root root 19 2010-10-03 10:39 /usr/lib/libdbusmenu-qt.so -> libdbusmenu-qt.so.2
lrwxrwxrwx 1 root root 23 2010-10-03 10:39 /usr/lib/libdbusmenu-qt.so.2 -> libdbusmenu-qt.so.2.3.4
-rwxr-xr-x 1 root root 194K 2010-10-03 10:39 /usr/lib/libdbusmenu-qt.so.2.3.4

[Jeff Johnson (n3npq)]

Your build is failing to find /usr/include/db51/db.h
(see lines 562-564).

config.log will supply details about the failure to find db.h

The easiest fix will be to supply a populated /usr/include/db51/*.h.
Is there any reason you cannot do that on Arch linux?

[Sébastien Luttringer (seblu)]

Hum, it will be hard to change the path of db.h in the whole arch system. And create a soft link is not a clean solution...

We setup berkeley db with the following:
configure --prefix=/usr --enable-compat185 --enable-shared --enable-static --enable-cxx --enable-dbm
make
make install

so he create a /usr/include/db.h.

I looked in debian, and it's the same!
$ cat /etc/debian_version
6.0
$ dpkg -L libdb5.1-dev
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libdb5.1-dev
/usr/share/doc/libdb5.1-dev/copyright
/usr/share/doc/libdb5.1-dev/changelog.Debian.gz
/usr/include
/usr/include/db_185.h
/usr/include/db.h
/usr/lib
/usr/lib/libdb-5.1.la
/usr/lib/libdb-5.1.a
/usr/lib/libdb-5.so
/usr/lib/libdb.a
/usr/lib/libdb.so

So, why you don't just use the include path to find you db.h and you search in db51/db.h ?

This is also why autotools don't detect that berkeley db is missing, because he detect it. I think you should fix that in the code.

[Jeff Johnson (n3npq)]

What is "uncleanly" about the solution
 ln -s . /usr/include/db51
which I suspect is enough to get your build working.

Many linux (and unix) systems have multiple Berkeley DB versions installed,
and /usr/include/db.h isn't sufficiently reliable/portable.

Note that RPM also needs to work on non-linux, where /usr/include (and Berkeley DB)
are all installed differently to what Debian does.

This is in fact why Berkeley DB used to be bundled with RPM: for
painless reliable "no-brainer" installation. Sadly, that does
not please anyone who wishes to use "system" Berkeley DB,
a concept that is mostly meaningless when there are multiple
versions of Berkeley DB installed on the "system".

You can still build with Berkeley DB internal if you untar db-5.1.19.tar.gz
into rpm's top level directory, rename
 mv db-5.1.19 db
and then add
 --with-db=internal
 --with-dbsql=internal
You might also need
 ln -s db db51
to be able to build.

If you wish to pursue this approach I will identify and document all the steps
needed (its not hard).

> This is also why autotools don't detect that berkeley db is missing,
> because he detect it. I think you should fix that in the code.

I don't disagree, but there's no pleasing everyone, or handling
all possible ways to install Berkeley DB, including version tests
and internal <-> external, automagically using autoconf tests.

Nor is there any RPM development reason to chase every possible
Berkeley DB version everywhere. Instead, one single version is
being targeted (older versions back to db-4.5.x will work) and
with one recommended installation of Berkeley DB
(relevant to your case, /usr/include/db51/db.h is "recommended")

[Sébastien Luttringer (seblu)]

On Wed, Dec 15, 2010 at 3:31 PM, Jeff Johnson <email address hidden> wrote:
> What is "uncleanly" about the solution
>        ln -s . /usr/include/db51
> which I suspect is enough to get your build working.
Unfortunately no, this fail later. I'm investigating.

Uncleanly, because, we should be able to choose which version of db we
want to use by ./configure or -I/usr/include/dbxx/
So if we want use db48 and not 51 we just specify a right path
-I/usr/include/db48.

After that, package is build as non-root and he cannot add
/usr/lib/db51/db.h before it start building, so we have to modify a
clean package of berkeley db to add a symlink to the current version
of db. I'll have to deal to db maintener.

> Many linux (and unix) systems have multiple Berkeley DB versions installed,
> and /usr/include/db.h isn't sufficiently reliable/portable.
Yes my debian have 3 versions, but they are still _one_ version of
/usr/include/db.h. lib48-dev packages are mutualy exclusive.

> Note that RPM also needs to work on non-linux, where /usr/include (and Berkeley DB)
> are all installed differently to what Debian does.
Yes of course! That's my problem, it don't build on one unix ;)
But as i said, finding the path of headers should be configurable, not
static in $INCLUDE/db51/db.h.

> This is in fact why Berkeley DB used to be bundled with RPM ...
>
> If you wish to pursue this approach I will identify and document all the steps
> needed (its not hard).
Stop bundling librairy with the binary is great and I don't want to
stop you in your swing. Find a way to correctly give the path of db.h
is a better way. No?

>> This is also why autotools don't detect that berkeley db is missing,
>> because he detect it. I think you should fix that in the code.
>
>
> I don't disagree, but there's no pleasing everyone, or handling
> all possible ways to install Berkeley DB, including version tests
> and internal <-> external, automagically using autoconf tests.
bdb is annoying to manage...

>
> Nor is there any RPM development reason to chase every possible
> Berkeley DB version everywhere. Instead, one single version is
> being targeted (older versions back to db-4.5.x will work) and
> with one recommended installation of Berkeley DB
> (relevant to your case, /usr/include/db51/db.h is "recommended")
We don't speak about bdb version but bdb PATH. This is just a question of path.

It's not a stupid to considere just using #include <db.h> and not
#include <db51/db.h> which my test patch do.
After that, it's free to compile with -I/usr/include/db51 to compile
or choose and default version and make a symlinks.
This seems (to me) the better way.

Another small point:

This line let think that berkeley-db is optional in building of rpm
Berkeley-DB [1] optional 5.1.19 5.1.19
http://www.oracle.com/database/berkeley-db.html

but when i try to build whitout it : i cannot. Normal?

--
Sébastien Luttringer
www.seblu.net

[Jeff Johnson (n3npq)]

There is another approach, patching <db51/db.h> to <db.h> in
RPM sources.

The patch isn't large or hard. Changing the AutoFu in RPM _IS_ hard
for other reasons having to do with "features" and "portability" and
particularly the RPM_CHECK_LIB() macro used everywhere for detecting build
pre-requisites for RPM.

 $ cd rpm-5.3.6
 $ grep "db51/" * */*
...

configure:#include <db51/db.h>
configure:#include <db51/db.h>
configure: if test -f "${__rcl_dir}/db51/db.h"; then
configure: for __rcl_file in _ `find ${__rcl_location} -name "db51/db.h" -type f -print 2>/dev/null`; do
configure: for ac_header in db51/db.h
configure: ac_fn_c_check_header_mongrel "$LINENO" "db51/db.h" "ac_cv_header_db51_db_h" "$ac_includes_default"
configure:#include <db51/dbsql.h>
configure:#include <db51/dbsql.h>
configure: if test -f "${__rcl_dir}/db51/dbsql.h"; then
configure: for __rcl_file in _ `find ${__rcl_location} -name "db51/dbsql.h" -type f -print 2>/dev/null`; do
configure: for ac_header in db51/dbsql.h
configure: ac_fn_c_check_header_mongrel "$LINENO" "db51/dbsql.h" "ac_cv_header_db51_dbsql_h" "$ac_includes_default"
...

configure.ac: [db-5.1], [db_create], [db51/db.h],
configure.ac: [db_sql-5.1], [sqlite3_open], [db51/dbsql.h],

...

rpmdb/rpmdb.h:#include <db51/db.h>
rpmdb/rpmrepo.c:#include <db51/dbsql.h>
rpmio/rpmsql.c:#include <db51/dbsql.h>
tools/dbsql.c:#include <db51/dbsql.h>
tools/rpmrepo.c:#include <db51/dbsql.h>
tools/sqlite3.c:#include <db51/dbsql.h>

There's even Yet Another Alternative that could be pursued,
by adding either a db51-config script, or a db51.pc pkgconfig
file, so that RPM_CHECK_LIB() could discover the necessary
-I include paths to link against Berkeley DB as installed on Arch
linux. Yes db51-config/db51.pc would have to be made to Berkeley DB,
not RPM, on Arch linux.

Build --with-db=internal (and the renaming/symlinks needed) is the
most viable path to building rpm-5.3.6 if you cannot change "system"
Berkeley DB on Arch linux.

[Jeff Johnson (n3npq)]

Regarding

> Another small point:
>
> This line let think that berkeley-db is optional in building of rpm
> Berkeley-DB [1] optional 5.1.19 5.1.19 http://www.oracle.com/database/berkeley-db.html
>
> but when i try to build whitout it : i cannot. Normal?

Expected. yes. Berkeley DB has always been used in RPM,
I personally would claim MANDATORY.

Meanwhile there's lots of Berkeley DB haters around who insist
on ripping out Berkelpey DB wherever they see it. This ripping
has been done in RPM as well, where it used to be possible to
build RPM with sqlite instead of Berkeley DB.

After repeatedly asking whether there was need (no answer) and
warning that "RPM ACID" was going to cause sqlite3 to be dropped
(there's nothing per se wrong with sqlite3, just the schema that
was chosen at the time MUST be changed), the current state
of affairs is that Berkeley DB is de facto "MANDATORY" not "optional"
even if the doco claims otherwise. I'm not at all averse to re-adding
sqlite3 support, just, well, ya gotta start someplace, and there needs to
be some interest before attempting the implementation.

[Jeff Johnson (n3npq)]

Regarding

> So if we want use db48 and not 51 we just specify a right path
> -I/usr/include/db48.

Yep. That is usually what I try to achieve. However, that also forces
RPM to lag choosing what Berkeley DB version to choose, dependent
on what distros choose to pick up. The delay is adoption is measured in
months and years, and db-5.1.19 -- while it _HAS_ been picked up surprisingly
fast -- is not gonna be any exception.

But if you are truly interesetd (in Arch linux) in supporting mutiple versions
of Berkeley DB, the convention of installing into /usr/include/db51 is
hardly surprising.

The harder issue for a distro is
   What version goes into /usr/include/db.h?
which is pretty easily handled by alternative symlinks into /usr/include/dbXY,
independently of whether RPM itself chooses to do (as in rpm-5.3.6)
   #include <db51/db.h>
or (I prefer -I/usr/include/db51 in CFLAGS personally)
    CFLAGS="... -I/usr/include/db51 ..."
    #include <db.h>

The harder issue atm is that RPM is trying to support "embedded sqlite" using
the dual access in db-5.x and (atm) there's a limitation in RPM_CHECK_LIB()
that forces <db51/db.h> not <db.h> for AutoFu. This can/will be fixed as rapidly
as can be managed (because I prefer the flexibility of -I/usr/include/db51).

Meanwhile, what's in rpm-5.3.6 was quite consciously/deliberately chosen
and the issues are well known: aggresively/narrowly targeting db-5.1.19
and dual SQL <-> CRUD access has implementation costs.

[Jeff Johnson (n3npq)]

Regarding
> We don't speak about bdb version but bdb PATH. This is just a question of path.

No. If #include <db.h> pulls in a random version of Berkeley DB, then
there is also the implicit expectation of "support" in RPM for whatever
version happens to be installed, and with some very complex AutoFu
necessary to test explicitly for version as well as paths.

But yes, your build failure is solely because of path, not version.

[Sébastien Luttringer (seblu)]

On Wed, Dec 15, 2010 at 7:06 PM, Jeff Johnson <email address hidden> wrote:
> Meanwhile, what's in rpm-5.3.6 was quite consciously/deliberately chosen
> and the issues are well known: aggresively/narrowly targeting db-5.1.19
> and dual SQL <-> CRUD access has implementation costs.

From an external point of view, 5.3.6 is a hell to compile. I'm
wondering on which system you run to compile this version?
I tried some minutes ago on fedora, this afternoon on debian and i
have long tried on archlinux since 2 days and in all case : FAILURE!

so to get arround our issue on berkeley db path i have patched
rpmdb/rpmdb.h by removing that (at start)
#if defined(_RPMDB_INTERNAL)
#if defined(WITH_DB)
#include <db51/db.h>
#else
#include "db_emu.h"
#endif
#endif

because, now db is always builded externaly and so, db51/db.h is never
included. changing only #include <db51/db.h> to #include <db.h> change
nothing.

so i've remplaced all this code by : #include <db.h>

and now compilation goes further, but fail:

http://pastebin.com/egmppm4v

please note that configure output says :
configure: Configured to build neon 0.29.5:

  Install prefix: /usr/local
  Compiler: gcc
  XML Parser: expat
  SSL library: SSL support is not enabled
  zlib support: zlib support enabled, using -lz
  Build libraries: Shared=yes, Static=yes

so it detect a expat parser?! but without --with-expat in configure it
shows building issue on xml parser as you can says in previous
pastebin.

with --with-expat in configure this give => no xml error message
(note, expat is marked optional.
http://pastebin.com/f0izqvSp

new test :LIBS="-lgssapi -lgomp" ./configure --with-python=python2
--with-expat => better
http://pastebin.com/wCuwQMWr

new test : LIBS="-lgssapi -lgomp -lproxy" ./configure
--with-python=python2 --with-expat LIBS="-lgssapi -lgomp -lproxy"
./configure --with-python=python2 --with-expat
http://pastebin.com/z9VGLcX2

Ok now i'm lost. Do you have suggestions?

--
Sébastien Luttringer
www.seblu.net

[Jeff Johnson (n3npq)]

Yes rpm is quite complicated to build.

See the platforms (and more importantly the build options)
in the top-level devtool.conf file. rpm-5.3.6 was building
on almost all of those platforms with the given options
under buildbots' for all of November. That of course
doesn't help you too much with an Arch linux build.

The %static stanza in devtool.conf is more minimalistic than most.

Regarding the 1st pastebin ... Do you really want -lgomp? There's little benefit.

Compiling without neon should simplify a lot of the build too: --without-neon
(neon is what drags in XML linkages). Preferring --with-neon=internal (what is in 5.3.6)
also means that all other build options must be explicitly added. If external,
pkgconfig often supplies additional flags.

Regarding the last pastebin with missing _dbiPool/db3free.

The db3Free is a #define in rpmdb/rpmdb.h under #if defined(WITH_DB).
That's also gonna be the case with _dbiPool.

You could try editing config.h after running ./configure and
enabling WITH_DB.

And another approach (if you don't want /usr/include/db51) would
be to crate a symlink in the rpm-5.3.6 top directory:
    ln -s /usr/include db51
That won't fix ./configure detection, but should find db.h.

[Sébastien Luttringer (seblu)]

On Thu, Dec 16, 2010 at 2:19 AM, Jeff Johnson <email address hidden> wrote:
> Yes rpm is quite complicated to build.
>
> See the platforms (and more importantly the build options)
> in the top-level devtool.conf file. rpm-5.3.6 was building
> on almost all of those platforms with the given options
> under buildbots' for all of November. That of course
> doesn't help you too much with an Arch linux build.
Thanks, this a great to see examples.

> The %static stanza in devtool.conf is more minimalistic than most.
ok...
-- no operation
checking magic.h usability... yes
checking magic.h presence... yes
checking for magic.h... yes
checking for magic_open in -lmagic... yes
checking whether to build with File (magic) library... yes (external:
implicitly)
++ executing success action
++ searching location: internal
-- skipping not existing local sub-directory: db3
configure: error: unable to find internal Berkeley-DB library

> Regarding the 1st pastebin ... Do you really want -lgomp? There's little
> benefit.
ld claims symbols from gomp libs, adding this remove error. I believe yes.

> Compiling without neon should simplify a lot of the build too: --without-neon
> (neon is what drags in XML linkages). Preferring --with-neon=internal (what is in 5.3.6)
> also means that all other build options must be explicitly added. If external,
> pkgconfig often supplies additional flags.
>
> Regarding the last pastebin with missing _dbiPool/db3free.
>
> The db3Free is a #define in rpmdb/rpmdb.h under #if defined(WITH_DB).
> That's also gonna be the case with _dbiPool.
>
> You could try editing config.h after running ./configure and
> enabling WITH_DB.
>
> And another approach (if you don't want /usr/include/db51) would
> be to crate a symlink in the rpm-5.3.6 top directory:
>    ln -s /usr/include db51
> That won't fix ./configure detection, but should find db.h.

After configuring with ./configure --prefix=/usr --sysconfdir=/etc
--localstatedir=/var --with-python=python2 --without-selinux
--with-beecrypt=external --with-neon=internal
editing the config.h to define WITH_DB and running make =>
http://pastebin.com/RfidCJJU

Seriously, i tried on ubuntu 10.10 with params from devtool.conf. The
same on fedora. In each case the source doesn't compile. Do you really
thing this is a stable relase or rpm5?

So please, just give me a platform where i can see it compiling, I
want to believe it compile somewhere!

--
Sébastien Luttringer
www.seblu.net

[Jeff Johnson (n3npq)]

The build pre-requisites are documented and available,
including db-5.1.19 installed into /usr/include/db51.

I have shown you the build options that were used
on multiple platforms (but not arch).

Since you have not succeeded in building rpm-5.3.6, you're in
no position to assess "stable".

We both agree "release" because the rpm-5.3.6 tar ball is
de facto publically available at http://rpm5.org even if we
disagree on "stable".

Any other questions?

[Jeff Johnson (n3npq)]

Re http://pastebin.com/RfidCJJU:

Using --with-neon=internal needs additional build options
supplied. These are what was used on ubuntu 10.10 (directly
listed in devtool.conf):
        --without-libproxy \
        --with-expat \
You will also need to either disable kerberos or supply the path
to the library that contains gssapi.

[Sébastien Luttringer (seblu)]

On Tue, Dec 21, 2010 at 1:45 AM, Jeff Johnson <email address hidden> wrote:
> The build pre-requisites are documented and available,
> including db-5.1.19 installed into /usr/include/db51.
I tryed on openbsd and db include are not into /usr/include/db5 but in
/usr/include/db.h.
I will try tomorow on freebsd.

> I have shown you the build options that were used
> on multiple platforms (but not arch).
Yes, and these options will _not_ compile on platforms where they
should. I don't speak about arch! I tried on ubuntu and fedora. Have
you make the test?

> Since you have not succeeded in building rpm-5.3.6, you're in
> no position to assess "stable".
You are right, i'm not in position.
But release something unbuildable is really boring for packager!
I tried to build rpm 5.3.6, 5.3.7 and 5.4.0 with many option without
success. I tried to build 5.3.6 on others distro with the same
effects!

> We both agree "release" because the rpm-5.3.6 tar ball is
> de facto publically available at http://rpm5.org even if we
> disagree on "stable".
rpm-5.3.6 is marked as "Production Ready" on rpm5.org website. Perhaps
by mistake, i believe this stand for ready to be buildable.

> Any other questions?
Yes, sames as in my previous mails. On which existing OS (other than
arch), and if possible based on linux, can i see rpm 5.3.6 build?
Just to take away the impression to fight against the wind.

--
Sébastien Luttringer
www.seblu.net

[Sébastien Luttringer (seblu)]

On Tue, Dec 21, 2010 at 1:57 AM, Jeff Johnson <email address hidden> wrote:
> Re http://pastebin.com/RfidCJJU:
>
> Using --with-neon=internal needs additional build options
> supplied. These are what was used on ubuntu 10.10 (directly
> listed in devtool.conf):
>        --without-libproxy \
>        --with-expat \
> You will also need to either disable kerberos or supply the path
> to the library that contains gssapi.
>
This doesn't build...

http://pastebin.com/c2L4ehkB

--
Sébastien Luttringer
www.seblu.net

[Jeff Johnson (n3npq)]

Those symbols are in -lbeecrypt.

There's 2 ways to fix:
1) Adding @WITH_BEECRYPT_LIBS@ to rpmconstant LDFLAGS
2) Build RPM using --with-beecrypt=internal so that beecrypt ends
up in -lrpmmisc.

The 2) approach using --with-beecrypt=internal is chosen in rpm-5.3.6
 because beecrypt has been dropped in RHEL6 and is essential (all digests
are generated using beecrypt because that is highest performing).

Meanwhile if you're up to rpmconstant build failures, you're very close to
a complete build of rpm-5.3.6. rpmconstant is used solely to build rpm-perl
bindings and is otherwise unneeded for RPM.

[Sébastien Luttringer (seblu)]

On Tue, Dec 21, 2010 at 2:37 PM, Jeff Johnson <email address hidden> wrote:
> Those symbols are in -lbeecrypt.
>
> There's 2 ways to fix:
> 1) Adding @WITH_BEECRYPT_LIBS@ to rpmconstant LDFLAGS
> 2) Build RPM using --with-beecrypt=internal so that beecrypt ends
> up in -lrpmmisc.
>
> The 2) approach using --with-beecrypt=internal is chosen in rpm-5.3.6
>  because beecrypt has been dropped in RHEL6 and is essential (all digests
> are generated using beecrypt because that is highest performing).
This is already done in the configure as you can see in pastebin.

>
> Meanwhile if you're up to rpmconstant build failures, you're very close to
> a complete build of rpm-5.3.6. rpmconstant is used solely to build rpm-perl
> bindings and is otherwise unneeded for RPM.
Jeff, this building is only to see you a point : With the options in
devtool.conf on the right platform, this doesn't build!

i make a dream where rpm can compile with ./configure; make; make install... :-)

Please jeff, can you give me an OS and build options which allow
compiling of v5.3.6?

--
Sébastien Luttringer
www.seblu.net

[Jeff Johnson (n3npq)]

What is your goal here:

    To prove that RPM cannot be built or to to build rpm?

If the first is your goal, I agree that RPM is hard to build. The choice of
    Have it your own way!
and adding zillions of build options was the choice made by @rpm5.org.

I'll ignore the fact that you seem to be calling me a liar. I most certainly have built
rpm-5.3.6 on most of the platforms listed in devtool.conf, with the given build options,
subject to setting up the build system, which involved installing
    autoconf
    libtool
    automake
    gettext
    db-5.1.19
    pcre
The spec files used for all of the above additions are available in @rpm5.org cvs in
a top-level "distro" module.

If the second is your goal, then I suggest you look at your build more carefully.
I cannot fix your arch linux build, only help diagnose your build failures.

[Sébastien Luttringer (seblu)]

On Tue, Dec 21, 2010 at 8:38 PM, Jeff Johnson <email address hidden> wrote:
> What is your goal here:
>    To prove that RPM cannot be built or to to build rpm?
Proven to whom? Let's stop kidding!
i really like not to spend one week on trying 20 different ways to compile rpm.

> If the first is your goal, I agree that RPM is hard to build. The choice of
>    Have it your own way!
I'm not agree with that. As far i can see, it not compile. My current
goal is to see it compile somewhere!

> and adding zillions of build options was the choice made by @rpm5.org.
Have 1 million options has no bearing on the fact that it should
compile without it!

> I'll ignore the fact that you seem to be calling me a liar.
Please.

>I most certainly have built rpm-5.3.6 on most of the platforms listed in devtool.conf, with the given build options,
> subject to setting up the build system, which involved installing
>    autoconf
>    libtool
>    automake
>    gettext
>    db-5.1.19
>    pcre
I don't see how it's possible! And I say this tactfully!
At this time,i don't have seen a distro with db5/db.h embedded. But
don't care...
Please just try. Go on ubuntu and do

tar xf rpm-3.5.6.tar.gz; cd rpm-3.5.6
./configure --verbose --prefix=/usr --with-db --with-dbsql
--without-db-tools-integrated --with-zlib --with-bzip2 --with-xz
--with-file --with-path-magic=/usr/share/file/magic
--with-lua=internal --with-tcl --without-sqlite --with-syck=internal
--with-readline --without-augeas --with-beecrypt=internal
--without-java --with-openssl --without-nss --with-gcrypt
--with-tomcrypt --without-tpm --without-libtasn1 --without-pakchois
--without-gnutls --with-neon=internal --without-libproxy --with-expat
--with-pcre --without-uuid --with-attr --with-acl --without-xar
--with-popt=internal --with-keyutils --with-pthreads --with-libelf
--without-cudf --without-ficl --without-aterm --without-nix
--without-bash --without-rc --without-js --without-gpsee --with-python
--without-pythonembed --with-perl --without-perlembed --without-ruby
--without-selinux --without-sepol --without-semanage
--without-squirrel --with-build-extlibdep --with-build-maxextlibdep
--with-valgrind --disable-openmp --enable-build-pic
--enable-build-versionscript --enable-build-warnings
--enable-build-debug --enable-maintainer-mode
make

and tell me if you compile. I don't search to prove you are a liar or
something else. I try to see why everywhere i try, this doesnt build.

> I cannot fix your arch linux build, only help diagnose your build failures.
Please do try to stop to speak about arch. ubuntu, fedora, openbsd
have the same issue (with my try)

i'm not a rpm5 developer. I'm a packager!
I do not know as well as you rpm. Maybe I do things badly. That's why
I'm asking your opinion!

--
Sébastien Luttringer
www.seblu.net

[Jeff Johnson (n3npq)]

rpm-5.3.6+ is compiled in Mandriva Cooker and Ark linux.

I'm not sure how I am responsible for proving to you that
RPM builds on Ubuntu 10.10 or any other platform.

But I've restarted the buildbot used for all of rpm-5.3.6
releaseing. E.g. You can see the build logs for a build
on Ubuntu 10.10 here
    http://eastham.rpm5.org:8010/builders/UBUNTU_rpm_release/builds/75
You can see other builds at
    http://eastham.rpm5.org:8010

When active (not currently because there's no development of
consequence going on @rpm5.org atm), you can examine
build logs at
     http://buildbot.rpm5.org:8010