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

Jay K jay.krell at cornell.edu
Sun Jan 19 13:32:44 CET 2014

upgrade.sh (note the .sh) rebuilds everything
I wrote upgrade.py based on it, but missed the "everything" part.
upgrade.py only upgrades "the compiler" (and m3core, libm3..)

A better practise although inefficient is:

 upgrade.py && ./do-cm3-all.py realclean skipgcc && ./do-cm3-all.py buildship  

I didn't suggest that to you here in order to get further in the pipeline faster.

However upgrade.py w/o other rebuild could leave m3core.so too new for many programs.
But for purposes of building/cross-building just the compiler, my instructions are good.

John, I see you added cm3 to the FreeBSD ports and you clearly know what you are doing.
Nevertheless, I am a lazy snob, don't quite see what you are doing wrong, and am suggesting "just different", not clearly better.
But, to my credit, this "just different" is what I use all the time.
I have used it to cross to several systems, w/ and w/o cm3cg (w/ and w/o C backend).
It isn't fast, and it doesn't always have the best incrementality, but it does usually work.
There is redundancy. pylib.py essentially duplicates parts of the config files.

You misunderstood what I meant by "C backend" and from the ports history you will somewhat appreciate it.
The C backend, instead of having a lot to do with gcc, is a backend that generates C, and then invokes a C compiler.
The problem you had with -gstabs for example, goes away. We'll use whatever debugging format regular C/C++ use.
There is a little hope of taking the one C output and compiling it for different targets -- at least FreeBSD 8,9,10.
Currently the C is very word size dependent, endian dependent, and somewhat otherwise target-dependent.
I'd like to fix these aspects but it isn't easy by far, will take possibly controversial changes in the frontend and interface to backend.

 - Jay

From: jay.krell at cornell.edu
To: adacore at marino.st
Date: Sun, 19 Jan 2014 12:17:24 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)

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.

 Do any of these work for you: 


 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.  
  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. 
  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.)

 - Jay

> Date: Sun, 19 Jan 2014 13:09:37 +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 12:40, Jay K wrote:
> > Your change looks about right.
> >  
> > Did you first "upgrade" and existing install, with these changes, and
> > then cross?
> > That is what you must do.
> It's probably easier that I show you.
> I've attached "Makefile.local" (I added the .txt extension just now to
> help out some mail clients) which is my recipe.
> So I run three targets in a freshly patched workarea:
> 1) make cross-compiler
> 2) make assembler-code (called from cross-archive)
> 3) make cross-archive
> In the cross-compiler target, the FreeBSD bootstrap compiler builds
> m3middle, m3linker, m3front, mequake, and CM3 for the cross compiler.
> The cross-compiler then builds libm3core and libm3 with FreeBSD cm3cg
> Everything is cleaned, then the cross compiler builds everything again
> (including libm3core and libm3) along with m3objfile, sysutils, and
> patternmatching.
> Then the cm3.cfg is changed to specify HOST=freebsd, TARGET=dragonfly,
> cm3cg is cm3cg-AMD64_DRAGONFLY.
> I would not be surprised is there is a logic flaw or two in "make
> cross-compiler".  The "how to port CM3" tutorial was slightly out of
> date and some of the instructions were a bit ambiguous so this was a
> best guess.
> Regards,
> John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20140119/153439e7/attachment-0002.html>

More information about the M3devel mailing list