babashka-sci-dev 2022-12-09

lispyclouds14:12:19

moving the discussion on https://github.com/babashka/babashka/pull/1445 here @thiagokokada whats the thing that breaks when those two vars are set? this just for my info 🙂

kokada14:12:53

It tried to run setup-musl script with BABASHKA_ARCH set as amd64

lispyclouds14:12:45

Right and the error GraalVM only supports building static binaries on x86_64. comes from the setup-musl?

lispyclouds14:12:09

i was thinking that var messes up the call to native-image somehow?

kokada14:12:39

> Right and the error GraalVM only supports building static binaries on x86_64. comes from the setup-musl? Yes

lispyclouds15:12:27

ahh i see it, been a while for me too 😅

kokada15:12:28

BTW, the build error is probably some flaky test

kokada15:12:36

It is not related to the bump at all

lispyclouds15:12:44

yeah we've seen it before

lispyclouds15:12:55

looks fine for me, merging it

kokada15:12:05

lispyclouds15:12:28

maybe will try a rerun on the flaky one once

borkdude15:12:30

thanks

borkdude15:12:03

From the GraalVM slack: > Yeah, so just pick an old base image and use that. This is a very old and long-standing Linux problem. It bites everyone eventually and then you learn the hacks. ~20 years ago I wrote a tool that could compile native code on newer Linux distros/glibcs whilst enabling them to run on older distros, using a variety of obscure linker/compiler features. That sort of thing never became mainstream though because Linux distros assume they're the only distributor of binaries and everything gets compiled as a unit. Closed world assumption on a bigger scale. (edited)

borkdude15:12:15

So I guess all graal projects should be mindful about it

borkdude15:12:10

Perhaps it's better to just base off debian and then install everything yourself

lispyclouds16:12:45

Still at some point we'll have the issue i guess. And on debian stable if we're updating could be quite a lot every 2 years or so

2022-12-09

Channels