Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
MiNT cross-compiler
10 views
Skip to first unread message
Thorsten Glaser
Feb 18, 2012, 6:00:02 PM2/18/12
to
Hi Vincent,
I’ve been looking for the MiNT cross-compiler in order to be able
to rebuild the Debian package atari-bootstrap. I’ve 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
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.1...@herc.mirbsd.org
I’ve been looking for the MiNT cross-compiler in order to be able
to rebuild the Debian package atari-bootstrap. I’ve 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
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.1...@herc.mirbsd.org
Vincent Rivière
Feb 19, 2012, 7:40:02 PM2/19/12
to
Thorsten Glaser wrote:
> I’ve been looking for the MiNT cross-compiler in order to be able
> to rebuild the Debian package atari-bootstrap.
Hello, Thorsten.
> I’ve been looking for the MiNT cross-compiler in order to be able
> to rebuild the Debian package atari-bootstrap.
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.
> Did you consider submitting those upstream?
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?
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.)
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,
--
Vincent Rivière
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
Feb 19, 2012, 8:00:02 PM2/19/12
to
Vincent Rivière dixit:
>> Did you consider submitting those upstream?
>
> Your question is about the binutils/GCC patches for the MiNT target, right?
Yes, indeed.
> 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).
> 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.
> 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 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’d like to work from unmodified
Debian sources if at all possible, so I’d be trying to get the
“regular” way of https://wiki.debian.org/BuildingCrossCompilers
to work for these. Maybe even upload the packages, if doko agrees.
bye,
//mirabilos
--
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. -- Ragge
No faith left in ISO C99, undefined behaviour, etc.
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.1...@herc.mirbsd.org
>> 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.
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).
> 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.
file them.
> 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)?
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’d like to work from unmodified
Debian sources if at all possible, so I’d be trying to get the
“regular” way of https://wiki.debian.org/BuildingCrossCompilers
to work for these. Maybe even upload the packages, if doko agrees.
bye,
//mirabilos
--
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. -- Ragge
No faith left in ISO C99, undefined behaviour, etc.
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alan Hourihane
Feb 20, 2012, 4:00:01 AM2/20/12
to
On 20/02/12 00:56, Thorsten Glaser wrote:
> Vincent Rivière dixit:
>
>>> Did you consider submitting those upstream?
>> Your question is about the binutils/GCC patches for the MiNT target, right?
> Yes, indeed.
>
>> 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).
>
>> 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.
>
>> 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.
> Vincent Rivière dixit:
>
>>> Did you consider submitting those upstream?
>> Your question is about the binutils/GCC patches for the MiNT target, right?
> Yes, indeed.
>
>> 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).
>
>> 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.
>
>> 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.
Alan.
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
Feb 20, 2012, 7:20:02 PM2/20/12
to
Alan Hourihane dixit:
> 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
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
> I've rebuilt atari-bootstrap. Just ping me if you need something.
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
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alan Hourihane
Feb 21, 2012, 9:10:03 AM2/21/12
to
On 21/02/12 00:11, Thorsten Glaser wrote:
> Alan Hourihane dixit:
>
>> 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 Hourihane dixit:
>
>> 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.
>
Alan.
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
Feb 21, 2012, 1:30:02 PM2/21/12
to
Alan Hourihane dixit:
> On 21/02/12 00:11, Thorsten Glaser wrote:
>> Alan Hourihane dixit:
>>
>>> 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.
to postings to debian-68k back in 2004) how to compile it.
bye,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
> On 21/02/12 00:11, Thorsten Glaser wrote:
>> Alan Hourihane dixit:
>>
>>> 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
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alan Hourihane
Feb 21, 2012, 1:40:02 PM2/21/12
to
On 21/02/12 18:16, Thorsten Glaser wrote:
> Alan Hourihane dixit:
>
>> On 21/02/12 00:11, Thorsten Glaser wrote:
>>> Alan Hourihane dixit:
>>>
>>>> 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,
> Alan Hourihane dixit:
>
>> On 21/02/12 00:11, Thorsten Glaser wrote:
>>> Alan Hourihane dixit:
>>>
>>>> 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.
>
>
so it doesn't get lost ?
Alan.
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
Feb 21, 2012, 2:30:02 PM2/21/12
to
Alan Hourihane dixit:
> 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’s 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
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
> O.k. so there is none. Isn't there a debian-m68k wiki that I can put it, so it
> doesn't get lost ?
change the atari-bootstrap source package to integrate this
process. Fully. (So there will not be any additional docs required.)
bye,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
-- Edward Burr
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
May 2, 2012, 1:30:02 PM5/2/12
to
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.
Vincent Rivière dixit:
> What components do you use in your Debian distribution, in order to rebuild the
> 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).
> 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
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.1...@herc.mirbsd.org
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.
Vincent Rivière dixit:
> What components do you use in your Debian distribution, in order to rebuild the
> atari-bootstrap package? The full MiNT toolchain (binutils + GCC + MiNTLib +
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).
> 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
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Rivière
May 3, 2012, 5:00:02 AM5/3/12
to
Thorsten Glaser wrote:
> I thought you’d appreciate a progress mail.
Hello, Thorsten.
> I thought you’d appreciate a progress mail.
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)
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).
> I’ve built gcc-4.6 as a DEB_STAGE=stage1 compiler,
> that is, without a C library or header files, but self-contained.
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
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.)
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).
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.
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).
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.
--
Vincent Rivière
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
May 6, 2012, 4:40:01 PM5/6/12
to
Vincent Rivière dixit:
>> 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.
OK, here I am.
First of, building a non-stage1 cross compiler is a tad ugly because
even though binutils-multiarch’s got mint support in my patch, it
cannot strip things like libgcc.a:
tg@zigo:~ $ m68k-mint-gcc-4.6 -c x.c
tg@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|tg@zigo:~ $ m68k-mint-ar rcs libx.a x.o
tg@zigo:~ $ strip libx.a
strip:libx.a: File format not recognized
1|tg@zigo:~ $ m68k-mint-strip x.o; echo $?
0
tg@zigo:~ $ m68k-mint-strip libx.a; echo $?
0
tg@zigo:~ $ strip libx.a
strip:libx.a(x.o): Unable to recognise the format of file: File format is ambiguous
It can, however, operate on TOS binaries:
tg@zigo:~ $ m68k-mint-gcc-4.6 -nostdlib x.c -o x.tos
tg@zigo:~ $ strip x.tos
tg@zigo:~ $ echo $?
0
(after adding an empty void __main() to x.c… don’t we all love 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’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.
My current idea is to ask joeyh to add a workaround for this to dh_strip
so we can build “officially” 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’s not in binutils, can you share a source for that?
I didn’t talk to people regarding EmuTOS yet. I figure I’ll do that
once I get the cross toolchain packaged and working.
bye,
//mirabilos
--
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
⎜ System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;) 08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
>> 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.
First of, building a non-stage1 cross compiler is a tad ugly because
even though binutils-multiarch’s got mint support in my patch, it
cannot strip things like libgcc.a:
tg@zigo:~ $ m68k-mint-gcc-4.6 -c x.c
tg@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|tg@zigo:~ $ m68k-mint-ar rcs libx.a x.o
tg@zigo:~ $ strip libx.a
strip:libx.a: File format not recognized
1|tg@zigo:~ $ m68k-mint-strip x.o; echo $?
0
tg@zigo:~ $ m68k-mint-strip libx.a; echo $?
0
tg@zigo:~ $ strip libx.a
strip:libx.a(x.o): Unable to recognise the format of file: File format is ambiguous
It can, however, operate on TOS binaries:
tg@zigo:~ $ m68k-mint-gcc-4.6 -nostdlib x.c -o x.tos
tg@zigo:~ $ strip x.tos
tg@zigo:~ $ echo $?
0
(after adding an empty void __main() to x.c… don’t we all love 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’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.
My current idea is to ask joeyh to add a workaround for this to dh_strip
so we can build “officially” 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’s not in binutils, can you share a source for that?
I didn’t talk to people regarding EmuTOS yet. I figure I’ll do that
once I get the cross toolchain packaged and working.
bye,
//mirabilos
--
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
⎜ System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;) 08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Rivière
May 6, 2012, 5:20:01 PM5/6/12
to
Thorsten Glaser wrote:
> tg@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
Yes, that's unfortunate, the BFD library is unable to differentiate those
> tg@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
a.out variants so it does not know how to strip them :-(
> 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.
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
> Now to atari-bootstrap: it does need mintlib.
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...
> It also needs m68k-atari-mint-flags (m68k-mint-flags probably), but
> that’s not in binutils, can you share a source for that?
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
> I didn’t talk to people regarding EmuTOS yet. I figure I’ll do that
> once I get the cross toolchain packaged and working.
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.
--
Vincent Rivière
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
May 6, 2012, 5:50:01 PM5/6/12
to
Vincent Rivière dixit:
> 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
Well, mintlib is easy, it’s a cross compilation, so we can easily tell
dh_strip to use the cross strip tool.
>> Now to atari-bootstrap: it does need mintlib.
>
> Could you please tell why?
Ugh… *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.
>> 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
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 official
> EmuTOS binaries, and the exact sources are always available on EmuTOS'
> SouceForge site, I suppose that's OK...
No, that’s actually an RC bug… they actually must even be removed from
the .orig.tar.gz if it doesn’t include the sources!
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…
I’ll work on all these then.
bye,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
> 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
dh_strip to use the cross strip tool.
>> 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...
>> 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
> 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...
the .orig.tar.gz if it doesn’t include the sources!
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…
I’ll work on all these then.
bye,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vincent Rivière
May 6, 2012, 6:30:02 PM5/6/12
to
Thorsten Glaser wrote:
> 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
> Well, mintlib is easy, it’s a cross compilation, so we can easily tell
> dh_strip to use the cross strip tool.
not gives any clue...
> Apparently, ataboot is a TOS executable and as such needs mintlib.
> 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…
- 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.
--
Vincent Rivière
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
May 6, 2012, 6:50:01 PM5/6/12
to
Vincent Rivière dixit:
> For my information, could you please tell me how? The dh_strip man page does
> not gives any clue...
See sub cross_command in /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm:
if DEB_BUILD_GNU_TYPE ≠ DEB_HOST_GNU_TYPE, it uses the cross tool
$DEB_HOST_GNU_TYPE-strip instead of strip. So you’ve “just” got to
let dh_strip think you’re cross-compiling.
Normally, you can cross-compile a package with
“dpkg-buildpackage -am68k”. “dpkg-buildpackage -amint-m68k” will
also be possible soon, as Guillem has included the MiNT patch in
his dpkg tree. (Or use the debs from me.)
>> 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’s no problem, really. I don’t want to mess with that, and once
I got mintlib packaged, which doesn’t look _too_ difficult and has
benefit _anyway_, I’ll be able to build it.
> 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.
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
--
[00:02] <Vutral> gecko: benutzt du emacs ?
[00:03] <gecko> nö [00:03] <gecko> nur n normalen mac
[00:04] <Vutral> argl [00:04] <Vutral> ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
> For my information, could you please tell me how? The dh_strip man page does
> not gives any clue...
if DEB_BUILD_GNU_TYPE ≠ DEB_HOST_GNU_TYPE, it uses the cross tool
$DEB_HOST_GNU_TYPE-strip instead of strip. So you’ve “just” got to
let dh_strip think you’re cross-compiling.
Normally, you can cross-compile a package with
“dpkg-buildpackage -am68k”. “dpkg-buildpackage -amint-m68k” will
also be possible soon, as Guillem has included the MiNT patch in
his dpkg tree. (Or use the debs from me.)
>> 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.
I got mintlib packaged, which doesn’t look _too_ difficult and has
benefit _anyway_, I’ll be able to build it.
> 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.
bye,
//mirabilos
--
[00:02] <Vutral> gecko: benutzt du emacs ?
[00:03] <gecko> nö [00:03] <gecko> nur n normalen mac
[00:04] <Vutral> argl [00:04] <Vutral> ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Petr Stehlik
May 7, 2012, 12:00:01 PM5/7/12
to
Vincent Rivière píše v Sun 06. 05. 2012 v 23:13 +0200:
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
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1336403481.15308.26.camel@aspire
> 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 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...
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
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
May 7, 2012, 12:20:02 PM5/7/12
to
Petr Stehlik dixit:
>It would be great if EmuTOS was part of Debian
I’ll work on it. Unless someone else wants to…?
It’s also a good burn-in test for my cross toolchain procedure…
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallooooo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooooooohhh"). [aus dasr]
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/Pine.BSM.4.64L.12...@herc.mirbsd.org
>It would be great if EmuTOS was part of Debian
It’s also a good burn-in test for my cross toolchain procedure…
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallooooo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooooooohhh"). [aus dasr]
--
To UNSUBSCRIBE, email to debian-68...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Miro Kropáček
Aug 19, 2017, 10:40:04 PM8/19/17
to
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 <vincent...@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.
Vincent Rivière
Aug 21, 2017, 3:50:03 AM8/21/17
to
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
Le 20/08/2017 à 04:37, Miro Kropáček a écrit :
> 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 <vincent...@freesbee.fr
> <mailto:vincent...@freesbee.fr>> wrote:
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
Le 20/08/2017 à 04:37, Miro Kropáček a écrit :
> 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 <vincent...@freesbee.fr
Miro Kropáček
May 23, 2023, 7:10:04 AM5/23/23
to
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
John Paul Adrian Glaubitz
May 23, 2023, 7:40:04 AM5/23/23
to
Hi Miro!
On Tue, 2023-05-23 at 13:07 +0200, Miro Kropáček wrote:
> 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
> [1] http://snapshot.debian.org/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, 2023-05-23 at 13:07 +0200, Miro Kropáček wrote:
> 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).
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
> [1] http://snapshot.debian.org/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Thorsten Glaser
May 23, 2023, 3:10:04 PM5/23/23
to
John Paul Adrian Glaubitz dixit:
>Hi Miro!
Please do not use Googlemail when attempting to collaborate with
OSS maintainers. I don’t 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.
>On Tue, 2023-05-23 at 13:07 +0200, Miro Kropáček wrote:
>> I've been wondering, what happened to all of this? I've seen another
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632380
has been merged in 4.6.1-2, that was the general m68k one.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694112
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’t possible with
Debian’s current layout for GCC packages.
>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
--
Stéphane, I actually don’t block Googlemail, they’re just 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.
>Hi Miro!
Please do not use Googlemail when attempting to collaborate with
OSS maintainers. I don’t 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.
>On Tue, 2023-05-23 at 13:07 +0200, Miro Kropáček wrote:
>> I've been wondering, what happened to all of this? I've seen another
has been merged in 4.6.1-2, that was the general m68k one.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694112
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’t possible with
Debian’s current layout for GCC packages.
>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.
bye,
//mirabilos
--
Stéphane, I actually don’t block Googlemail, they’re just 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.
Eero Tamminen
May 24, 2023, 12:20:05 PM5/24/23
to
Hi,
On 23.5.2023 14.34, John Paul Adrian Glaubitz wrote:
> On Tue, 2023-05-23 at 13:07 +0200, Miro Kropáček wrote:
>> 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
On 23.5.2023 14.34, John Paul Adrian Glaubitz wrote:
> On Tue, 2023-05-23 at 13:07 +0200, Miro Kropáček wrote:
>> 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.
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
John Paul Adrian Glaubitz
May 24, 2023, 12:20:05 PM5/24/23
to
On Wed, 2023-05-24 at 19:11 +0300, Eero Tamminen wrote:
> 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
> Atari MiNT "a.out" format support would also be needed in "binutils".
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.
> (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.
Adrian
Eero Tamminen
May 26, 2023, 7:00:05 AM5/26/23
to
Hi,
On 24.5.2023 19.19, John Paul Adrian Glaubitz wrote:
> On Wed, 2023-05-24 at 19:11 +0300, Eero Tamminen wrote:
>> 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
On 24.5.2023 19.19, John Paul Adrian Glaubitz wrote:
> On Wed, 2023-05-24 at 19:11 +0300, Eero Tamminen wrote:
>> 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?
experimental and AFAIK missing too many features to be a GCC replacement
(e.g. support for pc-relative addressing mode and coldfire).
- Eero
0 new messages