[M3devel] Stuck on adding new cm3 target (AMD64_DRAGONFLY)
adacore at marino.st
Sun Jan 19 13:38:32 CET 2014
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:
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
> 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?
More information about the M3devel