<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I understand your reluctance.<br><br><br>> Is the goal just to get FreeBSD to have a binary with the latest<br>> sources?<br><br><br>Yes, and to make sure the build process works for you.<br><br><br>> Shouldn't FreeBSD use the C backend too?<br><br><br>Every target should. I haven't convinced everyone yet.<br>There is less resistance for new targets, like AMD64_NT and ARM_LINUX, which are working, using the C backend.<br>There are downsides to the C backend:<br> - it is slower to compiler <br> - debugging is degraded on systems that have m3gdb <br> (debugging is much better on systems w/o m3gdb) <br><br><br>And there are advantages not yet implemented, in particular, efficient exception handling by generating C++.<br><br><br>> > gcc/amd64 works for the same<br>> > for Linux, FreeBSD, OpenBSD, NetBSD, and Dragonfly.<br>> <br>> I assume you mean after the system understands this target. There will<br>> be a lot of files with __FreeBSD__ that need to be changed to<br>> __FreeBSD__ || __DragonFly__ as well. In any case, I'll have to<br>> 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, vs. you want to commit them yourselves.<br>I already skimmed them and they all look easy.<br>DragonflyBSD is basically FreeBSD by another name.<br>Yes, a ton of work has been done on the kernel, file systems, maybe ports.<br>But the ABI is almost the same -- heck, for the most part, Linux==NetBSD==FreeBSD==OpenBSD.<br>Sure, they might be implemented differently, but they are highly source compatible and every highly object code compatible.<br><br><br>> I must be misunderstanding what you mean by "upgrade". It's the<br>> cross-compiler that's complaining, and it was built by the latest patches.<br><br>Agreed, we are both missing something simple.<br>Usually this is the error you get when you don't upgrade Target.i3/Target.m3.<br>If you want to press on with the current approach and ignore my advise, it should be possible to step through all this.<br>To start, break on Target__Init and see if it returns true or false.<br><br><br>> statically while a bug in the cm3 sources caused those libraries to link<br>> dynamically (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 gmp/mpfr/mpc in current source.<br>They are used for actually very little and aren't worth it.<br><br><br> - Jay<br><br><br><div>> Date: Sun, 19 Jan 2014 13:38:32 +0100<br>> From: adacore@marino.st<br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)<br>> <br>> On 1/19/2014 13:17, Jay K wrote:<br>> > Hey..I like that that does capture some of My Way. <br>> > Here is my independent off the cuff write up though:<br>> > I know the ports system is nice.<br>> > I know we really need to be in it for many operating systems.<br>> > I suspect your problem is that you didn't "upgrade" to apply you<br>> > changes at the right time.<br>> <br>> I must be misunderstanding what you mean by "upgrade". It's the<br>> cross-compiler that's complaining, and it was built by the latest patches.<br>> <br>> <br>> > Do any of these work for you:<br>> > https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html<br>> <br>> I'm not clear to which set you are referring.<br>> There's no need for a binary set, modula3 now builds on FreeBSD 9 and<br>> FreeBSD 10 (http://www.freshports.org/lang/modula3), which is also<br>> superior to the release binaries because they link gmp and mpfr<br>> statically while a bug in the cm3 sources caused those libraries to link<br>> dynamically (which is why release binaries don't run on current FreeBSD)<br>> <br>> Then there are the source distributions, but they are from 2012 so they<br>> aren't exactly fresh either.<br>> <br>> <br>> > Anyway, please try this: <br>> > Ignore DragonFly at first. <br>> > Go to a system with a working cm3. Such as FreeBSD. Linux. Almost<br>> > anything. <br>> > Such as from ports. <br>> > Make a backup, e.g. of /usr/local/cm3. <br>> > My instructions are unfortunately destructive of the existing install. <br>> > Checkout the full current CVS repository. <br>> > In that repository, run scripts/python/upgrade.py. <br>> > If that doesn't work, stop, and we'll help. <br>> <br>> Is the goal just to get FreeBSD to have a binary with the latest<br>> sources? If so, I'd just modify the port to do that now that we have<br>> working binary bootstraps. The main reason I'm reluctant is that it<br>> took over a week to make the cm3 port, I've never had so much difficulty<br>> before. (I've also spent another week on the DragonFly port). So I'm<br>> "resisting" because of how much work it already took. That's why I was<br>> trying to port DragonFly, THEN update to latest rather than update to<br>> latest and then port DragonFly. (in other words, going forward seems a<br>> short path than backtracking)<br>> <br>> <br>> <br>> > If that does work, apply your diffs. And upgrade.py again. You can say<br>> > "upgrade.py skipgcc" here. <br>> > Then boot1.py c amd64_dragonflybsd <br>> > Make sure you say "c" and the target "amd64_dragonflybsd", anywhere<br>> > on the command line. <br>> > Ok, "c" is actually up to you. Since nobody messes with ABI much,<br>> > gcc/amd64 works for the same<br>> > for Linux, FreeBSD, OpenBSD, NetBSD, and Dragonfly.<br>> <br>> I assume you mean after the system understands this target. There will<br>> be a lot of files with __FreeBSD__ that need to be changed to<br>> __FreeBSD__ || __DragonFly__ as well. In any case, I'll have to<br>> regenerate a bunch of patches from my current work.<br>> <br>> <br>> > If this works, it will give you, roughly amd64_dragonflybsd*.tar.gz <br>> > Copy that to your Dragonfly system, extract it, cd into it, make. <br>> > If that works, you have a native cm3. <br>> > Run it. It should say "can't find cm3.cfg". <br>> > Now on Dragonfly, mkdir -p /usr/local/cm3/bin <br>> > cp cm3 /usr/local/cm3/bin <br>> > export PATH=/usr/local/cm3/bin:$PATH<br>> > full CVS checkout <br>> > cd scripts/python ; ./boot2.sh <br>> > <br>> > You will need to have made small changes to pylib.py for this to work.<br>> > (And your config file should say to use the C backend, like Darwin and<br>> > ARM_LINUX do.)<br>> <br>> <br>> Well, I'm thrilled if I don't have to patch gcc again, that takes a long<br>> time. Shouldn't FreeBSD use the C backend too?<br>> <br>> John<br></div> </div></body>
</html>