Monday, May 24, 2010

The world of RPMs and SpareMiNT with FreeMiNT....... Specs and multiple targets...

RPMs, at least for users, make it easy for them to add or remove software, update, etc. More modern versions of RPM even make net updates pretty easy.

For developers though, RPM is hit or miss. Personally, I dislike the spec file. The spec file is basically the recipe, or instructions, for RPM to take a source archive, and possible a patch, and to successfully compile it, install it, and then package it for use by users.

Where am I going with this? Well, my latest adventure in trying to solve a major issue with SpareMiNT, how do you support multiple targets, and differentiate between them. Multiple targets meaning 68000, 68020-60, and 5475 (Coldfire).

68000 will work anywhere. On the Coldfire CPUs, though, these packages degrade performance because they must be run through an emulation layer to emulate the difference between the two architectures, since Coldfire is missing 68k instructions. So, when possible, you want software targeted for Coldfire. 68000 is compatible with 68020-60, but there are various optimizations gained from targeting the series of CPUs, so while you might not need all native software targeted for these higher end CPUs, there are some nice performance boost given in different areas.

68020-60 will only work on these CPUs and not Coldfire (I could be wrong). On that Atari ST platform, 68020 are rare, 68030 are common, 68040 are uncommon, and 68060 is pretty common now with the CT60.

5475 will only work on Coldfire series chips, such as the Firebee that is currently being developed / tested / in production. This series of chips is basically the successor of the m68k series. There is no telling how common this CPU will become, but tools are already supporting this target. I have built OpenSSL to include libraries supporting the target, and the GCC port also supports it, along with MiNTLib.

So, we have a quick and dirty summary of our targets. If you are a developer, you probably want or should have libraries built for each target, while if you are a user, you most likely only want binaries targeted at the systems CPU. This is where things get messy.

For developers, having the libraries separated is easy, currently, 68000 libs are the default and reside in /usr/lib and /usr/local/lib. The other targets reside in m68020-60 and m5475 directories in each of those directories. When software is built and the compiler is told to build for a CPU target or defaults to 68000 if nothing is specified, and it searched those directories first for supporting libraries needed, and then falls back to the 68000 libs if needed (and this behavior may change). So, this makes it sort of easy for developers. Only sort of, because when the libraries are installed doing the standard 'make install' they never actually go to the right home, so that needs to be done manually, and the '.la' file with the lib, if it has one, needs to be updated as well for the relocation. If I am incorrect with this statement, boy have I been making additional work for myself!

Anyway, the point is, we have an easy way to separate the libraries, and keep track. And, all of the libraries can be easily packed into a single -dev RPM for specific software. My recent Zlib build includes libs for all three targets, but only binaries for 68000.

This is where we run into problems. We have no easy way to separate the binaries. All of the binaries are just dumped into /usr/bin or /bin. Now, we could add CPU targeted subdirectories, but I do not see that as being worthwhile. My thought right now has been that the suffix is modified on an RPM for a user package so they can choose which version they want. For instance, I am using m68kmint (what has been used, 68000), m68k020mint (68020-60 target) and cfmint (5475). Not the most pretty solution, but we need something.

I guess that is it for rambles.....

Currently I am testing to see if I can build a Coldfire RPM of OpenSSH by just adding "--host=m68k-atari-mint" to configure. Configure is tricked into thinking it is cross compiling on my Falcon, which I guess is not a bad thing. I actually got a decent distance once with the compilation today before the dreaded malloc bug hit. Maybe that is my current issue with RPM, no luck building OpenSSL so far in RPM form because of the same bug..... RPM basically forces you to complete the process from the beginning to the end, no restarting without a lot of monkey business and tricking RPM.

No comments:

Post a Comment