error unpacking newlib-1.19.0: not in gzip format #45

Closed
sventunus opened this Issue Jan 10, 2013 · 6 comments

Projects

None yet

2 participants

@sventunus

Hi!

I cloned the toolchain today and am getting an error while the script tries to unpack newlib-1.19.0, saying it's not in gzip format.

Steps taken:
git clone git://github.com/esden/summon-arm-toolchain
cd summon-arm-toolchain
git checkout remotes/origin/dev
./summon-arm-toolchain PREFIX=/usr/local/summon-arm-toolchain SUDO=sudo OOCD_EN=0 LIBSTM32_EN=1

(...)
gcc-linaro-4.6-2011.10/libiberty/lrealpath.c
gcc-linaro-4.6-2011.10/libiberty/memcpy.c


  • Unpacking newlib-1.19.0
    archive type gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Running Linux Mint 14 Cinnamon, kernel 3.5.0-17-generic

@esden
Owner
esden commented Jan 10, 2013

Thanks for sending this in. The dev branch is currently obsolete. Please try again with the master branch.

@sventunus

Thank you for your response esden.
I tried the master branch issuing git checkout remotes/origin/master. Now make install fails for libgcc.

Trace:
(...)
chmod 644 /usr/local/summon-arm-toolchain/lib/gcc/arm-none-eabi/4.7.3/thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16/libgcov.a
/usr/local/summon-arm-toolchain/arm-none-eabi/bin/ranlib /usr/local/summon-arm-toolchain/lib/gcc/arm-none-eabi/4.7.3/thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16/libgcov.a
parts="crtbegin.o crtend.o crti.o crtn.o";
for file in $parts; do
rm -f /usr/local/summon-arm-toolchain/lib/gcc/arm-none-eabi/4.7.3/thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16/$file;
/usr/bin/install -c -m 644 $file /usr/local/summon-arm-toolchain/lib/gcc/arm-none-eabi/4.7.3/thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16/;
case $file in
.a)
/usr/local/summon-arm-toolchain/arm-none-eabi/bin/ranlib ../../../../../.././gcc/thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16/$file ;;
esac;
done
make[4]: Leaving directory /home/sven/Documents/work/arm/cortex-m4/summon-arm-toolchain/build/arm-none-eabi/thumb/cortex-m4/float-abi-hard/fpuv4-sp-d16/libgcc' make[3]: Leaving directory/home/sven/Documents/work/arm/cortex-m4/summon-arm-toolchain/build/arm-none-eabi/libgcc'
make[2]: Leaving directory /home/sven/Documents/work/arm/cortex-m4/summon-arm-toolchain/build/arm-none-eabi/libgcc' make[1]: Leaving directory/home/sven/Documents/work/arm/cortex-m4/summon-arm-toolchain/build'
make: *
* [install] Error 2

@esden
Owner
esden commented Jan 11, 2013

That is a strange error because I don't see the actual line that states what the error was. I think I had something similar and it was gone when I rerun the compile. You could also go into the build directory after the error and run make in there. Then you should be able to see the source of the error itself.

@sventunus

Yes, it is strange indeed.
I just re-ran the script, and now it has passed where it failed before, but I get a new error on libcmsis.

Trace:
(...)
libcmsis-379ad8eb38feb6703f2f5f2e457742b7e09e3b2c/include/cmsis/system_stm32.h
libcmsis-379ad8eb38feb6703f2f5f2e457742b7e09e3b2c/include/cmsis/core_cm3.h
libcmsis-379ad8eb38feb6703f2f5f2e457742b7e09e3b2c/include/cmsis/stm32.h


  • Building libcmsis-379ad8eb38feb6703f2f5f2e457742b7e09e3b2c
    make -C src all
    make[1]: Entering directory /home/sven/Documents/work/arm/cortex-m4/summon-arm-toolchain/libcmsis-379ad8eb38feb6703f2f5f2e457742b7e09e3b2c/src' arm-none-eabi-gcc -I../include -Wall -ansi -std=c99 -fno-common -Os -g -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -c -o core_cm3.o core_cm3.c /tmp/cc8O4ejE.s: Assembler messages: /tmp/cc8O4ejE.s:452: Error: registers may not be the same --strexb r0,r0,[r1]'
    /tmp/cc8O4ejE.s:477: Error: registers may not be the same -- strexh r0,r0,[r1]' make[1]: *** [core_cm3.o] Error 1 make[1]: Leaving directory/home/sven/Documents/work/arm/cortex-m4/summon-arm-toolchain/libcmsis-379ad8eb38feb6703f2f5f2e457742b7e09e3b2c/src'
    make: *** [all] Error 2

Any ideas? Re-running for a third time doesn't seem to fix this one.

@sventunus

Seems to be a known bug that has been patched 11 months ago. Please have a look at texane/stlink#65. Maybe you can pull in the patch?

@esden
Owner
esden commented Jan 22, 2013

The previous bug with having to rerun the script is something I can observe here too. Where linaro gcc fails to compile on the first try. Not sure how to solve it yet.

I added the patch you pointed out to libcmsis. Still I would encourage you to use libopencm3 instead of the st libraries in the future. :)

@esden esden closed this Jan 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment