(static) building on alpine / musl

[sam0x17]

I am having some build issues with this shard when building statically on Alpine Linux and I was wondering if you have any insight.

During the postinstall build hook, I am getting:

ld: library not found for -lcrt0.o (this usually means you need to install the development package for libcrt0.o)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: execution of command failed with code: 1: `cc "${@}" -o '/Users/sam/workspace/blockvue-api/server'  -rdynamic -static  -lxml2 /usr/local/lib/libgmp.a -L/Users/sam/workspace/blockvue-api/lib/duktape/src/.build/lib -L/Users/sam/workspace/blockvue-api/lib/duktape/src/.build/include -lduktape -lm `command -v pkg-config > /dev/null && pkg-config --libs --silence-errors libssl || printf %s '-lssl -lcrypto'` `command -v pkg-config > /dev/null && pkg-config --libs --silence-errors libcrypto || printf %s '-lcrypto'` -lz /usr/local/lib/libpcre.a /usr/local/Cellar/crystal/0.31.0_1/embedded/lib/libgc.a -lpthread /usr/local/Cellar/crystal/0.31.0_1/src/ext/libcrystal.a /usr/local/lib/libevent.a -liconv -ldl -L/usr/local/Cellar/crystal/0.31.0_1/embedded/lib -L/usr/lib -L/usr/local/lib`

For the life of me I can't find any packages on Alpine that provide libcrt0.o, but some old Duktape github issues indicate compilation on musl is possible.

Do I maybe need to make a modification to the makefile?

[jessedoyle]

Hi @sam0x17.

I don't use Alpine Linux regularly, but I was able to build an example crystal project with duktape.cr on the alpine:latest docker image.

I had to install the following packages after entering a shell on the container:

apk add crystal shards
apk add make            # duktape.cr uses a makefile for automation
apk add build-base      # GCC, c stdlib

I was able to build the following crystal example:

# test.cr
require "duktape/runtime"

rt = Duktape::Runtime.new

pp rt.eval("1 + 1")

Building:

shards install
crystal build test.cr --release --static
./test # 2.0

I'm not able to replicate the exact issue that you're encountering. Are you building in a docker container? If so, what's your base image?

[sam0x17]

Thanks for taking the time to look at this -- I'm building using durosoft/crystal-alpine:0.30.1 which is based on this dockerfile (but was tagged when crystal was at 0.30.1 on edge:

https://github.com/sam0x17/crystal-alpine/blob/29abfda1e670f09d14a16c4425c553192ce07c91/Dockerfile

I have other unrelated compilation issues with 0.31.1 which is why I'm using 0.30.1, which doesn't have those issues.

[jessedoyle]

@sam0x17 - I'm not certain on the error, but I have a few thoughts.

• If you're compiling statically in a docker container, are you executing a shards install inside the container first?

  duktape.cr will generate an object file for the current architecture during the shards postinstall phase. If the shard install (and post install phase) occurs on the host machine and the object files are mounted as a volume on the docker container, the object files generated will likely not match the container architecture.

  If you want to force a recompilation of the native code, you can always call:

  make -C lib/duktape cleanlib libduktape

  from the app directory in your running container.

• The error output you posted above looks like the crystal compiler is executing on a OS X based system (the /Users/{username}/... directory structure as well as references to the/usr/local/Cellar paths from Homebrew seem to indicate that).

  Creating a fully statically linked binary is not supported on OS X - please see the documentation here: https://developer.apple.com/library/archive/qa/qa1118/_index.html

  I use OS X as my day-to-day dev machine and I get the same libcrt0.o linking error if I try to compile any crystal program with the --static flag.

I hope this helps!

[sam0x17]

Thanks for the advice. I was finally able to get it working (5 minutes ago) by doing the latter you suggested and running the make command manually. There seems to be some sort of bug with shards and my particular build where after the “Fetching” section, it will hang forever and use 100% CPU and allocate large memory blocks, only when run in the alpine docker image. To get around this, I manually call the post install of each shard (including duktape) and that seems to get around the issue.

The libcrt0 thing happens, like you said, if you forget to run shards install or shards build at all. I figured that out earlier today and have been dealing with this latter issue for the rest of the day.

Thanks again for your help!

On Oct 2, 2019, at 11:03 PM, Jesse Doyle notifications@github.com wrote:

@sam0x17 https://github.com/sam0x17 - I'm not certain on the error, but I have a few thoughts.

If you're compiling statically in a docker container, are you executing a shards install inside the container first?

duktape.cr will generate an object file for the current architecture during the shards postinstall phase. If the shard install (and post install phase) occurs on the host machine and the object files are mounted as a volume on the docker container, the object files generated will likely not match the container architecture.

If you want to force a recompilation of the native code, you can always call:

make -C lib/duktape cleanlib libduktape from the app directory in your running container.

The error output you posted above looks like the crystal compiler is executing on a OS X based system (the Users/{username}/... directory structure as well as references to the/usr/local/Cellar paths from Homebrew seem to indicate that).

Creating a fully statically linked linked binary is not supported on OS X - please see the documentation here: https://developer.apple.com/library/archive/qa/qa1118/_index.html https://developer.apple.com/library/archive/qa/qa1118/_index.html I use OS X as my day-to-day dev machine and I get the same libcrt0.o linking error if I try to compile any crystal program with the -static flag.

I hope this helps!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jessedoyle/duktape.cr/issues/54?email_source=notifications&email_token=AAOE4LNO37WK6ULXY5AF7ULQMVOJNA5CNFSM4I4XAULKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAG2HTQ#issuecomment-537764814, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOE4LJPOGKOOFV4OH6LWYDQMVOJNANCNFSM4I4XAULA.

[jessedoyle]

@sam0x17 - Great - glad to hear you got it figured out!