On 2017-07-20 06:33, Danny YUE <sheepd...@gmail.com> wrote:
> On 2017-07-20 06:25, R0b0t1 <r03...@gmail.com> wrote:
>> On Thu, Jul 20, 2017 at 1:20 AM, Danny YUE <sheepd...@gmail.com> wrote:
>>>
>>> On 2017-07-20 05:59, R0b0t1 <r03...@gmail.com> wrote:
>>>> On Thu, Jul 20, 2017 at 12:42 AM, Danny YUE <sheepd...@gmail.com> wrote:
>>>>> Hi guys,
>>>>>
>>>>> I am setting up cross compiling environment for my newly bought
>>>>> Raspberry Pi 3, under the guide of:
>>>>> https://wiki.gentoo.org/wiki/Raspberry_Pi
>>>>> https://wiki.gentoo.org/wiki/Raspberry_Pi/Quick_Install_Guide
>>>>>
>>>>> My original idea was to use crossdev to cross compile packages on my PC
>>>>> and install binaries on RPI.
>>>>> However I found it really nasty because it kept giving me the error
>>>>> message about "libintl: no such file or directory" during compilation of
>>>>> packages such as attr, python etc.
>>>>>
>>>>> And if some (even very few) packages fail to build on the PC, it is
>>>>> hardly possible to keep PC and RPI 'consistent'.
>>>>> (Yes, I did setup the 'make.profile' symlink to the right place.)
>>>>>
>>>>> So my question is:
>>>>> 1) If some packages are *doomed* to fail, how do you keep the
>>>>> emerge world environment consistency between PC and RPI?
>>>>> Or is my understanding of this method incorrect?
>>>>>
>>>>
>>>> Match compilation and USE flags.
>>>>
>>>>> 2) If it is not really a good idea to use crossdev, which one do you
>>>>> recommend between distcc and chroot method?
>>>>> (I googled but did not really get one answer about compilation speed.)
>>>>>
>>>>
>>>> You should be able to mix crossdev compiled packages freely with
>>>> device compiled ones. Incompatible packages will be ignored and it
>>>> will try to recompile a package with matching flags, so pay attention.
>>>> If you need to compile something on device then I suspect you want to
>>>> use distcc if at all possible.
>>>>
>>> Thanks for your reply. :-)
>>>
>>> Well, yes. But do you know how is distcc compared with chroot referring
>>> to compilation speed?
>>>
>>
>> Using qemu-user to emulate the target architecture and hosting the
>> system in a chroot is generally slower than compiling on device, if
>> that is what you are referring to. I've read of people who tested this
>> with the RPi3 and some Hardkernel devices.
>
> Oops, really?
> I have read of this point of view, too.
> But the Wiki page says that it is faster than native compilation on RPI.
>
> To be honest, I prefer to compile using crossdev...
>
> Ok then, I will try re-setup crossdev on my PC and see if everything
> compiles well. If not, I will post the error message here.
>
> Thanks.

Ok, I am back.

This time I purged cross toolchain for Raspberry Pi and started it over
again.

I ran:
$ crossdev -S -v -t armv7a-hardfloat-linux-gnueabi
$ cd /usr/aarch64-unknown-linux-gnu/etc/portage
$ rm make.profile
$ ln -s /usr/portage/profiles/default/linux/arm64/13.0/armv7a make.profile

Then I did `armv7a-hardfloat-linux-gnueabi-emerge -auDNU @world`.
Most packages succedded to build, but 'util-linux-2.30' failed and gave
following messages:

--- BEGIN ---
/usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/ld: skipping incompatible 
/usr/lib64/libncursesw.so when searching for -lncursesw
/usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/ld: skipping incompatible 
/usr/lib64/libc.so when searching for -lc
/usr/lib64/libc.a: error adding symbols: File format not recognized
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:7070: ul] Error 1
make[2]: *** Waiting for unfinished jobs....
libtool: link: armv7a-hardfloat-linux-gnueabi-gcc -fsigned-char -fno-common 
-Wall -Werror=sequence-point -Wextra -Wmissing-declarations 
-Wmissing-parameter-type -Wmissing-prototypes -Wno-missing-field-initializers 
-Wredundant-decls -Wsign-compare -Wtype-limits -Wuninitialized 
-Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-parameter 
-Wunused-result -Wunused-variable -Wnested-externs -Wpointer-arith 
-Wstrict-prototypes -Wformat-security -Wimplicit-function-declaration -O2 
-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -Wl,-O1 -o setsid 
sys-utils/setsid.o  -Wl,--as-needed
libtool: link: armv7a-hardfloat-linux-gnueabi-gcc -fsigned-char -fno-common 
-Wall -Werror=sequence-point -Wextra -Wmissing-declarations 
-Wmissing-parameter-type -Wmissing-prototypes -Wno-missing-field-initializers 
-Wredundant-decls -Wsign-compare -Wtype-limits -Wuninitialized 
-Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-parameter 
-Wunused-result -Wunused-variable -Wnested-externs -Wpointer-arith 
-Wstrict-prototypes -Wformat-security -Wimplicit-function-declaration -O2 
-march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -Wl,-O1 -o setarch 
sys-utils/setarch.o  -Wl,--as-needed
make[2]: Leaving directory 
'/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/sys-apps/util-linux-2.30/work/util-linux-2.30-.arm'
make[1]: *** [Makefile:11718: all-recursive] Error 1
make[1]: Leaving directory 
'/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/sys-apps/util-linux-2.30/work/util-linux-2.30-.arm'
make: *** [Makefile:4913: all] Error 2
--- END ---

Did I do anything wrong?

Please let me know if any further information is needed.

Thanks.

Danny

Reply via email to