MiNT cross-compiler

[Thorsten Glaser]

Hi Vincent,

I=E2=80=99ve been looking for the MiNT cross-compiler in order to be able
to rebuild the Debian package atari-bootstrap. I=E2=80=99ve found your
patches, which seem to have been rebased against current versions
of GCC and binutils. Did you consider submitting those upstream?
Who wrote them and who else contributed to them in significant
(i.e. relevant for FSF copyright assignments) amount? Do you and
them have filed the forms for that?

Do you want me to try to get the patches integrated into standard
Debian, at least? (Intent to submit it upstream helps with that.)

bye,
//mirabilos
--=20
=E2=80=9CHaving a smoking section in a restaurant is like having
a peeing section in a swimming pool.=E2=80=9D
=09=09=09=09=09=09-- Edward Burr

[Vincent Rivière]

I’ve been looking for the MiNT cross-compiler in order to be able
to rebuild the Debian package atari-bootstrap.

Hello, Thorsten.

Thanks for your interest in my cross-tools.

I knew that Linux/68k existed, but I was not aware of the Debian/68k project
and its Atari hardware support.

I’ve found your patches, which seem to have been rebased against current
versions of GCC and binutils.

Yes, I upgrade them when new official versions are available.

Did you consider submitting those upstream?

Your question is about the binutils/GCC patches for the MiNT target, right?

It could also be about submitting my Ubuntu packages upstream. They can also
be successfully recompiled for Debian Testing.

Who wrote them and who else contributed to them in significant
(i.e. relevant for FSF copyright assignments) amount? Do you and
them have filed the forms for that?

The original author of the patches was Guido Flohr. Then I made some changes.
I once asked to the binutils mailing list if I could contribute the MiNT
patches upstream, they told me that the original author had to fill the
forms. So I temporarily gave up. But I could ask Guido for that, even if he
is no more active on the MiNT scene.
Also, I think that a few thing should be cleaned up before an official
integration.
Also, the m68k-atari-mint target uses an a.out variant for executables and
object files, fortunately this has not yet been obsoleted.

Do you want me to try to get the patches integrated into standard
Debian, at least? (Intent to submit it upstream helps with that.)

Of course, that would be great.
But a few other people also produce binaries with those patches (native MiNT
ports, Gentoo...) so it would be better to push them upstream into binutils/GCC.

What components do you use in your Debian distribution, in order to rebuild
the atari-bootstrap package? The full MiNT toolchain (binutils + GCC +
MiNTLib + PML)?

Regards,

[Thorsten Glaser]

Post by Thorsten Glaser
Did you consider submitting those upstream?

Your question is about the binutils/GCC patches for the MiNT target, righ=

t?

Yes, indeed.

It could also be about submitting my Ubuntu packages upstream. They can a=

lso be

successfully recompiled for Debian Testing.

Probably, but I=E2=80=99d rather get them integrated into FSF code if
at all possible. Otherwise, I _can_ try to get them into the
Debian packages (properly separated, etc.), but it=E2=80=99s preferable
to have it upstream (so GCC can fix it if needed, etc).

I once asked to the binutils mailing list if I could contribute the MiNT
patches upstream, they told me that the original author had to fill the f=

orms.

Well yes, everyone who has done copyright-worthy work has to
file them.

What components do you use in your Debian distribution, in order to rebui=

ld the

atari-bootstrap package? The full MiNT toolchain (binutils + GCC + MiNTLi=

b +

PML)?

I=E2=80=99ve got no idea. Nobody seems to know, and there seems to be no
documentation what is needed, where or how to get/make it.

I think binutils and gcc and the flags utility at least. No idea
whether more is needed. (With the Debian hat on, real MiNT also
is not my interest, similar to you. The unpatched source code of
atari-bootstrap uses an m68k-tos-gcc where I can find even less
information of.) If I work on it, I=E2=80=99d like to work from unmodified
Debian sources if at all possible, so I=E2=80=99d be trying to get the
=E2=80=9Cregular=E2=80=9D way of https://wiki.debian.org/BuildingCrossCompi=
lers
to work for these. Maybe even upload the packages, if doko agrees.

bye,
//mirabilos
--=20
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant. Therefore you cannot use ' in a preproces-
sing file in c99 mode.=09-- Ragge
No faith left in ISO C99, undefined behaviour, etc.

[Alan Hourihane]

Post by Thorsten Glaser

Post by Vincent Rivière

Post by Thorsten Glaser
Did you consider submitting those upstream?

Your question is about the binutils/GCC patches for the MiNT target, right?

Yes, indeed.

Post by Vincent Rivière
It could also be about submitting my Ubuntu packages upstream. They can also be
successfully recompiled for Debian Testing.

Probably, but I’d rather get them integrated into FSF code if
at all possible. Otherwise, I _can_ try to get them into the
Debian packages (properly separated, etc.), but it’s preferable
to have it upstream (so GCC can fix it if needed, etc).

Post by Vincent Rivière
I once asked to the binutils mailing list if I could contribute the MiNT
patches upstream, they told me that the original author had to fill the forms.

Well yes, everyone who has done copyright-worthy work has to
file them.

Post by Vincent Rivière
What components do you use in your Debian distribution, in order to rebuild the
atari-bootstrap package? The full MiNT toolchain (binutils + GCC + MiNTLib +
PML)?

I’ve got no idea. Nobody seems to know, and there seems to be no
documentation what is needed, where or how to get/make it.

I've rebuilt atari-bootstrap. Just ping me if you need something.

Alan.

[Thorsten Glaser]

Post by Alan Hourihane
I've rebuilt atari-bootstrap. Just ping me if you need something.

Documentation. Just dropping in binaries will give us
the current situatioin where the .deb ships stuff that
is not in correspondence with the source.

I'd prefer if everything works from as-much-as-possible
unmodified Debian sources.

bye,
//mirabilos
--=20
=E2=80=9CHaving a smoking section in a restaurant is like having
a peeing section in a swimming pool.=E2=80=9D
=09=09=09=09=09=09-- Edward Burr

[Alan Hourihane]

Post by Thorsten Glaser

Post by Alan Hourihane
I've rebuilt atari-bootstrap. Just ping me if you need something.

Documentation. Just dropping in binaries will give us
the current situatioin where the .deb ships stuff that
is not in correspondence with the source.
I'd prefer if everything works from as-much-as-possible
unmodified Debian sources.

So where does this documentatio need updating ?

Alan.

[Thorsten Glaser]

Post by Alan Hourihane

Post by Thorsten Glaser

Post by Alan Hourihane
I've rebuilt atari-bootstrap. Just ping me if you need something.

Documentation. Just dropping in binaries will give us
the current situatioin where the .deb ships stuff that
is not in correspondence with the source.

So where does this documentatio need updating ?

There is none at all. Nobody seems to know (even going back
to postings to debian-68k back in 2004) how to compile it.

bye,
//mirabilos
--=20
=E2=80=9CHaving a smoking section in a restaurant is like having
a peeing section in a swimming pool.=E2=80=9D
=09=09=09=09=09=09-- Edward Burr

[Alan Hourihane]

Post by Thorsten Glaser

Post by Alan Hourihane

Post by Thorsten Glaser

Post by Alan Hourihane
I've rebuilt atari-bootstrap. Just ping me if you need something.

Documentation. Just dropping in binaries will give us
the current situatioin where the .deb ships stuff that
is not in correspondence with the source.

So where does this documentatio need updating ?

There is none at all. Nobody seems to know (even going back
to postings to debian-68k back in 2004) how to compile it.

O.k. so there is none. Isn't there a debian-m68k wiki that I can put it,
so it doesn't get lost ?

Alan.

[Thorsten Glaser]

O.k. so there is none. Isn't there a debian-m68k wiki that I can put it, =

so it

doesn't get lost ?

Yes, but for now it=E2=80=99s enough to write it here, as I intend to
change the atari-bootstrap source package to integrate this
process. Fully. (So there will not be any additional docs required.)

bye,
//mirabilos
--=20
=E2=80=9CHaving a smoking section in a restaurant is like having
a peeing section in a swimming pool.=E2=80=9D
=09=09=09=09=09=09-- Edward Burr

[Thorsten Glaser]

Post by Vincent Rivière

Iï¿œve found your patches, which seem to have been rebased against current
versions of GCC and binutils.

Yes, I upgrade them when new official versions are available.

I’ve taken your gcc-4.6.2-mint-20111028 patch and applied most
of it to my patched (for m68k) variant of the gcc-4.6 source
package now, and filed a wishlist bug against gcc-4.6 to enable
cross-building to non-Debian architectures (alternatively, I
will hack it to accept mint-m68k as Debian architecture, which
is what Debian GNU/MiNT uses).

I’ve changed your patch a little:

• all: whitespace cleaned
• config.guess: not applied, we don’t use that, and it’s bogus anyway
• configure: not applied, we run autoconf during build
• gcc/config/m68k/m68k.h: not applied, because we patched everything
away from __M68881__ to __HAVE_68881__ (including the shipped ffi),
but see below
• gcc/config/m68k/math-68881.h: used a different patch
• gcc/config/m68k/mint.h: defines __M68881__ now, for FreeMiNT only
• gcc/df-problems.c: not applied as we have it already in the package
• gcc/version.c: not applied, not needed in Debian
• libdecnumber/decNumberLocal.h, libiberty/hex.c, libiberty/safe-ctype.c:
applied slightly differently, to look better
• libssp/ssp.c: slightly more nice patch

The patch has been tested by building a cross-compiler from Debian/amd64
to Debian/m68k, but not with/on FreeMiNT or natively yet. (Native Linux
will come next time, and MiNT needs first to have the binutils patch
applied and the cross-compilation target magic issue solved.)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670084

I have copyright assignment papers with the FSF standing, so once you
and Guido get yours accepted, you can take my stuff with no fuss if you
want.

I’m currently a bit slow-going with all this, but I hope that’s okay.

bye,
//mirabilos

[Thorsten Glaser]

Hi Vincent,

I thought you=E2=80=99d appreciate a progress mail.

For now, I=E2=80=99ve built binutils and gcc-4.6 with your patches (applied
liberally rather than literally as I mailed you) and got the dpkg
maintainer to add mint-m68k as a Debian architecture (patch also
applied locally). I=E2=80=99ve built gcc-4.6 as a DEB_STAGE=3Dstage1 compil=
er,
that is, without a C library or header files, but self-contained.

What components do you use in your Debian distribution, in order to rebui=

ld the

atari-bootstrap package? The full MiNT toolchain (binutils + GCC + MiNTLi=

b +

For now I=E2=80=99m doing without mintlib; my next step is to see whether
that is actually enough to build atari-bootstrap or whether I have
to package mintlib, or rather, what we need from it, for Debian as
well. (I looked at your packages, but would prefer to do things in
a more Debian way. No criticism, for a private repository they are
good enough.) If so, I=E2=80=99ll update the gcc patch to build without
DEB_STAGE set. Once I=E2=80=99ve had success, I=E2=80=99ll feed back the pa=
tches
to the respective Debian package maintainers. Independent of whether
atari-bootstrap needs mintlib, if I get bored I may port enough to
get a hello world programme running on MiNT (or even TOS?) on ARAnyM,
so the gcc maintainer can=E2=80=99t complain about the incompleteness of my
patches ;-)

This will take me some time, though; the m68k work has =E2=80=9Cidle priori=
ty=E2=80=9D
for me, i.e. I=E2=80=99m doing it when nothing else pops up, and to educate
myself further (about m68k, Debian, porting, and other unixoid OSes).

PML)?

What is PML? Your page only mentions a link to ftp.funet.fi which
is pretty much saying nothing.

Unfortunately, at the current time I do not know whether the climate
in Debian would be welcoming to a full FreeMiNT (cross-built) develop-
ment suite (there is precedent for a MinGW one though). But indepen-
dent of that, my changes (especially the dpkg one) would help people
reactivating =E2=80=9CDebian GNU/MiNT=E2=80=9D, which ragnar76 hinted at. (=
It=E2=80=99s at
http://web.archive.org/web/20080517034704/http://debian-mint.nocrew.org/
now, since all the Debian-related m68k stuff seems to have been thrown
away from nocrew at some point.) From what I=E2=80=99ve seen so far, doing =
it
would be relatively easy with those patches and what I=E2=80=99ve invested =
into
Debian proper until now, just time-consuming.

bye,
//mirabilos
--=20
=E2=80=9CIt is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.=E2=80=9D
=09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

[Vincent Rivière]

I thought you’d appreciate a progress mail.

Hello, Thorsten.

Thanks for these nice news!

On my side, I'm just back from vacation. Meanwhile, I got the FSF
agreements for the binutils and GCC. Same for Guido Flohr, the original
author of the binutils patch. So I'm ready to start working on the
binutils mailing list to get most of the MiNT patch committed. I plan to
rework the patches in the light of your own work, to be sure we only do
the necessary changes, no more. When the binutils is finished, I will do
the same for GCC, including your changes, of course.
Well, that's my roadmap. That will certainly take some time, but it does
not matter.

After that, the Debian specific patches should be very minimal.

For now, I’ve built binutils and gcc-4.6 with your patches (applied
liberally rather than literally as I mailed you)

Good. My patches are written exactly in that spirit: that works for me,
take what you want for your own needs.

and got the dpkg maintainer to add mint-m68k as a Debian architecture
(patch also applied locally).

Very good.

I’ve built gcc-4.6 as a DEB_STAGE=stage1 compiler,
that is, without a C library or header files, but self-contained.

BTW, that stage1 compiler could be used to compile the emutos package.
EmuTOS is a Free ROM for Atari compatible computers (compatible with the
original OS) and is shipped in binary form inside Debian's aranym and
hatari packages. EmuTOS does not use external libraries (except libgcc).

For now I’m doing without mintlib; my next step is to see whether
that is actually enough to build atari-bootstrap

I don't know what are the contents of that Debian atari-bootstrap
package, so I don't know either.

(I looked at your packages, but would prefer to do things in
a more Debian way. No criticism, for a private repository they are
good enough.)

Sure. My first goal was to get a working cross-compiler, whatever the
method. Now it has proven to work very well, so the next step is to
industrialize the build process, what you are doing.

This will take me some time, though; the m68k work has “idle priority”
for me, i.e. I’m doing it when nothing else pops up, and to educate
myself further (about m68k, Debian, porting, and other unixoid OSes).

Same for me. I had very few free time lately, but I would be very happy
to clean up all that stuff and get everything committed.

What is PML? Your page only mentions a link to ftp.funet.fi which
is pretty much saying nothing.

PML is the Portable Math Library. Normally the MiNT toolchain use fdlibm
as libm, but when I started working on GCC I wasn't aware of it. Today
PML is reliable enough for my needs (including 68881 and ColdFire), so
there is no hurry for me to switch to fdlibm.

Unfortunately, at the current time I do not know whether the climate
in Debian would be welcoming to a full FreeMiNT (cross-built) develop-
ment suite (there is precedent for a MinGW one though).

This is the big question.
I also wonder if the FSF people will welcome the m68k-atari-mint target
which still use the obsolete a.out format for object files and executables.

But independent of that, my changes (especially the dpkg one) would help people
reactivating “Debian GNU/MiNT”

Sure, that will certainly help a lot.

So many thanks for all the work you made so far, there is still much to do.

[Thorsten Glaser]

Post by Vincent Rivière

For now I=E2=80=99m doing without mintlib; my next step is to see whethe=

r

Post by Vincent Rivière

that is actually enough to build atari-bootstrap

I don't know what are the contents of that Debian atari-bootstrap
package, so I don't know either.

OK, here I am.

First of, building a non-stage1 cross compiler is a tad ugly because
even though binutils-multiarch=E2=80=99s got mint support in my patch, it
cannot strip things like libgcc.a:

***@zigo:~ $ m68k-mint-gcc-4.6 -c x.c
***@zigo:~ $ strip x.o
strip:x.o: File format is ambiguous
strip: Matching formats: a.out-m68k-linux a.out-zero-big a.out-sunos-big
1|***@zigo:~ $ m68k-mint-ar rcs libx.a x.o
***@zigo:~ $ strip libx.a
strip:libx.a: File format not recognized
1|***@zigo:~ $ m68k-mint-strip x.o; echo $?

0
***@zigo:~ $ m68k-mint-strip libx.a; echo $?

0
***@zigo:~ $ strip libx.a
strip:libx.a(x.o): Unable to recognise the format of file: File format is a=
mbiguous

It can, however, operate on TOS binaries:

***@zigo:~ $ m68k-mint-gcc-4.6 -nostdlib x.c -o x.tos
***@zigo:~ $ strip x.tos
***@zigo:~ $ echo $?

0

(after adding an empty void __main() to x.c=E2=80=A6 don=E2=80=99t we all l=
ove gcc?)


The problem with this is that building the gcc Debian package invokes
dh_strip, which tries to run strip (not m68k-mint-strip, because it=E2=80=
=99s
NOT a cross-compilation but the native-compilation of a cross toolchain)
on all executables and libraries. The gcc case is special because it
contains both native and foreign objects.

My current idea is to ask joeyh to add a workaround for this to dh_strip
so we can build =E2=80=9Cofficially=E2=80=9D for the archive.


Now to atari-bootstrap: it does need mintlib. I will thus package it
and try to hack on gcc until it builds a regular compiler.

It also needs m68k-atari-mint-flags (m68k-mint-flags probably), but
that=E2=80=99s not in binutils, can you share a source for that?


I didn=E2=80=99t talk to people regarding EmuTOS yet. I figure I=E2=80=99ll=
do that
once I get the cross toolchain packaged and working.

bye,
//mirabilos
--=20
08:05=E2=8E=9C<XTaran:#grml> mika: Does grml have an tool to read Apple
=E2=8E=9C System Log (asl) files? :)
08:08=E2=8E=9C<ft:#grml> yeah. /bin/rm. ;) 08:09=E2=8E=9C<mrud:#grml>=
hexdump -C
08:31=E2=8E=9C<XTaran:#grml> ft, mrud: *g*

[Vincent Rivière]

Post by Thorsten Glaser
strip:x.o: File format is ambiguous
strip: Matching formats: a.out-m68k-linux a.out-zero-big a.out-sunos-big

Yes, that's unfortunate, the BFD library is unable to differentiate those
a.out variants so it does not know how to strip them :-(

Post by Thorsten Glaser
The problem with this is that building the gcc Debian package invokes
dh_strip, which tries to run strip (not m68k-mint-strip, because it’s
NOT a cross-compilation but the native-compilation of a cross toolchain)
on all executables and libraries. The gcc case is special because it
contains both native and foreign objects.

In my lame debian/rules build scripts, when compiling cross-libraries I use
dh_strip -X to exclude the directories containing target libraries. Example
from the mintlib package:
dh_strip -X debian/gemlib-m68k-atari-mint/usr/m68k-atari-mint

Post by Thorsten Glaser
Now to atari-bootstrap: it does need mintlib.

Could you please tell why?
Maybe for building a few MiNT/TOS executables?
Or maybe atari-bootstrap just requires a few includes? In that case they
could just be copied into atari-bootstrap itself...

Post by Thorsten Glaser
It also needs m68k-atari-mint-flags (m68k-mint-flags probably), but
that’s not in binutils, can you share a source for that?

Sure. That flags tool in the mintbin package, also available on my website.

However, ld has similar functionality. Run "m68k-atari-mint-ld
--target-help" to see the equivalent options. Then you can link the programs
using a command line like the flollowing, instead of using the flags command:
m68k-atari-mint-gcc a.c -o a.tos -Wl,--mno-altram

Post by Thorsten Glaser
I didn’t talk to people regarding EmuTOS yet. I figure I’ll do that
once I get the cross toolchain packaged and working.

FYI, I'm the current EmuTOS administrator. That may help if you have trouble :-)

I was surprised to discover that the EmuTOS binaries were distributed in the
aranym and hatari Debian packages without the sources. Since they are
official EmuTOS binaries, and the exact sources are always available on
EmuTOS' SouceForge site, I suppose that's OK...

Good luck.

[Thorsten Glaser]

In my lame debian/rules build scripts, when compiling cross-libraries I u=

se

dh_strip -X to exclude the directories containing target libraries. Examp=

le

dh_strip -X debian/gemlib-m68k-atari-mint/usr/m68k-atari-mint

Well, mintlib is easy, it=E2=80=99s a cross compilation, so we can easily t=
ell
dh_strip to use the cross strip tool.

Post by Thorsten Glaser
Now to atari-bootstrap: it does need mintlib.

Could you please tell why?

Ugh=E2=80=A6 *looks at source*

Maybe for building a few MiNT/TOS executables?
Or maybe atari-bootstrap just requires a few includes? In that case they =

could

just be copied into atari-bootstrap itself...

Apparently, ataboot is a TOS executable and as such needs mintlib.

Post by Thorsten Glaser
It also needs m68k-atari-mint-flags (m68k-mint-flags probably), but
that=E2=80=99s not in binutils, can you share a source for that?

Sure. That flags tool in the mintbin package, also available on my websit=

e.

However, ld has similar functionality. Run "m68k-atari-mint-ld --target-h=

elp"

to see the equivalent options. Then you can link the programs using a com=

mand

m68k-atari-mint-gcc a.c -o a.tos -Wl,--mno-altram

Thanks, that would be easier.

I was surprised to discover that the EmuTOS binaries were distributed in =

the

aranym and hatari Debian packages without the sources. Since they are off=

icial

EmuTOS binaries, and the exact sources are always available on EmuTOS'
SouceForge site, I suppose that's OK...

No, that=E2=80=99s actually an RC bug=E2=80=A6 they actually must even be r=
emoved from
the .orig.tar.gz if it doesn=E2=80=99t include the sources!

Good to know. Let=E2=80=99s keep this quiet until then though, otherwise
ftpmasters would probably remove aranym and hatari from the
archives unless it gets fixed ASAP=E2=80=A6

I=E2=80=99ll work on all these then.

bye,
//mirabilos
--=20
If Harry Potter gets a splitting headache in his scar
when he=E2=80=99s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
=09-- me, wondering why it=E2=80=99s not Jerry Potter=E2=80=A6=E2=80=A6=E2=
=80=A6

[Vincent Rivière]

Well, mintlib is easy, it’s a cross compilation, so we can easily tell
dh_strip to use the cross strip tool.

For my information, could you please tell me how? The dh_strip man page does
not gives any clue...

Apparently, ataboot is a TOS executable and as such needs mintlib.

If you tell me where I can find that source I will look at it.

Good to know. Let’s keep this quiet until then though, otherwise
ftpmasters would probably remove aranym and hatari from the
archives unless it gets fixed ASAP…

After looking closely to that issue, it appears that:
- aranym is clean. The man page suggests to download the EmuTOS ROM from its
official website.
- hatari is wrong. The EmuTOS binary is included without sources in both the
hatari source and binary package.

But I agree, let's leave that aside for now.

[Thorsten Glaser]

For my information, could you please tell me how? The dh_strip man page d=

oes

not gives any clue...

See sub cross_command in /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm:
if DEB_BUILD_GNU_TYPE =E2=89=A0 DEB_HOST_GNU_TYPE, it uses the cross tool
$DEB_HOST_GNU_TYPE-strip instead of strip. So you=E2=80=99ve =E2=80=9Cjust=
=E2=80=9D got to
let dh_strip think you=E2=80=99re cross-compiling.

Normally, you can cross-compile a package with
=E2=80=9Cdpkg-buildpackage -am68k=E2=80=9D. =E2=80=9Cdpkg-buildpackage -ami=
nt-m68k=E2=80=9D will
also be possible soon, as Guillem has included the MiNT patch in
his dpkg tree. (Or use the debs from me.)

Post by Thorsten Glaser
Apparently, ataboot is a TOS executable and as such needs mintlib.

If you tell me where I can find that source I will look at it.

It=E2=80=99s no problem, really. I don=E2=80=99t want to mess with that, an=
d once
I got mintlib packaged, which doesn=E2=80=99t look _too_ difficult and has
benefit _anyway_, I=E2=80=99ll be able to build it.

- aranym is clean. The man page suggests to download the EmuTOS ROM from =

its

official website.

Ah ok.

- hatari is wrong. The EmuTOS binary is included without sources in both =

the

hatari source and binary package.
But I agree, let's leave that aside for now.

OK.

bye,
//mirabilos
--=20
[00:02] <Vutral> gecko: benutzt du emacs ?
[00:03] <gecko> n=C3=B6 [00:03] <gecko> nur n normalen mac
[00:04] <Vutral> argl [00:04] <Vutral> ne den editor
=09-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

[Petr Stehlik]

Post by Vincent Rivière
I was surprised to discover that the EmuTOS binaries were distributed in the
aranym and hatari Debian packages without the sources. Since they are
official EmuTOS binaries, and the exact sources are always available on
EmuTOS' SouceForge site, I suppose that's OK...

No, that's not OK. We were thinking about distributing EmuTOS as part of
ARAnyM Debian package when we were going to put ARAnyM into Debian but
the rules are strict: everything must be rebuildable from source code.
So we gave up on that in ARAnyM and have been waiting until TOS/MiNT GCC
crosscompiler in Debian is up to the task of rebuilding EmuTOS from its
source code.

It would be great if EmuTOS was part of Debian, it could then be made a
suggested dependency of both ARAnyM and hatari :-)

Petr

[Thorsten Glaser]

Post by Petr Stehlik
It would be great if EmuTOS was part of Debian

I=E2=80=99ll work on it. Unless someone else wants to=E2=80=A6?
It=E2=80=99s also a good burn-in test for my cross toolchain procedure=E2=
=80=A6

bye,
//mirabilos
--=20

Post by Petr Stehlik
emacs als auch vi zum Kotzen finde (joe rules) und pine f=C3=BCr den einz=

ig

Post by Petr Stehlik
bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert).=

;)
Hallooooo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
=2E.. pine-User, und das auch noch gewohnheitsm=C3=A4=C3=9Fig ("Oooooooohhh=
"). [aus dasr]

[Miro Kropáček]

Hi guys,

while searching for some gcc stuff in my inbox I've bumped into this thread.

On 3 May 2012 at 18:55, Vincent RiviÚre <***@freesbee.fr>
wrote:

Meanwhile, I got the FSF agreements for the binutils and GCC. Same for

Guido Flohr, the original author of the binutils patch. So I'm ready to
start working on the binutils mailing list to get most of the MiNT patch
committed. I plan to rework the patches in the light of your own work, to
be sure we only do the necessary changes, no more. When the binutils is
finished, I will do the same for GCC, including your changes, of course.

What had happened to this? I mean both FSF submit process and integrating
the FreeMiNT target into Debian.

[Vincent Rivière]

Hello, all.
Sorry, but I totally forgot this old thread. I got busy with other
things, and didn't make any progress regarding to FSF.

But in the meantime, I published to GitHub *all* the know patches
related to the m68k-atari-mint target:
https://github.com/freemint/m68k-atari-mint-binutils-gdb
https://github.com/freemint/m68k-atari-mint-gcc
This will surely help for further work.
Note: There are many branches.

1) Submit m68k-atari-mint-target to binutils/GCC
Main point: I never got any answer from the binutils team regarding to
the following question.
Is the binutils team going to accept a new target derived from m68k-aout?
If the answer is 'no', there is no point to make further efforts.
Unfortunately, until now, no one from the binutils team took the time to
have a look at the MiNT patch, and tell if it would be acceptable or not.
Second: there is a suspicious code in the linker path, when generating
relocations. The code is patched at a strange place, I think it is not
the ideal one (even if the result is correct). I had to move it at a
better place when working on (successful) hybrid a.out/ELF linker. This
has to be thoroughly tested and validated against regressions. This
might be a blocker (or not) for official integration, as the current
linker patch adds mess to a little part of common code.
Third: The current MiNT patch contains various fixes for workarounds
when compiling with GCC 2.95. This should obviously be dropped.
Except the above points, the MiNT patch is supposed to be clean and safe
for other targets (to be carefully checked).

2) integrating the FreeMiNT target into Debian
Personally, I didn't make any efforts for that (yet). But of course,
that would be great.
--
Vincent Rivière

Post by Miro Kropáček
Hi guys,
while searching for some gcc stuff in my inbox I've bumped into this thread.
Meanwhile, I got the FSF agreements for the binutils and GCC. Same
for Guido Flohr, the original author of the binutils patch. So I'm
ready to start working on the binutils mailing list to get most of
the MiNT patch committed. I plan to rework the patches in the light
of your own work, to be sure we only do the necessary changes, no
more. When the binutils is finished, I will do the same for GCC,
including your changes, of course.
What had happened to this? I mean both FSF submit process and
integrating the FreeMiNT target into Debian.
--
MiKRO / Mystic Bytes
http://mikro.atari.org

[Miro Kropáček]

Hi,

I've been wondering, what happened to all of this? I've seen another
Thorsten email a while later proposing to merge those changes but looking
at https://tracker.debian.org/pkg/gcc-4.6 it would seem that all of this
effort is gone? Or is this mint cross compiler accessible in debian
somehow? (except adding Vincent's PPA of course).

Cheers,
Miro

Post by Thorsten Glaser
Hi Vincent,
I thought you’d appreciate a progress mail.
For now, I’ve built binutils and gcc-4.6 with your patches (applied
liberally rather than literally as I mailed you) and got the dpkg
maintainer to add mint-m68k as a Debian architecture (patch also
applied locally). I’ve built gcc-4.6 as a DEB_STAGE=stage1 compiler,
that is, without a C library or header files, but self-contained.

Post by Vincent Rivière
What components do you use in your Debian distribution, in order to

rebuild the

Post by Vincent Rivière
atari-bootstrap package? The full MiNT toolchain (binutils + GCC +

MiNTLib +
For now I’m doing without mintlib; my next step is to see whether
that is actually enough to build atari-bootstrap or whether I have
to package mintlib, or rather, what we need from it, for Debian as
well. (I looked at your packages, but would prefer to do things in
a more Debian way. No criticism, for a private repository they are
good enough.) If so, I’ll update the gcc patch to build without
DEB_STAGE set. Once I’ve had success, I’ll feed back the patches
to the respective Debian package maintainers. Independent of whether
atari-bootstrap needs mintlib, if I get bored I may port enough to
get a hello world programme running on MiNT (or even TOS?) on ARAnyM,
so the gcc maintainer can’t complain about the incompleteness of my
patches ;-)
This will take me some time, though; the m68k work has “idle priority”
for me, i.e. I’m doing it when nothing else pops up, and to educate
myself further (about m68k, Debian, porting, and other unixoid OSes).

Post by Vincent Rivière
PML)?

What is PML? Your page only mentions a link to ftp.funet.fi which
is pretty much saying nothing.
Unfortunately, at the current time I do not know whether the climate
in Debian would be welcoming to a full FreeMiNT (cross-built) develop-
ment suite (there is precedent for a MinGW one though). But indepen-
dent of that, my changes (especially the dpkg one) would help people
reactivating “Debian GNU/MiNT”, which ragnar76 hinted at. (It’s at
http://web.archive.org/web/20080517034704/http://debian-mint.nocrew.org/
now, since all the Debian-related m68k stuff seems to have been thrown
away from nocrew at some point.) From what I’ve seen so far, doing it
would be relatively easy with those patches and what I’ve invested into
Debian proper until now, just time-consuming.
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
--
with a subject of "unsubscribe". Trouble? Contact

[John Paul Adrian Glaubitz]

Hi Miro!

Post by Miro Kropáček
I've been wondering, what happened to all of this? I've seen another
Thorsten email a while later proposing to merge those changes but
looking at https://tracker.debian.org/pkg/gcc-4.6 it would seem that
all of this effort is gone? Or is this mint cross compiler accessible
in debian somehow? (except adding Vincent's PPA of course).

It should be available through snapshot.debian.org [1].

However, I think it would be more reasonable to get those patches either
upstreamed into GCC or LLVM which both support the m68k architecture
these days.

Adrian

Post by Miro Kropáček
[1] http://snapshot.debian.org/

[Thorsten Glaser]

Post by John Paul Adrian Glaubitz
Hi Miro!

Please do not use Googlemail when attempting to collaborate with
OSS maintainers. I don=E2=80=99t know whether you will get this eMail from
me but I will almost certainly not get your response, and Google
are fully to blame for that.

Post by John Paul Adrian Glaubitz

Post by Miro Kropáček
I've been wondering, what happened to all of this? I've seen another

It should be available through snapshot.debian.org [1].

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D632380
has been merged in 4.6.1-2, that was the general m68k one.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D694112
was merged in 4.6.3-15, that was the stage1 cross-compiler
build. So everything I did is available on snapshot.d.o.
It also explains why more than a stage1 isn=E2=80=99t possible with
Debian=E2=80=99s current layout for GCC packages.

Post by John Paul Adrian Glaubitz
However, I think it would be more reasonable to get those patches either
upstreamed into GCC or LLVM which both support the m68k architecture
these days.

You will have to talk with Vincent about that.

bye,
//mirabilos
--=20
St=C3=A9phane, I actually don=E2=80=99t block Googlemail, they=E2=80=99re j=
ust too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

[John Paul Adrian Glaubitz]

Atari MiNT "a.out" format support would also be needed in "binutils".

a.out support was removed in binutils, so you will have to use something
like elf2aout.

While there are newer GCC versions for MiNT provided by different
individuals, Debian packages remained at v4.x. AFAIK GCC 4.x is used
for those because it generates best m68k code when one considers the
size of the generated code vs. its performance.

Did you try LLVM for m68k?

(Choices done for optimizations in non-HW dependent parts of later GCC
versions favor more modern CPUs with larger caches and more RAM in
general, than typical m68k machines have.)
I.e. newer GCC versions are useful for MiNT mainly due to their support
for newer C++ versions.

Yes, indeed.

Adrian

[Eero Tamminen]

Hi,

Post by John Paul Adrian Glaubitz

Atari MiNT "a.out" format support would also be needed in "binutils".

a.out support was removed in binutils, so you will have to use something
like elf2aout.

While there are newer GCC versions for MiNT provided by different
individuals, Debian packages remained at v4.x. AFAIK GCC 4.x is used
for those because it generates best m68k code when one considers the
size of the generated code vs. its performance.

Did you try LLVM for m68k?

No, but there would not be much point yet. LLVM m68k port is still
experimental and AFAIK missing too many features to be a GCC replacement
(e.g. support for pc-relative addressing mode and coldfire).


- Eero

Post by John Paul Adrian Glaubitz

(Choices done for optimizations in non-HW dependent parts of later GCC
versions favor more modern CPUs with larger caches and more RAM in
general, than typical m68k machines have.)
I.e. newer GCC versions are useful for MiNT mainly due to their support
for newer C++ versions.

Yes, indeed.
Adrian

[Eero Tamminen]

Hi,

Post by John Paul Adrian Glaubitz

Post by Miro Kropáček
I've been wondering, what happened to all of this? I've seen another
Thorsten email a while later proposing to merge those changes but
looking at https://tracker.debian.org/pkg/gcc-4.6 it would seem that
all of this effort is gone? Or is this mint cross compiler accessible
in debian somehow? (except adding Vincent's PPA of course).

It should be available through snapshot.debian.org [1].
However, I think it would be more reasonable to get those patches either
upstreamed into GCC or LLVM which both support the m68k architecture
these days.

Atari MiNT "a.out" format support would also be needed in "binutils".

While there are newer GCC versions for MiNT provided by different
individuals, Debian packages remained at v4.x. AFAIK GCC 4.x is used
for those because it generates best m68k code when one considers the
size of the generated code vs. its performance.

(Choices done for optimizations in non-HW dependent parts of later GCC
versions favor more modern CPUs with larger caches and more RAM in
general, than typical m68k machines have.)

I.e. newer GCC versions are useful for MiNT mainly due to their support
for newer C++ versions.


- Eero