Re: [MiNT] Sparemint Coldfire

[Paul Wratt <paul.wratt@gmail.com>]

1st off, sorry about this quoted post of mine, it was suppose to
contain a 5474 & 5475 comparison, as Vincent commented, but my
internet broke, and I have to format to get it back, this is a boot CD
OS, unfortunately note AFROS (Gmail+HW=no go atm :( )

On Fri, Jan 8, 2010 at 12:31 PM, Mark Duckworth
<mduckworth@atari-source.org> wrote:
....

>> Again, SRC2PKG should be able to do this no problem, unless you
>> specifically mean:
>> "v4e RPM's created with v4e RPM"
>>
>>
>
> This allows cheats.  As a platform we shouldn't allow the RPM build process
> to be cheated as it will contribute to overall neglect of things like the
> malloc bug which has plagued for so long.  The RPM build process is easy and
> you can steal spec files from other platforms.
>
you mean src2pkg, or the build process allows cheats. I presume the
malloc bug is not a gcc 4.4.2 or 4.4.3 issue? src2pkg is capable of
cross target and cross source compilation, and the creator is actively
using it to maintain and compile 1000's packages at a time, is it has
to be able to be able to cope with the problems you are concerned
with.

This is not really the point tho, I was just going to get it running
on MiNT doing m68k-atari-mint, an then use it to compile deb and other
srpm packages not currently available. it can handle gentoo and a ton
of other distros, including busybox, which I would say might be the
preferred compilation of sources now (for speed and weight), except
that the standard toolchain is compiled without help, you need man
pages :)

....

>> would this not make more sense then:
>> aalib-1.2-1.m5474-v4e-mint.rpm
>> aalib-1.2-1.m5475-v4e-mint.rpm
>> aalib-1.2-1.v4e-mint.rpm
>>
>
> Maybe v4emint.  Either way, if there is no vote on it, I'm just going to set
> it to what I think is best which is either m5474mint or v4emint.  Probably
> v4emint
>
I would prefer at least v4e-mint, simply for readability, and it helps
maintain standard and current mint rpm naming conventions too, but it
is the glance and see method, instead of the look and "oh yeh" study
method

I presume the rest of the package name is per the package distribution

...


>> BTW: why is there still a need to patch is the source is C/C++, wasn't
>> that the point of another discussion re: ASM. I do however understand
>> the need to patch for GCC 4.x "strictness" due to the age of
>> sources...
>>
>
> It's a lot of explanation to explain this but numerous patches are needed to
> build typical unix packages on our platform due to subtle differences and
> missing features.  A classic example was building git today.  Git wants to
> use mmap which our system doesn't have due to lack of vm which means it must
> be coded around.  Luckily someone already did this work and you just have to
> enable it.  Then in the posix layer there is another problem.  On almost
> every platform the __S_IFLNK octal for file permissions is defined as
> 0120000.  On our platform it is defined as 0160000 which collides with a git
> cache type.  So now I have to learn about posix, learn what we can change
> where to make this work.  Most likely I'll be changing the octal value for
> the git cache which means a patch and it means that a tarred git repository
> may not work from our platform on linux and vice versa.  This is the type of
> work that needs to be done to build each package.  GCC 4.4.2 is much
> stricter than 2.95.3 which means builds will fail for things that worked
> before.  This basically means that a lot of the software needs to be either
> updated or manually fixed patch by patch.  Since I am working on sparemint
> for modern machines like coldari I will update ;)
>
> Really with newer packages we will run even more into problems with missing
> features like dynamic loading, virtual memory.  It will make porting the
> most recent software more challenging than it has been in the past.
>
> Thanks,
> Mark
>
cheers for that, there is little bits of gold in these dev related posts

I know someone wanted to look at implementing vm, and I know there is
a need for dynamic loading and a.out (?), which I would be capable of
supplying about 12 months time, which is of course no use atm, and
requires me to do a few other things in the meantime

The "challenge" you talk about that was something I already understood
before I ever joined the mail list of started compiling with gcc. I
managed to find a server that has source packages that date to around
the same time period as the current load of sparemint packages, some
are even the same or just a few clicks up or the end of that
generation, they are sun rpm packages to

I figured that would be a good way to quickly learn the differences
and allow some updates to be supplied, before I moved onto the other
50% which were not part of sparemint, only some of which where
available else where (I did a lot of searching).

Anyway, I have not got to this yet, soon maybe, but I had alredy
collect the CMake, JAM excetera...

It occurs to be that MAKE is half the problem with native gcc built
tools, besides gcc emense size, and a JAM system might be lighter on
the native system. I have not yet tried using Miko's CMake yet, so I
dont know how well it will perform compared to make.

Part of getting a descent devkit together tho is testing all this. At
some point I will no doubt get down to gcc source, which I know is
complex, but from my point of view, not as complex as kernel, as I
have studied c & c++ compilers in great depth in the past, so I dont
fee out of my depth (or upto chest height, kernel being that limit, I
have to go with snorkel and water wings :) )

I had notices distcc because of some other project I was looking as, I
will take a closer look at some point over the next month, along with
some other tools..

Paul