<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'>sorry, I'm delayed..so much to do..<br>I commited the networking fix..<br>The m3core/unix one I think we already have.<br><br>Later...<br> - Jay<br><br><div>> Date: Fri, 24 Jan 2014 00:42:01 +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 14:06, John Marino wrote:<br>> > On 1/19/2014 13:50, Jay K wrote:<br>> >> And there are advantages not yet implemented, in particular, efficient<br>> >> exception handling by generating C++.<br>> > <br>> > Like FreeBSD (and unlike NetBSD and OpenBSD), DragonFly has implemented<br>> > dl_iterate_phdr which gcc uses for efficient zero-cost exception<br>> > handling. That might come in handy here (I implemented it in<br>> > DragonFly's real-time linker, mainly for Ada/GNAT but C++ benefited.)<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 --<br>> >> depends on if you are ok with my stealing your credit, vs. you want to<br>> >> commit them yourselves.<br>> > <br>> > I would love it if you did this - I'm happy with a mention in the commit<br>> > message. I just attached a tarball of all the patches I'm using right<br>> > now. Some of these changes are specifically for the cross compiler (I'm<br>> > think of the /scripts changes mostly) but most are valid assuming they<br>> > still apply to the head of the repo. Please take as much as you want<br>> > with my gratitude.<br>> > <br>> >> I already skimmed them and they all look easy.<br>> >> DragonflyBSD is basically FreeBSD by another name.<br>> > <br>> > That's not an accident. As a DragonFly developer that mostly works on<br>> > userland, I've been converging FreeBSD and DragonFly again. They<br>> > drifted apart after 10 years, but I thought it better to keep the<br>> > userlands as similar as possible for 3rd party applications.<br>> > <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,<br>> >> Linux==NetBSD==FreeBSD==OpenBSD.<br>> >> Sure, they might be implemented differently, but they are highly source<br>> >> compatible and every highly object code compatible.<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>> >> Agreed, we are both missing something simple.<br>> >> Usually this is the error you get when you don't upgrade<br>> >> Target.i3/Target.m3.<br>> >> If you want to press on with the current approach and ignore my advise,<br>> > <br>> > I'm not ignoring it; it's more like I'm not quite ready to give up since<br>> > I'm so close. I think I could actually get these libs and cm3 to build<br>> > on DragonFly if I used AMD64_FREEBSD as the target with the<br>> > cm3cg-AMD_DRAGONFLY generator. It was building before. I just figured<br>> > I'd then get stuck on the DragonFly side trying to compile cm3 with<br>> > itself, theoretically I should get the same error there.<br>> > <br>> > <br>> >> Ugh. I saw something about that in your diffs. Definitely we intend to<br>> >> link statically.<br>> >> I actually went to the trouble of removing use of gmp/mpfr/mpc in<br>> >> current source.<br>> >> They are used for actually very little and aren't worth it.<br>> > <br>> <br>> Hi Jay,<br>> If you get those patches committed and publish an official snapshot<br>> (compressed tarball) with those changes in it, then I'll update the<br>> FreeBSD port to that snapshot.<br>> <br>> If new patches are required, say to convert FreeBSD to use the C<br>> backend, I'll feed those back too.<br>> <br>> Then I'll try porting DragonFly again, your way.<br>> Thanks,<br>> John<br>> <br>> <br>> <br></div> </div></body>
</html>