New MiNTlib and Friends....

I'm lazy, so once again, I'll share a recent post to the MiNT List about building the latest release of the MiNTLib. Whats news? Support for GCC4 and also support for the Coldfire CPU for the upcoming Firebee! I am by no means as skillful or knowledgeable as Frank Naumann was, who is dearly missed for his support of the platform and shaping MiNTLib, and the kernel, to be what they are today.

---

Before this goes up into SpareMiNT, thought it should be tested to have a consensus that the build is good. I have not found any issues, but that does not mean that I did not overlook something obvious and my Falcon is pretty much a test/dev environment rather than 'production.'

Files are here:

http://www.radix.net/~atari/mint/recent/

[ ] mintbin-0.3-4.m68kmint.rpm 31-May-2010 11:54 579k
[ ] mintbin-0.3-4.src.rpm 31-May-2010 12:00 328k

Install this package first to fix a conflict between the older version and the latest MiNTLib.

[ ] mintlib-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:11 961k
[ ] mintlib-0.59.1-1.src.rpm 02-Jun-2010 16:24 1.4M
[ ] mintlib-debug-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:13 1.7M
[ ] mintlib-devel-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:15 1.6M
[ ] mintlib-profile-0.59.1-1.m68kmint.rpm 02-Jun-2010 16:17 1.8M

Here is the MiNTLib packages themselves, install what is needed. They include the Coldfire libs, as well as the 68000 and 68020-60 libs.

[ ] fdlibm-5.3-2.m68kmint.rpm 04-Jun-2010 13:49 109k
[ ] fdlibm-5.3-2.src.rpm 04-Jun-2010 13:49 85k
[ ] pml-2.03-4.m68kmint.rpm 01-Jun-2010 18:10 25k
[ ] pml-2.03-4.src.rpm 01-Jun-2010 18:10 68k

The MiNTLib update will remove math.h, so whichever math lib is being used needs to be upgraded as well. Both PML and Fdlibm include libraries for 68000 / 68020-60 / Coldfire. PML's Coldfire support is from Vincent's patching. I added the Coldfire support to Fdlibm, and have not tested it yet.

[ ] gcc-4.5.0-1.m68kmint.rpm 01-Jun-2010 15:40 6.5M
[ ] gcc-4.5.0-1.src.rpm 03-Jun-2010 14:52 32.8M
[ ] gcc-c++-4.5.0-1.m68kmint.rpm 01-Jun-2010 15:51 9.5M

Finally, if you want to be brave, GCC 4.5.0 for FreeMiNT. I used this to built MiNTLib, so it seems pretty stable. Based on Vincent's latest patch. If this is installed, it will replace GCC 2.95.3, and you will want this MiNTLib and also Binutils 2.20.1.

I used 'black magic' to build this package. It was build with the Cross Compiler in PS3 Linux using a spec file modified to detect whether it is running natively or cross, and then I had to modify the RPM to be totally 3.0 compliant as it was built with RPM 4.4. There were some other tricks employed in there to fix problems with RPM noting the OS used for the build.

---

Hopefully today I will post a little tutorial (that might possibly be a tad incomplete, but we'll see) on how to try to setup an environment to try to cross compile RPMs. Right now, I am testing this process with the newly released OpenSSL 1.0.0a and will probably also try this with a rebuild of OpenSSH 5.5p1, to keep us up to date!

Multi-Target SpareMiNT (RPM) Thoughts - How to do it maybe...

This is the other list post about multiple targets for RPM....

---

This is extremely long, but hopefully I explain almost everything....

Basically, this is my thought towards a multi architectured SpareMiNT. Note that this can be tweaked, as I am just basically taking stabs to see what works where. And it is definitely not perfect.

Now, my opinion on libraries versus binaries is this, I think we should try to build the libraries all bundled into a single RPM, because a huge problem will arise with includes needing to overwrite each other. I have, so far, done this with both OpenSSL and Zlib. Binaries can each get their
own package, but the problem arise when lib/binary combination, and that is going to take some thought or fancy spec maneuvering. Anyway....

My first thought is we basically have 3 targets:

m68kmint - 68000, basically the base
m68k020mint - 68020-60
cfmint - 5475

So, for the release of make, you have:

make-3.81-3.src.rpm The src RPM to rebuilt the packages
make-3.81-3.m68kmint.rpm The 68000 binary
make-3.81-3.m68k020mint.rpm The 68020-60 binary
make-3.81-3.cfmint.rpm The Colfire binary

Can these be built? Yes, but we have to make our systems allow them to be installed before we get to the build process.

All systems can install m68kmint.rpm packages, but there need to be changes to allow m68k020mint.rpm and/or cfmint.rpm packages to be installed and/or built.

Two files need to be edited. The first one is /etc/rpmrc.

I believe the original looks like this:

#
# /etc/rpmrc
#
optflags: -O2 -fomit-frame-pointer
Provides: /sbin/rmt

---

Basically this file is just specifying the CFLAGS (Compiler Optimizations)
to use when building a RPM pacakge. So, my modifications:

#
# /etc/rpmrc
#
optflags: m68kmint -O2 -fomit-frame-pointer
optflags: m68k020mint -m68020-60 -O2 -fomit-frame-pointer
optflags: cfmint -mcpu=5475 -O2 -fomit-frame-pointer
#optflags: -O2 -fomit-frame-pointer
Provides: /sbin/rmt

---

The above is setting the CFLAGS for the additional 2 targets so they are
CPU specific.

The other file that needs changes is the /usr/lib/rpm/rpmrc file. This
file is quite large. To be brief, here is the original snippet of lines
that contain mint and might be changed (but not all will):

arch_canon: m68kmint: m68kmint 13
arch_canon: atarist: m68kmint 13
arch_canon: atariste: m68kmint 13
arch_canon: ataritt: m68kmint 13
arch_canon: falcon: m68kmint 13
arch_canon: atariclone: m68kmint 13
arch_canon: milan: m68kmint 13
arch_canon: hades: m68kmint 13
buildarchtranslate: atarist: m68kmint
buildarchtranslate: atariste: m68kmint
buildarchtranslate: ataritt: m68kmint
buildarchtranslate: falcon: m68kmint
buildarchtranslate: atariclone: m68kmint
buildarchtranslate: milan: m68kmint
buildarchtranslate: hades: m68kmint
arch_compat: atarist: m68kmint noarch
arch_compat: atariste: m68kmint noarch
arch_compat: ataritt: m68kmint noarch
arch_compat: falcon: m68kmint noarch
arch_compat: atariclone: m68kmint noarch
arch_compat: milan: m68kmint noarch
arch_compat: hades: m68kmint noarch
buildarch_compat: atarist: m68kmint noarch
buildarch_compat: atariste: m68kmint noarch
buildarch_compat: ataritt: m68kmint noarch
buildarch_compat: falcon: m68kmint noarch
buildarch_compat: atariclone: m68kmint noarch
buildarch_compat: milan: m68kmint noarch
buildarch_compat: hades: m68kmint noarch

---

These are the definitions that allow rpm / sparemint software to be
installed on the various Atari systems. Now, here is my 'modified'
version, which allows the newer RPMs to install:

arch_canon: m68kmint: m68kmint 13
arch_canon: atarist: m68kmint 13
arch_canon: atariste: m68kmint 13
arch_canon: ataritt: m68kmint 13
arch_canon: falcon: m68kmint 13
arch_canon: atariclone: m68kmint 13
arch_canon: milan: m68kmint 13
arch_canon: hades: m68kmint 13
arch_canon: coldtari: m68kmint 13
buildarchtranslate: atarist: m68kmint
buildarchtranslate: atariste: m68kmint
buildarchtranslate: ataritt: m68kmint
buildarchtranslate: falcon: m68kmint
buildarchtranslate: atariclone: m68kmint
buildarchtranslate: milan: m68kmint
buildarchtranslate: hades: m68kmint
arch_compat: atarist: m68kmint noarch
arch_compat: atariste: m68kmint noarch
arch_compat: ataritt: m68kmint m68k020mint noarch
arch_compat: falcon: m68kmint m68k020mint noarch
arch_compat: atariclone: m68kmint m68k020mint noarch
arch_compat: milan: m68kmint m68k020mint noarch
arch_compat: hades: m68kmint m68k020mint noarch
arch_compat: coldtari: m68kmint cfmint noarch
buildarch_compat: atarist: m68kmint m68k020mint cfmint noarch
buildarch_compat: atariste: m68kmint m68k020mint cfmint noarch
buildarch_compat: ataritt: m68kmint m68k020mint cfmint noarch
buildarch_compat: falcon: m68kmint m68k020mint cfmint noarch
buildarch_compat: atariclone: m68kmint m68k020mint cfmint noarch
buildarch_compat: milan: m68kmint m68k020mint cfmint noarch
buildarch_compat: hades: m68kmint m68k020mint cfmint noarch
buildarch_compat: coldtari: m68kmint m68k020mint cfmint noarch

---

Yes, the coldtari name needs to be fixed. :)

What this does now is this lets machines with 68030+ CPUs install the m68k020mint packages besides the standard ones. It also 'allows' the RPMS for all three targets to be built on the various systems.

So, now we have support for installing the RPMs, and support for building them, how do we build them?

So, take a standard RPM spec file. This is the file that has the instructions for building a package. We will use make.spec

For 68000 (The Default)
rpm -ba make.spec

For 68020-60
rpm -ba make.spec --target m68k020mint

For Coldfire
rpm -ba make.spec --target cfmint (Oops, this might fail, we'll get to that)

What this is doing is passing the compiler optimization for those targets to RPM, which, for make, this is how they are used:

make_cv_sys_gnu_glob=yes \
CFLAGS="${RPM_OPT_FLAGS}" ./configure \
--host=m68k-atari-mint \
--prefix=%{_prefix} --disable-nls \
--disable-nsec-timestamps

Right here we are either setting no CPU target or -m68020-60 or -mcpu=5475 at the CFLAGS="${RPM_OPT_FLAGS}"

This will produce makefile to build that way and output a properly named RPM.

Did I just mention a possible problem with Coldfire? Well, the problem is that since Coldfire binaries will not run on anything other than Coldfire CPUs, this causes configure to error out when testing for a Cross Compiler. My 'current' solution for that is the above "--host=m68k-atari-mint" line, which causes configure to think it is cross compiling the Coldfire target on a 68060 system, which is sort of true. This option, I believe, is ignored for the 68000 and 68020-60 targets.

Anyway, if you are still with me, thats my thought. I'm sure a bunch of this is confusing, and people can tweak it, so, go for it!

In closing, let me share a large snippet of the Zlib spec to demo what I talked about in the intro:

%build
# Coldfire
CFLAGS="-mcpu=5475 ${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
mv libz.a libzCF.a
# 68020-60
CFLAGS="-m68020-60 ${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make
mv libz.a libz020.a
# 68000
CFLAGS="${RPM_OPT_FLAGS}" \
./configure \
--prefix=%{_prefix}
make

%install
[ "${RPM_BUILD_ROOT}" != "/" ] && rm -rf ${RPM_BUILD_ROOT}

mkdir -p ${RPM_BUILD_ROOT}%{_prefix}
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/include
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib/m68020-60
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/lib/m5475
mkdir -p ${RPM_BUILD_ROOT}%{_prefix}/share/man/man3

#make install \
# prefix=${RPM_BUILD_ROOT}%{_prefix}
install -m644 libz.a ${RPM_BUILD_ROOT}%{_prefix}/lib/libz.a
install -m644 libzCF.a ${RPM_BUILD_ROOT}%{_prefix}/lib/m5475/libz.a
install -m644 libz020.a ${RPM_BUILD_ROOT}%{_prefix}/lib/m68020-60/libz.a
install -m644 zlib.h ${RPM_BUILD_ROOT}%{_prefix}/include/zlib.h
install -m644 zconf.h ${RPM_BUILD_ROOT}%{_prefix}/include/zconf.h
install -m644 zutil.h ${RPM_BUILD_ROOT}%{_prefix}/include/zutil.h
install -m644 zlib.3 ${RPM_BUILD_ROOT}%{_prefix}/share/man/man3

# compress manpages
gzip -9nf ${RPM_BUILD_ROOT}%{_prefix}/share/man/man*/* ||:

---

If you can follow this, what is happening is Zlib is being compiled 3 times, and the libs for the first 2 compiles are moved out of the way. Finally, everything is installed manually, and the libs for all 3 targets are placed in their correct locations.

The only other way to cleanly support the multilibs I can see, besides having all three loaded into 1 package is to make the 68000 package the main package, and then the other 2 packages sub to it, so you would have:

zlib-devel.m68kmint.rpm
zlib-devel020.m68kmint.rpm
zlib-develcf.m68kmint.rpm

Anyway, this is long enough, but this is my thought process. Any and all thoughts except on how to make this better.

Keith

MiNTLib / Kernel Future and also SpareMiNT......

Since I have been remiss with updates, been doing work with some progress, let me post some of my list postings. Will be 2, one about the future (this post) and the next about SpareMiNT for multiple targets......

---

Hi All,

Well, not sure where to go with this conversation, but we need to start it.

First being, we need a person, or a group of people, to steer MiNTLib and the Kernel. Mainly, I think, these people need to decide when it is time to do a release, maybe a little project planning, but I do not believe we need too much. I think this needs to more or less be a decision by the group.

It seems to me that it was more or less decided we should release MiNTLib at 0.59, should this be done now, or with a past build? I know I agree with this since some of the modern tools (gmp/mpfr/mpc/gcc) need support from functionality added and fixed in the CVS/developmental branch of the MiNTLib.


I would propose that we do a release now, and then plan the 0.60 version of MiNTLib to be released around the time of the Firebee release (possibly) in case things need to be fixed or added for Coldfire.

As for the kernel, I can not speak to it's status for release. I would recommend a road map or maybe a list of goals to prepare it for release, mainly bug squishing, and then expand that list to include what features, additions, etc, would go into the next revision.

Now, the other question is Sparemint. Where should it head? Are people still willing to build RPMs and support the software, and do people still want the software supported?

The other issue with Sparemint (well RPM), at least in my opinion, is architecture support. By default, unless currently noted, RPMs are built for a 68000 target. Should that remain the same, or should this expand so that packages are also target at 68020-60 and then later at the Coldfire? If so, how?

I have my own ideas / thoughts for this, but not much point in executing it if it would be of no use.

Remember, Alan is also working on a Gentoo MiNT distribution. I just want to basically see programming resources not go to waste, and get some real 'direction.'

Sorry for writing a book. Back to working on MPFR RPM.....

Keith