User:Kentnl/m68k-qemu

= TL;DR = Nope, its all fucked, I give up, you can't step-ladder stages, they're fucked.

= Long Form =

Build QEmu to support this mess
You'll need:


 * "static-user" is important, because you need to copy the binary into your chroot later, and expect it to work.
 * "-tci" is important, as for whatever reason, everything even slightly complicated (perl, python, all of portage) segfault in its code.

Embedded_Handbook/General/Compiling_with_qemu_user_chroot

Set up the kernel to dispatch m68k binaries to qemu user
This mostly involves:


 * Having a kernel with binfmt_misc support
 * making sure the /proc fs for binfmt_misc is mounted
 * making sure the right glue entries are present

Some of which can be mostly done with:

Embedded_Handbook/General/Compiling_with_qemu_user_chroot

Build your chroot

 * wget a stage image:
 * untar it somewhere ( $CHROOT )
 * cp /usr/bin/qemu-m68k $CHROOT/usr/bin/

Drop into Chroot
And that should mostly be enough to get chrooting to work:

Now, obviously this is not adequate for real work, you'll probably need some bind-mounts or whatever, the standard fare for doing chroots, covered by most install guides, if you want "/proc" to exist, for instance.

But its enough to prove you can start doing m68k-ish stuff.

Bootstrapping
Getting things up-to-date is hell, because the stage is dated 2013, and well, that means its portage is pre-EAPI(whatever), and you can't even install the latest portage with it.

I suggest cracking open sync/gentoo.git and rewinding to 3474fda92548e6c24979ba08ffd77e8106a9d591 (October 2016)

Make sure to  and pick a valid one, or bootstrap can't work.

This seems to be old enough that portage-2013 finds a legal depgraph, and the tarballs aren't all gone poof into the dark bits.

SSL
Often, you'll get situations where distfiles exist, ... but simply cant be fetched, due to SSL legacy issues.

Fortunately, you can still fetch these manually in the host with a more recent wget or whatever, and dodge that bullet.

mmap stack: Cannot allocate memory
Yeah, don't set  with a   value. It doesn't play nice with the whole "you can only use 4G Virtual Address space on 32bit" and "make calls vfork" and "vfork has to be done in qemu, duplicating the address space somewhere at some point while also trying to share it", and things like  will poo the sheets trying to call "as" with a bunch of things, and you will be sad.

In fact, you should explicitly set, as somewhere after upgrading something, something will "autodetect" a default and you'll find   kicks in your build environment. https://github.com/gentoo/portage/commit/5a1e6c9710becab384b684ad6ba55e025d63a60e

If avoiding MAKEOPTS is not sufficient, also set  and cross your appendages. Worked for me!?

More out of memory errors 8 hours into a gcc compile
You're kinda screwed here, haven't worked out how to avoid this, other than crossing your fingers and start over with emerge.

It might help to quit the chroot, reap all qemu- process manually, then re-enter the chroot.

But ...

Alternatively, try USE="-fortran -openmp" for gcc, which will mean portage won't try to reinstall it at all after getting past bootstrap, as bootstrap seems to toggle that.

udev: hidden symbol `__stop_BUS_ERROR_MAP' isn't defined
Its fucked and I can't unfuck it.

I gave up and just started --exclude sys-fs/udev --exclude sys-fs/static-dev

You need both exclusions as static-dev is the fallback for when you don't have udev, but like, I'm bind-mounting udev, so ....

Fallback to busybox mdev? Idk.

Bash segfault *** Error in `/bin/bash': free: invalid pointer: 0x3ff97000 ***
Yeesus.

For some weird reason, bash using '[' instead of '[[' makes it panic. God only wut.

I hand edited /etc/profile and replaced '[ ]' with ' ' and the panics go away. WHY.

Bootstrap

 * Mirror distfiles from https://dev.gentoo.org/~kentnl/emergency-distfiles/m68k/2016/
 * Use sync/gentoo.git @ 3474fda92548e6c24979ba08ffd77e8106a9d591
 * Use profile default/linux/m68k/13.0

Most of the distfiles are retrievable automatically, but some I had to ask for help for copies (++NeddySeagoon) and dig up some sources from google (++vapier, ++ whoevers responsible for https://www.jabawok.net/gentoo/distfiles/procps-3.3.11-remove_Unix98_output_limits.patch )

This is suitable for a full bootstrap.sh run :)

@system

 * make sure to use gcc-config to select a valid profile when done ( m68k-unknown-linux-gnu-5.4.0 )
 * make sure to use `eselect python` to set valid python's

Then feel free to

You don't need them under chroot anyway, so its cool.

And I recommend:

First, because you're gonna want to know what you're missing.

Also, to save yourself a waste of time:

Then:

@world
First deploy a few hacks for keywords and USE flags

Make sure you didn't miss any distfiles

And when that all checks out

When all is done, congrats!, you just leaped forward 3 years and have a semi-recentish openssl.

Yikes, and that's not including the 5 failed gcc's and udev's I had to go through.

depclean / cleanup
Yes, removing udev is fine here. We're still chroot, yain't gonna need it.

You also probably want to ensure your portage is setup now as per recent portages with "repos.conf"

Here's what I'm using, I'm not ready to actually tell portage it can sync stuff itself.

Do yourself a favour though:

I don't know why these are here and its just annoying.

October 2018
(WIP)

These following instructions assume you got October 2018 working first.


 * Mirror distfiles from https://dev.gentoo.org/~kentnl/emergency-distfiles/m68k/2018/
 * Use sync/gentoo.git @ ec8a78014050edd81aad9082acf622f8c9f680b6
 * Use profile default/linux/m68k/17.0

@system
Employ this fix: Glibc_2.26_porting_notes/nsswitch.conf_in_glibc-2.26

Somewhere in the middle of this it will fuck up (probably) in automake, like:

Just ignore it, and re-run the  and it mysteriously stops being a target, and lets hope we can fix that shit later.

You'll also see similar segfaults in grep, but whatever, doesn't stop the compile.

And somewhere in binutils

Yikes 😬 I'm gonna hope reinstalling perl somewhere later unfucks this.

Anywho, I eventually get this far before I'm blocked by coreutils

Sooo lets fix this fucking perl problem eh

Yeah. K.

Later:

And nope, its all fucked, I give up, you can't step-ladder stages, they're fucked.