Provide fully static binaries
facchinm opened this issue · 16 comments
arduino/Arduino#3548 and other issue are frequently caused by the binaries not being fully static.
Consider providing static binaries next time the programmers will be updated
Small update:
- OSX programs can't be fully static (http://stackoverflow.com/questions/5259249/creating-static-mac-os-x-c-build)
- Linux build need to recompile glibc entirely ( 😵 ) but it is ok
- Windows build does not need to be static as it loads the dll from the executable folder
Linux script here: https://gist.github.com/facchinm/6c3feff432c62d6849fb
How it going? ARDUINO 1.6.6 is out and again - no static binaries..
I am having the same problem running the Arduino software on Gentoo:
"/home/zoobab/Downloads/arduino-1.6.7/hardware/tools/avr/bin/avrdude: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory"
I will try to compile the arduino SDK with MUSL-Libc as GLIBC is a nightmare to produce static binaries. GLIBC guys deliberately broke that feature for GPL/political reasons.
Hi @zoobab ,
the problem you are experiencing is due to a newly compiled libncurses. Symlinking libtinfo to libncurses or installing some kind of libtinfo-compat package does the trick.
However, the next version of avrdude binary will be of course static to avoid this kind of problems.
I know, I had to rebuild ncurses with tinfo support, so now at least I can upload some code to my arduino.
Will try to build a static toolchain now, will write here if I manage to build it.
No need for a static toolchain, only a static avrdude is needed.
If you want to compile using these scripts https://gist.github.com/facchinm/6c3feff432c62d6849fb and validate them it would be great!
From my Googling, static is dead.
that is why ' -static ' doesn't work, or more like ignored any more.
Not really, the "-static" is being broken on purpose by the GLIBC guys. I will check what I can do, even if it means using MUSL libc like I did for other projects where I needed a static binary.
The question is (for me as packager), if we just can use the upstream avrdude etc or if this would cause too many problems. The same goes for java. However I still suggest to use static linkage as the ready to go zipfile should not rely on any dependencies.
will be solved by https://github.com/arduino/avrdude-build-script/commits/master
@facchinm Since it is very close to the upstream avrdude, do you think in arch we just can use the upstream avrdude? Also what do you think of using a different avr-gcc? It might break a few programs possibly, but also it can make use of lto etc. I also found some libusb stuff, can we also get rid of this in the arduino build process if the host has those available?
Using non-bundled tools (in a transparent way) is a support nightmare; people should also know the tools version which is not directly obtainable by the UI.
But the linked avrdude (and all the toolchain from arduino/Arduino#5021) would solve these problem since:
- binaries are almost static (libusb stuff/additional libraries are linked statically)
- lto is enabled
- the toolchains are Atmel's official
So I'd go for the bundled ones 😄
Thanks for explaining this. That's also what I was thinking.
Is the patch in the latest master build now? I am creating an arduino-git package, so I could remove the avrdude dep.
arduino/Arduino#5021 is now merged and released