[M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)

Sun Jan 19 13:50:27 CET 2014

I understand your reluctance.

> Is the goal just to get FreeBSD to have a binary with the latest
> sources?

Yes, 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, like AMD64_NT and ARM_LINUX, which are working, using the C backend.
There are downsides to the C backend:
  - it is slower to compiler  
  - debugging is degraded on systems that have m3gdb  
 (debugging is much better on systems w/o m3gdb) 

And there are advantages not yet implemented, in particular, efficient exception handling by generating C++.

> > gcc/amd64 works for the same
> >     for Linux, FreeBSD, OpenBSD, NetBSD, and Dragonfly.
> 
> 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, 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 on if you are ok with my stealing your credit, vs. you want to commit them yourselves.
I already skimmed them and they all look easy.
DragonflyBSD is basically FreeBSD by another name.
Yes, a ton of work has been done on the kernel, file systems, maybe ports.
But the ABI is almost the same -- heck, for the most part, Linux==NetBSD==FreeBSD==OpenBSD.
Sure, they might be implemented differently, 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, and it was built by the latest patches.

Agreed, we are both missing something simple.
Usually this is the error you get when you don't upgrade Target.i3/Target.m3.
If you want to press on with the current approach and ignore my advise, it should be possible to step through all this.
To start, 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 source.
They are used for actually very little and aren't worth it.

 - Jay

> Date: Sun, 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)
> 
> On 1/19/2014 13:17, Jay K wrote:
> > Hey..I like that that does capture some of My Way. 
> > 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.
> 
> I must be misunderstanding what you mean by "upgrade".  It's the
> cross-compiler that's complaining, and it was built by the latest patches.
> 
> 
> >  Do any of these work for you:
> >  https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html
> 
> I'm not clear to which set you are referring.
> There's no need for a binary set, modula3 now builds on FreeBSD 9 and
> FreeBSD 10 (http://www.freshports.org/lang/modula3), 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)
> 
> Then there are the source distributions, but they are from 2012 so they
> aren't exactly fresh either.
> 
> 
> >  Anyway, please try this: 
> >   Ignore DragonFly at first. 
> >   Go to a system with a working cm3. Such as FreeBSD. Linux. Almost
> > anything. 
> >   Such as from ports. 
> >   Make a backup, e.g. of /usr/local/cm3. 
> >   My instructions are unfortunately destructive of the existing install. 
> >   Checkout the full current CVS repository. 
> >   In that repository, run scripts/python/upgrade.py. 
> >   If that doesn't work, stop, and we'll help. 
> 
> Is the goal just to get FreeBSD to have a binary with the latest
> sources?  If so, 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, I've never had so much difficulty
> 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, THEN update to latest rather than update to
> latest and then port DragonFly.  (in other words, going forward seems a
> short path than backtracking)
> 
> 
> 
> >   If that does work, apply your diffs. And upgrade.py again. You can say
> > "upgrade.py skipgcc" here. 
> >   Then boot1.py c amd64_dragonflybsd   
> >     Make sure you say "c" and the target "amd64_dragonflybsd", anywhere
> > on the command line. 
> >     Ok, "c" is actually up to you. Since nobody messes with ABI much,
> > gcc/amd64 works for the same
> >     for Linux, FreeBSD, OpenBSD, NetBSD, and Dragonfly.
> 
> 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, I'll have to
> regenerate a bunch of patches from my current work.
> 
> 
> >   If this works, it will give you, roughly amd64_dragonflybsd*.tar.gz 
> >   Copy that to your Dragonfly system, extract it, cd into it, make. 
> >   If that works, you have a native cm3. 
> >   Run it. It should say "can't find cm3.cfg".  
> >   Now on Dragonfly, mkdir -p /usr/local/cm3/bin 
> >   cp cm3 /usr/local/cm3/bin  
> >   export PATH=/usr/local/cm3/bin:$PATH
> >   full CVS checkout  
> >   cd scripts/python ; ./boot2.sh 
> >    
> >   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, like Darwin and
> > ARM_LINUX do.)
> 
> 
> Well, I'm thrilled if I don't have to patch gcc again, that takes a long
> time.  Shouldn't FreeBSD use the C backend too?
> 
> John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140119/ce74cb6a/attachment-0002.html>