Could crossdev help put qt on my Atom [solved]

[Fog_Watch]

Hello

Code: Select all

# grep name /proc/cpuinfo
model name	: Intel(R) Atom(TM) CPU N450   @ 1.66GHz
model name	: Intel(R) Atom(TM) CPU N450   @ 1.66GHz
# grep -i memtotal /proc/meminfo 
MemTotal:        2032500 kB

I need zoom, but this has qt dependencies and compiling them on my Atom takes, well, I don't know because after three days I gave up. Could crossdev help me compile qt?

[Hu]

It might. Do you have a system with an architecture different from your Atom, such as amd64 (assuming that Atom is an x86), arm, or ppc?

[Fog_Watch]

amd64

?
Yes

assuming that Atom is an x86

I assume so too. I don't know how to read the documentation to find out.
(cat /proc/cpuinfo | wgetpaste)

[Jaglover]

https://ark.intel.com/content/www/us/en ... 6-ghz.html

[1clue]

Atom is an x86. Most of the recent ones are x86_64.

[NeddySeagoon]

Fog_Watch,

If you have a multilib amd64 you don't need crossdev.

Set up a chroot that is a copy of the atom install but add buildpkg to its FEATURES=
Chroot in and build what you need.

On the atom, install the binary packages.

There are a few wrinkles but thats the high level overview.

If you amd64 is /no-multilib/, it can't run 32 bit code, so crossdev is a part of the solution.
Cross distcc is generally less pain than pure cross compiling.

[Hu]

amd64

?Yes

assuming that Atom is an x86

I assume so too. I don't know how to read the documentation to find out.
(cat /proc/cpuinfo | wgetpaste)

According to that output, both of those CPUs are capable of running x86_64 code. Whether you have chosen to exercise that capability (by installing an amd64 system) or not (by installing an x86 system) is not shown. For that, we would need to see uname -m or, better, emerge --info.

[Fog_Watch]

Firstly, I have to say this is a really top shelf forum. Just saying.

Forgive me: emerge --info.

I followed the wiki to install zoom and qt dependencies using binary packages. This much was quite successful. The inescapable fact is the incapacity of my atom. Zoom runs, but only just, the quality is quite terrible.

Back to the drawing board. I might have to fork out some coin.

[Hu]

Code: Select all

Portage 2.3.89 (python 3.6.10-final-0, default/linux/amd64/17.1, gcc-9.2.0, glibc-2.29-r7, 4.19.97-gentoo x86_64)
System uname: Linux-4.19.97-gentoo-x86_64-Intel-R-_Atom-TM-_CPU_N450_@_1.66GHz-with-gentoo-2.6

This Atom is running in x86_64 mode. This means crossdev is (probably) not the right solution. You probably have an amd64 install on the more powerful machine as well, in which case all you need is for the powerful machine to build binary packages (tbz2 via FEATURES=buildpkg) that use CFLAGS/CXXFLAGS that will avoid generating instructions the Atom cannot handle. If you get it wrong, the consequence will be that the program will crash with "Illegal instruction" on the Atom when it reaches the instruction it does not understand. Then you go back to the more powerful machine, fix your flags, and try again. The only risk of long term harm is if the crashed program manages to crash at such a point that it loses important state. (For example, if it deletes your settings file, starts writing a new one, and crashes before it finishes saving the new one.) If that happens, you reconstitute the state or restore it from backup. Good programs will generally write the new file first under a temporary name, then replace the old one, so that a crash does not lose the old state (but could still lose the updated state you were trying to save).

[NeddySeagoon]

Fog_Watch,

There is a small wart of the face of Hus solution.

What Hu suggests will just work if the Atom instruction set is a subset of the more powerful build box.
If the Atom has instructions that the build box cannot execute, you can build binaries on the build box but they may not execute there.

Its not a huge problem. You may need to ensure your Atom toolchain in the chroot does not get built with Atom only instructions, or you will get Illegal Instructions there.

[axl]

I see 2 possible solutions with this. Depending on cpu instruction set. Read what Neddy said.

One solution would be to just mount the atom's rootfs over nfs on the amd64 machine, and chroot within it and update like it was local. That would prolly yield the best results in my opinion. If you don't have cpu instruction on the atom side that the amd64 can't execute.

Now there are a few addendums here.

1. portage build/tmp dir. should prolly keep it on amd64.
2. repos. should prolly keep on amd64 as well.

Should also prolly check number of threads to build with... and I think that's about it.


The other solution would be through crossdev. With cross-emerge.

You would need a whole bunch of arguments, but it should work like this. First, again, mount atom's rootfs over nfs.

Then assuming you have that mounted over /mnt/atom, you would do something like this:

CHOST="x86_64-pc-linux-gnu" CBUILD="x86_64-pc-linux-gnu" ROOT=/mnt/atom/ SYSROOT=${ROOT} PKG_CONFIG_PATH="${ROOT}/usr/lib/pkgconfig/" cross-emerge whatever

CHOST is the target system.
CBUILD is the host system.
Rest should be self evident.

I use this extensively. There are packages that have issues with this, but most of them work.

Personally I use this scheme to update rootfs for arm, armv6, armv7, aarch64 and powerpc64 all from amd64.

[Fog_Watch]

Read what Neddy said.

Always.

One solution would be to just mount the atom's rootfs over nfs on the amd64 machine, and chroot within it and update like it was local.

And make sure async is in /etc/exports, otherwise tar -xf is never going to complete.