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:26:32 CEST
Message-ID: <op.vzximiidmn2pqa@inferno>
DONE IT !!! [SOLVED]

I passed out all the errors the last one was resolved by using db-5.1.19  
instead of db-5.2.x

Here is a quick reference on how I did it, may be some one stuck into it  
like me:



Compiling and Installation:
___________________________
===========================

1. Configure TCL:
-----------------
    # ./configure --prefix=/usr --libdir=/usr/lib64 --enable-shared  
--enable-threads --enable-64bit \
      --enable-static

2. Configure the db-5.1.19:
---------------------------
    # cd build_unix
    #  ../dist/configure --prefix=/usr --libdir=/usr/lib64 --enable-tcl  
--enable-shared --enable-sql \
       --enable-dbm --with-tcl=/usr/lib64
    # make
    # make install
    # cp db.h dbsql.h /usr/include/db51/

3. Configure ncurses:
---------------------
    # ./configure --prefix=/usr --libdir=/usr/lib64 --with-shared  
--with-static --with-libtool

4. Configure expat:
-------------------
    # ./configure --prefix=/usr --libdir=/usr/lib64 --with-shared  
--with-static

5. Configure the rest of the 3d-parties as follows:
---------------------------------------------------
    * Configure all of them as follows:
      #./configure --prefix=/usr --libdir=/usr/lib64
      # make
      # make install

      Note: Some of them doesn't use a 'configure' script, so they don't  
have an option line to install
            libs to /usr/lib64, so,
	   after installing them, do a symlink from them to /usr/lib64

6. Configure RPM:
-----------------
    # ./configure --prefix=/usr --libdir=/usr/lib64 --with-uuid=/usr/lib64  
--with-xar=/usr/lib64 \
                  --enable-rpm-lua-extensions-based-on-rpmlib  
--enable-fast-install --enable-shared \
		 --enable-rpmvercmp-digits-beat-alpha --with-expat=/usr/lib64  
--with-neon=/usr/lib64 \
		 --with-tcl=/usr/lib64
    # make
    # make install
    # rpm --rebuilddb





On Tue, 09 Aug 2011 00:54:30 -0400, Belal Salem <belal@nothing-real.com>  
wrote:

> 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  
> 'DB_SEQUENCE'
> ./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 e-mail client: http://www.opera.com/mail/
Received on Tue Aug 9 07:30:47 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.