[M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)
mika at async.caltech.edu
mika at async.caltech.edu
Sun Jan 19 21:13:08 CET 2014
There were some bugs we never got around to addressing with the C backend,
weren't there? A crash that didn't happen with native backend.
I've been using the "native" at more or less the head on very recent
Debian and the Raspberry Pi for a while now with no problems to speak of.
(As long as you only use user threads... but that's another story, I think.)
Mika
Jay K writes:
>--_f56ed036-02b3-494e-bb04-f7c58d07fa28_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>I understand your reluctance.
>
>
>> Is the goal just to get FreeBSD to have a binary with the latest
>> sources?
>
>
>Yes=2C and to make sure the build process works for you.
>
>
>> Shouldn't FreeBSD use the C backend too?
>
>
>Every target should. I haven't convinced everyone yet.
>There is less resistance for new targets=2C like AMD64_NT and ARM_LINUX=2C =
>which are working=2C using the C backend.
>There are downsides to the C backend:
> - it is slower to compiler =20
> - debugging is degraded on systems that have m3gdb =20
> (debugging is much better on systems w/o m3gdb)=20
>
>
>And there are advantages not yet implemented=2C in particular=2C efficient =
>exception handling by generating C++.
>
>
>> > gcc/amd64 works for the same
>> > for Linux=2C FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.
>>=20
>> I assume you mean after the system understands this target. There will
>> be a lot of files with __FreeBSD__ that need to be changed to
>> __FreeBSD__ || __DragonFly__ as well. In any case=2C I'll have to
>> regenerate a bunch of patches from my current work.
>
>
>Your patches should apply fairly cleanly to any new checkout.
>I am willing to through them and apply them to CVS if you want -- depends o=
>n if you are ok with my stealing your credit=2C vs. you want to commit them=
> yourselves.
>I already skimmed them and they all look easy.
>DragonflyBSD is basically FreeBSD by another name.
>Yes=2C a ton of work has been done on the kernel=2C file systems=2C maybe p=
>orts.
>But the ABI is almost the same -- heck=2C for the most part=2C Linux=3D=3DN=
>etBSD=3D=3DFreeBSD=3D=3DOpenBSD.
>Sure=2C they might be implemented differently=2C but they are highly source=
> compatible and every highly object code compatible.
>
>
>> I must be misunderstanding what you mean by "upgrade". It's the
>> cross-compiler that's complaining=2C and it was built by the latest patch=
>es.
>
>Agreed=2C we are both missing something simple.
>Usually this is the error you get when you don't upgrade Target.i3/Target.m=
>3.
>If you want to press on with the current approach and ignore my advise=2C i=
>t should be possible to step through all this.
>To start=2C break on Target__Init and see if it returns true or false.
>
>
>> statically while a bug in the cm3 sources caused those libraries to link
>> dynamically (which is why release binaries don't run on current FreeBSD)
>
>
>Ugh. I saw something about that in your diffs. Definitely we intend to link=
> statically.
>I actually went to the trouble of removing use of gmp/mpfr/mpc in current s=
>ource.
>They are used for actually very little and aren't worth it.
>
>
> - Jay
>
>
>> Date: Sun=2C 19 Jan 2014 13:38:32 +0100
>> From: adacore at marino.st
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)
>>=20
>> On 1/19/2014 13:17=2C Jay K wrote:
>> > Hey..I like that that does capture some of My Way.=20
>> > Here is my independent off the cuff write up though:
>> > I know the ports system is nice.
>> > I know we really need to be in it for many operating systems.
>> > I suspect your problem is that you didn't "upgrade" to apply you
>> > changes at the right time.
>>=20
>> I must be misunderstanding what you mean by "upgrade". It's the
>> cross-compiler that's complaining=2C and it was built by the latest patch=
>es.
>>=20
>>=20
>> > Do any of these work for you:
>> > https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html
>>=20
>> I'm not clear to which set you are referring.
>> There's no need for a binary set=2C modula3 now builds on FreeBSD 9 and
>> FreeBSD 10 (http://www.freshports.org/lang/modula3)=2C which is also
>> superior to the release binaries because they link gmp and mpfr
>> statically while a bug in the cm3 sources caused those libraries to link
>> dynamically (which is why release binaries don't run on current FreeBSD)
>>=20
>> Then there are the source distributions=2C but they are from 2012 so they
>> aren't exactly fresh either.
>>=20
>>=20
>> > Anyway=2C please try this:=20
>> > Ignore DragonFly at first.=20
>> > Go to a system with a working cm3. Such as FreeBSD. Linux. Almost
>> > anything.=20
>> > Such as from ports.=20
>> > Make a backup=2C e.g. of /usr/local/cm3.=20
>> > My instructions are unfortunately destructive of the existing install=
>.=20
>> > Checkout the full current CVS repository.=20
>> > In that repository=2C run scripts/python/upgrade.py.=20
>> > If that doesn't work=2C stop=2C and we'll help.=20
>>=20
>> Is the goal just to get FreeBSD to have a binary with the latest
>> sources? If so=2C I'd just modify the port to do that now that we have
>> working binary bootstraps. The main reason I'm reluctant is that it
>> took over a week to make the cm3 port=2C I've never had so much difficult=
>y
>> before. (I've also spent another week on the DragonFly port). So I'm
>> "resisting" because of how much work it already took. That's why I was
>> trying to port DragonFly=2C THEN update to latest rather than update to
>> latest and then port DragonFly. (in other words=2C going forward seems a
>> short path than backtracking)
>>=20
>>=20
>>=20
>> > If that does work=2C apply your diffs. And upgrade.py again. You can =
>say
>> > "upgrade.py skipgcc" here.=20
>> > Then boot1.py c amd64_dragonflybsd =20
>> > Make sure you say "c" and the target "amd64_dragonflybsd"=2C anywhe=
>re
>> > on the command line.=20
>> > Ok=2C "c" is actually up to you. Since nobody messes with ABI much=
>=2C
>> > gcc/amd64 works for the same
>> > for Linux=2C FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.
>>=20
>> I assume you mean after the system understands this target. There will
>> be a lot of files with __FreeBSD__ that need to be changed to
>> __FreeBSD__ || __DragonFly__ as well. In any case=2C I'll have to
>> regenerate a bunch of patches from my current work.
>>=20
>>=20
>> > If this works=2C it will give you=2C roughly amd64_dragonflybsd*.tar.=
>gz=20
>> > Copy that to your Dragonfly system=2C extract it=2C cd into it=2C mak=
>e.=20
>> > If that works=2C you have a native cm3.=20
>> > Run it. It should say "can't find cm3.cfg". =20
>> > Now on Dragonfly=2C mkdir -p /usr/local/cm3/bin=20
>> > cp cm3 /usr/local/cm3/bin =20
>> > export PATH=3D/usr/local/cm3/bin:$PATH
>> > full CVS checkout =20
>> > cd scripts/python =3B ./boot2.sh=20
>> > =20
>> > You will need to have made small changes to pylib.py for this to work=
>.
>> > (And your config file should say to use the C backend=2C like Darwin =
>and
>> > ARM_LINUX do.)
>>=20
>>=20
>> Well=2C I'm thrilled if I don't have to patch gcc again=2C that takes a l=
>ong
>> time. Shouldn't FreeBSD use the C backend too?
>>=20
>> John
> =
>
>--_f56ed036-02b3-494e-bb04-f7c58d07fa28_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 12pt=3B
>font-family:Calibri
>}
>--></style></head>
><body class=3D'hmmessage'><div dir=3D'ltr'>I understand your reluctance.<br=
>><br><br>>=3B Is the goal just to get FreeBSD to have a binary with the l=
>atest<br>>=3B sources?<br><br><br>Yes=2C and to make sure the build proce=
>ss works for you.<br><br><br>>=3B Shouldn't FreeBSD use the C backend too=
>?<br><br><br>Every target should. I haven't convinced everyone yet.<br>Ther=
>e is less resistance for new targets=2C like AMD64_NT and ARM_LINUX=2C whic=
>h are working=2C using the C backend.<br>There are downsides to the C backe=
>nd:<br> =3B - it is slower to compiler =3B <br> =3B - debugging=
> is degraded on systems that have m3gdb =3B <br> =3B(debugging is m=
>uch better on systems w/o m3gdb) <br><br><br>And there are advantages not y=
>et implemented=2C in particular=2C efficient exception handling by generati=
>ng C++.<br><br><br>>=3B >=3B gcc/amd64 works for the same<br>>=3B >=
>=3B for Linux=2C FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.<br>>=
>=3B <br>>=3B I assume you mean after the system understands this target. =
> There will<br>>=3B be a lot of files with __FreeBSD__ that need to be ch=
>anged to<br>>=3B __FreeBSD__ || __DragonFly__ as well. In any case=2C I'=
>ll have to<br>>=3B regenerate a bunch of patches from my current work.<br=
>><br><br>Your patches should apply fairly cleanly to any new checkout.<br>I=
> am willing to through them and apply them to CVS if you want -- depends on=
> if you are ok with my stealing your credit=2C vs. you want to commit them =
>yourselves.<br>I already skimmed them and they all look easy.<br>DragonflyB=
>SD is basically FreeBSD by another name.<br>Yes=2C a ton of work has been d=
>one on the kernel=2C file systems=2C maybe ports.<br>But the ABI is almost =
>the same -- heck=2C for the most part=2C Linux=3D=3DNetBSD=3D=3DFreeBSD=3D=
>=3DOpenBSD.<br>Sure=2C they might be implemented differently=2C but they ar=
>e highly source compatible and every highly object code compatible.<br><br>=
><br>>=3B I must be misunderstanding what you mean by "upgrade". It's the=
><br>>=3B cross-compiler that's complaining=2C and it was built by the lat=
>est patches.<br><br>Agreed=2C we are both missing something simple.<br>Usua=
>lly this is the error you get when you don't upgrade Target.i3/Target.m3.<b=
>r>If you want to press on with the current approach and ignore my advise=2C=
> it should be possible to step through all this.<br>To start=2C break on Ta=
>rget__Init and see if it returns true or false.<br><br><br>>=3B staticall=
>y while a bug in the cm3 sources caused those libraries to link<br>>=3B d=
>ynamically (which is why release binaries don't run on current FreeBSD)<br>=
><br><br>Ugh. I saw something about that in your diffs. Definitely we intend=
> to link statically.<br>I actually went to the trouble of removing use of g=
>mp/mpfr/mpc in current source.<br>They are used for actually very little an=
>d aren't worth it.<br><br><br> =3B- Jay<br><br><br><div>>=3B Date: Su=
>n=2C 19 Jan 2014 13:38:32 +0100<br>>=3B From: adacore at marino.st<br>>=3B=
> To: jay.krell at cornell.edu<br>>=3B CC: m3devel at elegosoft.com<br>>=3B Su=
>bject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)<br>&g=
>t=3B <br>>=3B On 1/19/2014 13:17=2C Jay K wrote:<br>>=3B >=3B Hey..I =
>like that that does capture some of My Way. <br>>=3B >=3B Here is my in=
>dependent off the cuff write up though:<br>>=3B >=3B I know the ports =
>system is nice.<br>>=3B >=3B I know we really need to be in it for man=
>y operating systems.<br>>=3B >=3B I suspect your problem is that you d=
>idn't "upgrade" to apply you<br>>=3B >=3B changes at the right time.<br=
>>>=3B <br>>=3B I must be misunderstanding what you mean by "upgrade". =
>It's the<br>>=3B cross-compiler that's complaining=2C and it was built by=
> the latest patches.<br>>=3B <br>>=3B <br>>=3B >=3B Do any of thes=
>e work for you:<br>>=3B >=3B https://modula3.elegosoft.com/cm3/snaps/s=
>napshot-index.html<br>>=3B <br>>=3B I'm not clear to which set you are =
>referring.<br>>=3B There's no need for a binary set=2C modula3 now builds=
> on FreeBSD 9 and<br>>=3B FreeBSD 10 (http://www.freshports.org/lang/modu=
>la3)=2C which is also<br>>=3B superior to the release binaries because th=
>ey link gmp and mpfr<br>>=3B statically while a bug in the cm3 sources ca=
>used those libraries to link<br>>=3B dynamically (which is why release bi=
>naries don't run on current FreeBSD)<br>>=3B <br>>=3B Then there are th=
>e source distributions=2C but they are from 2012 so they<br>>=3B aren't e=
>xactly fresh either.<br>>=3B <br>>=3B <br>>=3B >=3B Anyway=2C plea=
>se try this: <br>>=3B >=3B Ignore DragonFly at first. <br>>=3B >=
>=3B Go to a system with a working cm3. Such as FreeBSD. Linux. Almost<br>=
>>=3B >=3B anything. <br>>=3B >=3B Such as from ports. <br>>=3B =
>>=3B Make a backup=2C e.g. of /usr/local/cm3. <br>>=3B >=3B My in=
>structions are unfortunately destructive of the existing install. <br>>=
>=3B >=3B Checkout the full current CVS repository. <br>>=3B >=3B =
>In that repository=2C run scripts/python/upgrade.py. <br>>=3B >=3B If=
> that doesn't work=2C stop=2C and we'll help. <br>>=3B <br>>=3B Is the =
>goal just to get FreeBSD to have a binary with the latest<br>>=3B sources=
>? If so=2C I'd just modify the port to do that now that we have<br>>=3B =
>working binary bootstraps. The main reason I'm reluctant is that it<br>>=
>=3B took over a week to make the cm3 port=2C I've never had so much difficu=
>lty<br>>=3B before. (I've also spent another week on the DragonFly port)=
>. So I'm<br>>=3B "resisting" because of how much work it already took. =
>That's why I was<br>>=3B trying to port DragonFly=2C THEN update to lates=
>t rather than update to<br>>=3B latest and then port DragonFly. (in othe=
>r words=2C going forward seems a<br>>=3B short path than backtracking)<br=
>>>=3B <br>>=3B <br>>=3B <br>>=3B >=3B If that does work=2C appl=
>y your diffs. And upgrade.py again. You can say<br>>=3B >=3B "upgrade.p=
>y skipgcc" here. <br>>=3B >=3B Then boot1.py c amd64_dragonflybsd <=
>br>>=3B >=3B Make sure you say "c" and the target "amd64_dragonflyb=
>sd"=2C anywhere<br>>=3B >=3B on the command line. <br>>=3B >=3B =
> Ok=2C "c" is actually up to you. Since nobody messes with ABI much=2C<br>&=
>gt=3B >=3B gcc/amd64 works for the same<br>>=3B >=3B for Linux=2C=
> FreeBSD=2C OpenBSD=2C NetBSD=2C and Dragonfly.<br>>=3B <br>>=3B I assu=
>me you mean after the system understands this target. There will<br>>=3B=
> be a lot of files with __FreeBSD__ that need to be changed to<br>>=3B __=
>FreeBSD__ || __DragonFly__ as well. In any case=2C I'll have to<br>>=3B =
>regenerate a bunch of patches from my current work.<br>>=3B <br>>=3B <b=
>r>>=3B >=3B If this works=2C it will give you=2C roughly amd64_dragon=
>flybsd*.tar.gz <br>>=3B >=3B Copy that to your Dragonfly system=2C ex=
>tract it=2C cd into it=2C make. <br>>=3B >=3B If that works=2C you ha=
>ve a native cm3. <br>>=3B >=3B Run it. It should say "can't find cm3.=
>cfg". <br>>=3B >=3B Now on Dragonfly=2C mkdir -p /usr/local/cm3/bin =
><br>>=3B >=3B cp cm3 /usr/local/cm3/bin <br>>=3B >=3B export P=
>ATH=3D/usr/local/cm3/bin:$PATH<br>>=3B >=3B full CVS checkout <br>&g=
>t=3B >=3B cd scripts/python =3B ./boot2.sh <br>>=3B >=3B <br>>=
>=3B >=3B You will need to have made small changes to pylib.py for this =
>to work.<br>>=3B >=3B (And your config file should say to use the C b=
>ackend=2C like Darwin and<br>>=3B >=3B ARM_LINUX do.)<br>>=3B <br>>=
>=3B <br>>=3B Well=2C I'm thrilled if I don't have to patch gcc again=2C t=
>hat takes a long<br>>=3B time. Shouldn't FreeBSD use the C backend too?<=
>br>>=3B <br>>=3B John<br></div> </div></body>
></html>=
>
>--_f56ed036-02b3-494e-bb04-f7c58d07fa28_--
More information about the M3devel
mailing list