Eliyahu Skoczylas wrote:

>> If you start reporting what the compilation issues actually are,  
>> then the
>> issues can likely be sorted out.
>
> Mostly, they aren't directly RPM related.  Having problems with  
> Solaris' autoconf while building Gnu's libiconv today, for example,  
> isn't something I would ask for help with on an RPM list.  I got  
> stuck with that today because yesterday I couldn't get gettext to  
> build with Solaris' libc, and so I had to install libiconv.   
> Gettext was brought in to make Gmake happy, which I installed  
> because Gcc 4 wouldn't build against Sun's make.  That kind of  
> thing....
>
> As I said, building RPM 5 on Solaris 8 has turned into building the  
> entire GNU toolset.  And that means incrementally building a tool,  
> moving onto the next tool and the next, then going back and  
> rebuilding the first tool better (with newer libraries.)

We do have similar issues when building on for instance FreeBSD and  
on Mac OS X. Somewhat less, perhaps, since the system compiler is GCC  
(or at least based on it) but when it comes to installing GNU tools  
or replacing outdated system ones and so on. So far, these are all  
solved by the OpenPKG bootstrap as implemented in the "devtool" of RPM5.

By invoking "devtool standalone", it builds the required toolchain  
(not _all_ tools are included, for instance a C compiler is expected)  
then goes on to building the required libraries and finally starts  
building the bootstrap version of RPM in a temporary location. This  
can later be used to build the final RPM version from the real specs.

The %standalone target has then been somewhat modified, to make the % 
macosx target that builds for Mac OS X (rpm4darwin).

--anders

PS. You need the CVS version, not tarball.