0

I've followed this tutorial which shows how you can enable the GCC compiler on ChromeOS, which uses the following commands below.

sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 2
sudo mount -i -o remount,exec /home/chronos/user/
export C_INCLUDE_PATH=~/Toolchain/usr/include/
export LD_LIBRARY_PATH=~/Toolchain/usr/lib:~/Toolchain/usr/lib/binutils/armv7a-hardfloat-linux-gnueabi/2.25.1/
export PATH=$PATH:~/Toolchain/usr/armv7a-hardfloat-linux-gnueabi/gcc-bin/4.9.3/:~/Toolchain/usr/armv7a-hardfloat-linux-gnueabi/binutils-bin/2.25.1/
sudo sed -i 's/\/usr/\/home\/chronos\/user\/Toolchain\/usr/g' ~/Toolchain/usr/lib/libc.so

Once executed, I'm able to compile source files right up until my shell instance terminates. Once I return to the shell later, all attempts at source compilation via ./configure fail.

I suspected that the exported variables become lost after the instance is terminated. I try implementing the same commands exactly as before, but the ability to compile seems irrevocably lost.

The config.log stream presents the following error:

configure:3378: checking whether the C compiler works
configure:3400: gcc    conftest.c  >&5
/home/chronos/user/Toolchain/usr/armv7a-hardfloat-linux-gnueabi/binutils-bin/2.25.1/ld: cannot find /home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/usr/lib/libc_nonshared.a
collect2: error: ld returned 1 exit status
configure:3404: $? = 1
configure:3442: result: no

Something really peculiar happens to the path...

cannot find /home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/home/chronos/user/Toolchain/usr/lib/libc_nonshared.a

I feel that I've exhausted my limited knowledge of Linux to resolve this issue. Is anyone able to provide some insight as to what's going on?

  • I think, maybe I shouldn't keep replicating that sed command. It's the only instruction I don't get... Do I keep appending to the target path when I keep running it? I don't understand what the target is either. If I could figure it out, maybe it could be reset... – Mapsy Oct 18 '16 at 13:17
1

The problem is that when you repeatedly use sed in this way, you keep appending to the shared object file ~/Toolchain/usr/lib/libc.so. So after the first run, this corrupts the file path.

If your path is corrupted, navigate to the file and manually change the contents of libc.so to the following:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-littlearm)

GROUP ( /lib/libc.so.6 /home/chronos/user/Toolchain/usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux-armhf.so.3 ) )

Trouble is, when the shell has been closed, it's important that if you wish to keep compiling once you do return, you must re-run the export flags since these do get lost. You need to do this until you seek a more permanent solution which establishes the flags upon initialization of the shell, i.e. via ~/.bashrc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.