[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] New RPMS (curl, libjpeg, hermes, libiconv, libfreetype2)

Actually.. I just read your blog post and it suggests that the libs will be multiarch and binary packages will be build per architecture - m68kmint m68k020mint and cfmint.... I'm starting to think that this really is the best way to go about this.
I'm just wondering about building rpm's natively. There might be tests that run that won't work on the coldfire build. I guess you would just decide your build system and the other arch's would be considered cross compiled? 

Thanks,
Mark

On 3/3/11 12:52 PM, Keith Scroggins wrote:
I was trying to resolve a good way to do this with our version of RPM, and I just can not figure out an 'easy' way to implement this.
Since it has been a few months since I played around with it, I could not go directly into details. What I do recall is that it was not easy to build the RPMs targetted for the other arch's based on the limitations of the older RPM, and trying to upgrade is far from an easy task because of the usage of mmap all over the place in both 'official' tries of RPM, besides the fact that the source code itself is a 'rats nest' in organization.
As long as we are using static libraries, I think the -devel RPMs should be multilib'd, which will assist in quicker software development for the FireBee once complete, because there will already be a base for it.
As for the binaries, it would be *NICE* if the binary RPM packages could all be built within that single build, but I just have not figured out how to do it. Like, building OpenSSL, I'll have already built the actually openssl binary itself, but I'm only cherry picking the libs. If I could pick the rest that would be great.
Ideas accepted. :) I'm not quite sure how Alan/Gentoo handle the multi-arch nature, but I am sure that it is done and not nearly as complicated. 

Keith

On Thu, 24 Feb 2011, Mark Duckworth wrote:
This is why I am somewhat against this method. Other systems use different architectures.... 


We use pkg-ver.m68kmint.rpm.
I would package complete different packages built for different architectures like..
pkg-ver.m68mint.rpm, pkg-ver.m5475mint.rpm, pkg-ver.m68060mint.rpm, etc. That way any incidental binaries will run on the platform. I would be ok with multilib if there was a common minimum but 68000 stuff can't run on coldfire without a software emulation which makes this approach broken to me. 

But, we can also do a hybrid of this approach and create both setups.

Thanks,
Mark


On Feb 24, 2011, at 5:13 PM, Peter Slegg wrote:


On Thu, 24 Feb 2011 22:48:40 , "m0n0" <ole@monochrom.net> wrote:


Am Do, 24.02.2011, 21:26 schrieb Peter Slegg:


So does the multi-arch "hack" only apply to the .a files ?


Right - what more do you want?
There is only one thing that I could think of: a auto-generated config.h 
file ( or something like that, maybe types.h - whatever) which is
different between m68000 and coldfire.... - then you would need to take 
further steps...


Sorry if it is a dumb question. I assumed that with the devel rpm
it is the .a files. Then I was thinking about the  binaries in the main
libxml rpm, do these have to be mv'd to make each cpu version ?

/usr/bin/xmlcatalog
/usr/bin/xmllint
/usr/doc/libxml2-2.7.8
/usr/doc/libxml2-2.7.8/AUTHORS
/usr/doc/libxml2-2.7.8/ChangeLog
/usr/doc/libxml2-2.7.8/Copyright
/usr/doc/libxml2-2.7.8/NEWS
/usr/doc/libxml2-2.7.8/README
/usr/doc/libxml2-2.7.8/TODO
/usr/share/man/man1/xmlcatalog.1.gz
/usr/share/man/man1/xmllint.1.gz