RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpmio not compiling

From: Belal Salem <belal@nothing-real.com>
Date: Tue 09 Aug 2011 - 06:54:30 CEST
Message-ID: <op.vzw0g4ltmn2pqa@localhost.macbook>
Thanks for the detailed explanation.
So, here after I satisfied all the prerequisites, when compiling the RPM  
source, I encounter the following compilation errors:

In file included from dbconfig.c:14:
./rpmdb.h:433: error: expected specifier-qualifier-list before  
./rpmdb.h:490: error: expected specifier-qualifier-list before 'DB_LOGC'
./rpmdb.h: In function 'dbiCopen':
./rpmdb.h:589: error: 'struct _dbiIndex' has no member named 'dbi_vec'
./rpmdb.h: In function 'dbiCclose':

what do you think that is?!

On Mon, 08 Aug 2011 15:36:34 -0400, Jeff Johnson <n3npq@mac.com> wrote:

> On Aug 8, 2011, at 1:19 PM, Belal Salem wrote:
>> Actually, what I'm trying to do is the following, may be you have an  
>> advice for me:
>> I'm running RHEL-5, I found it the most stable and secure Distro that  
>> runs smoothly almost all the high-end simulation and 3D applications  
>> that I'm using intensively, the problem is that there are dozens of  
>> simple but important applications/utilities that requires higher  
>> versions of glibc and python, those that where supplied as rpm packages  
>> that requires newer versions of the RPM to be installed!
> Yes, you aren't alone here either: most "enterprise" distros have such a  
> ;one
> "supported" life that they become irrelevant.
> I'm not sure that ether's any "enterprise" distro with a solid upgrade  
> path.
> Dag's repository is likeliest best both reputation ally and in in  
> "reality".
> Check there first imho.
>> So, I decided to build a custom system installation that satisfies all  
>> my needs.
>> I manually forced upgrade glibc with a version that gives 2.6 and 2.7  
>> without breaking the system dependencies, and I compiled python-2.7.2,  
>> and now my system runs really great! and I can run those new  
>> applications smoothly.
> Upgrading REHL5 to python-2.7.2 is non-trivial: congratulations on  
> success.
>> The only one thing that I'm suffering from is that I have to manually  
>> extract and install them since they require higher signature of  
>> fileDegist, payload and rpm compressing... for that I decided to  
>> upgrade to RPM-5 to be able to install them regularly using the RPM  
>> Packager.
> Yes: distros have chosen to use SHA-256 file digests without bothering
> to release a compatible version of rpm.
> There is a way to disable file digests using --nofdigests (I've  
> forgotten the
> older option, it has been 6 years or so: --nomd5sums? something like  
> that).
> Sadly that *still* isn't enough because of the XZ! XZ! XZ! craziness. So  
> there's
> often nothing one can do except extract the payload
> 	rpm2cpio.sh foo*.rpm | cpio -dim
> (there's a shell script that permits inserting a unxz where needed).
> There are back ports of XZ and SHA256 file digests to whatever RPM is
> in RHEL5 if needed: I can dig out the necessary patches if GOOG
> cannot find something that Just Works.
>> Any advices about that! are there an easy way to let the RPM source  
>> compile both of the i686 and x86_64 bit.
> All depends on what is considered "easy".
> FYI: rpm-4.4.7 (on which @rpm5.org is based) treats arch simply as a  
> string. SO
> it's entirely feasible to do
> 	rpmbuild -ba --target=hotmommacpu foo.spec
> and end up producing binary
> 	foo*.hotmammacpu.rpm
> Whether that is useful or not is a far more complex answer: but RPM  
> won't stop you
> from attempting.
> For RHEL5, its likely easiest to add (and change)
> 	/etc/rpm/platform
> which contains in 1-line the usual config.guess string like
> 	x86_64-unknown-linux
> There are ways to invoke with a setarch(1) prefix like
> 	setarch x86_64 rpmbuild -ba yadda.spec
> but I find that rather more annoying than easy: usually I'm building
> a set of packages, and editing /etc/rpm/platform is persistent (and easy)
> even if I usually forget to check the setting when building.
>> What I'm confused about, is that the RPM has many dependencies, and I  
>> don't know which one of them should be compiled for both i686 and  
>> x86_64 and which needs to only compile for x86_64.
> All ELF dependencies have a "color" and are attached to file(s) (if the  
> functionality is not disabled).
> So color is 0 == "white", 1 == elf32, and 2 == elf64 and you can see the  
> dependencies by doing
> 	rpm -qp --filerequire *.rpm
> to see which dependencies are associated with each file.
> There is a --fileprovide as well, and you can also see what rpm is going'
> to do by typing, say,
> 	find /bin | /usr/lib/rpm/rpmdeps --requires
> or even
> 	echo "/bin/sh" | …
> (there's a --provides analogue to --requires too).
> Other arch-specific dependencies are usually dictated by Packaging  
> Policy Police somewhere.
> Note that RHEL5 is particularly strangely painful in the way it handles  
> ix86 <-> x86_64 "multilib".
> hth
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> User Communication List                             rpm-users@rpm5.org

Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Tue Aug 9 00:53:16 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.