The bsd.cpu.mk change will only fix 32-bit native, not 64-bit -> 32bit lib build. The right fix is to backport the patch from PR239007 to gcc-8 and gcc-9. I expect one release for gcc-8 and at least one for gcc-9. I try to take care to upstream and to feed the ports tree with a intermediate patch for gcc8/9-(devel).

In PR 239007 you mentioned that you did a backport of the patch for gcc which brings secure-plt. But you also found that adding -msecure-plt to CFLAGS.gcc is doing its job. For powerpc gcc that might work, but if you build a powerpc64 gcc with multilibs, with 32-bit libgcc etc., then I doubt that this is enough. But I might be wrong.

The multilib libs of a powerpc64 gcc build will not be built with this flag.

Tested on my 7,3. Thanks Michael!

I have not tested it yet, back to 338xxx. Did you test on powerpc64? I assume you tested on your Mini, right?
If you have successfully ran some tests, ok with me.

This is the glue needed to build as a ko. If you add it to the KERNCONF file like 'device if_lan78xx # PI3b+ USB NIC' then you build it inline.

Thanks for being invited to the review.
Well, I'm looking forward to a solution. I do not care in a first priority about POWER5+, it is broken anyway, genius iflib. But I can at least test the bring-up.
A more important priority is the G5 support. I'd need one and I'm willing to help.
For POWER8/9, others have to jump in.

My 2c, the code builds and boots fine if I use the odroidc1.dts with the meson.dtsi before this revision: 324820. I try to give it a chance.

The patches look good so far, but I'd like to build a cc before I continue. Unfortunately -CURRENT is totally broken regarding PowerPC-G5. And this hunting consumed quite a lot of time. Sure, for your patch this is not needed, but _I_ need a reference if gcc bootstrap works on PowerPC.
Btw, does powerpcspe have multilib directions?

config.gcc: please put the double ;; on a new line.

Tested on both, 32-bit and 64-bit powerpc. With the below addition to the Makefile.

Looks good.

Aha, I have to choose the action :)

I tested on a dual G5 and on a quad G5, with load (gcc bootstrapping/kernel/world build). The revision was r313259. It looks stable now.
It was not possible to test on POWER5+ due to e1000 and friend commits not working on BE systems.
Thanks,
Andreas

Why did you allow to enable multilib for all archs on gcc4.9/gcc4.8? It is still a no-op for all archs beside powerpc64.

I tested on my side and it is fine so far. I'd like to have this in since I have a follow up for enable/disable java for powerpc64. And also, gcc-6.0 can not be bootstrapped with the default gcc (gcc-4.2.1). it needs at newer one which must be < 5.2. gcc-5.2 is broken when it comes to linking. I guess PIE support.

Ok with me.
I often used to build with --disable-multilib to save time. But I usually have a lib32/libc.so. So if this test works, fine.
powerpc64 is the only target in FreeBSD land which has multilib support in gcc. For all other targets the --disable-multilib is a nop.

Okey. POWER5+ is also happy. Awesome! Thanks

Cool!
Now both, UP and SMP are working. Against -CURRENT after 277468 with diff 4, ID 3258.

Ok, good. Then I did it right. I was confused why it still hangs. Thought it was my patch apply procedure. But this is ok I guess.

Nathan, hm. Do I do it right? I do 'Download Raw Diff', latest revision against base. Apply it to current and it still hangs after the second CPU got activated. uhub and iichb errors.
Current svn revision is: 277423

I'm on 277392 now and I tried to create a patch between 3241 and 3254. This is not my tool.

UP boots fine. SMP hangs on ichb and uhub attach.

The dash after freebsd, it must read arm*-*-freebsd*. Guess it's a c&p ;)

Andrew, you're right.
Nevertheless, there is a typo: s/arm*-*-freebsd-*/arm*-*-freebsd*

I suggest to do the part of libstdc++-v3/configure.host this way:

Late night comment....

Have not much to say about my stuff except two things:

• the testsuite patch is not really needed. If you want to run the testsuite a few more bits are needed which are not yet committed. I usually run the testsuite to verify my changes. If I run towards zero failures I feel ready to prepare for commit. So the patch itself has had several successful test suite runs.