This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-18
Channels
- # announcements (1)
- # aws (13)
- # beginners (55)
- # calva (8)
- # cider (73)
- # cljs-dev (96)
- # clojure (119)
- # clojure-europe (4)
- # clojure-italy (41)
- # clojure-nl (14)
- # clojure-uk (6)
- # clojurescript (90)
- # cursive (14)
- # data-science (1)
- # datomic (20)
- # dirac (1)
- # emacs (32)
- # figwheel-main (11)
- # fulcro (81)
- # hoplon (2)
- # jobs (1)
- # lein-figwheel (2)
- # luminus (1)
- # lumo (19)
- # nyc (3)
- # off-topic (60)
- # other-languages (1)
- # pedestal (5)
- # quil (1)
- # re-frame (3)
- # reagent (3)
- # reitit (5)
- # remote-jobs (1)
- # ring-swagger (2)
- # shadow-cljs (43)
- # sql (15)
- # tools-deps (20)
- # vim (21)
- # yada (6)
I was checking how to compile lumo statically and I bumped into this commit that @grav made against a lumo fork https://github.com/grav/lumo/commit/78d04752231f362b34c368be008b5240a25b7797
Has there been some talk already around adding it to lumo proper?
The problem I am trying to solve is that the latest lumo need a higher version on some dynamic libraries that the AWS lambda runtime does not support
@richiardiandrea yes, lumo has been statically compiled before
but it’s just not feasible
otherwise native modules don’t work
Oh ok that's why
they only work if you compile them against the musl version that was statically linked in
By native modules you mean util
, fs
, or npm modules that are compiled to native?
.node
modules
native “extensions” or whatever they’re called
perhaps we could add a statically compiled Lumo to the build matrix
Yeah that would be awesome because the AWS runtime use case is so attractive
right
I’m not gonna do it but feel free to send a PR
And at the moment I am using Grav's binary
Ok sounds great
it should really just be a matter of adding that flag conditionally on an env variable or something
Yep I think that should an easy one