Re: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL

On 11/26/2019 12:09 AM, Miroslav Lachman wrote:
> Ruslan Garipov wrote on 2019/11/25 19:26:
> 
> [...]
> 
>>> I didn't tried this with current but I am using it with stable (11.3 at
>>> this time). Building on Xeon E3-1240v3 and installing on many different
>>> machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649,
>>> some 10 years old Intel Pentium.
>>> So at least it worked in the past (11.3 amd64). Did you use this
>>> workflow in the past / did it work?
>> No, unfortunately I didn't.  Always built world/kernel on target host.
>>
>>> I remember some issue in the past which was (accidentally?) fixed by
>>> running "make buildworld && make builkernel && make installkernel &&
>>> make installworld" on the build host (to some different DESTDIR) and
>>> then "make installkernel && make installworld" on the target host (build
>>> machine is shared via NFS)
>> Therefore, this trick somehow "fixes" /usr/obj shared on the build
>> machine?  I'll try this later.  Thanks!
> 
> Yes, I think so. But I am not a developer nor I know much about how 
> build process works.
I've tried to installkernel/installworld with non-default DESTDIR, it
doesn't help for GENERIC kernel.  But...

After I had failed with that DESTDIR, I decided to update kernel/world
on the build machine to the revision I tried to deploy (r355085).  I
cleaned result of the previous build, restored make.conf and src.conf
specifying sandybridge† there as value of CPUTYPE and explicit -march,
build and install kernel and world.  Then I cleaned result of the build
again, run buildworld and buildkernel preparing to investigate the build
logs.  But before doing that, I decided to run `make installkernel` once
again on a target machine, and ... bang!  It completed successfully!
mergemaster, installworld -- the same!  Everything completed smoothly.

I updated the source to r355105 on the build machine, buildworld and
buildkernel there -- installkernel, mergemaster, installworld on a
target machine completed with no errors.

To be honest, I don't know what exactly was a reason for my previous
failure.  Because I've tried to build with sandybridge in the configs.
May be r355085 helped me, I don't know.  In any case, I should inspect
the build log, I believe.

Miroslav, thanks for support!

† This is the oldest chip we have on our ESXi hosts.