remove --fully-static for linux

[hlolli]

#163

This was as simple as this, removeing the --fully-static compiler flag for linux.

Got some clues here nodejs/node#3207
that this may not be necessary, tough I must admit I don't know what this adds.

[anmonteiro]

I have nothing against doing this, but it'll drop support for NixOS.

[hlolli]

I can try tomorrow if the last release causes this require problem on NixOS, don't know what the result of that experiment should lead us to. Maybe this can be solved differently.

[anmonteiro]

@hlolli Here's a better explanation of what's happening:

• In some recent version I switched Lumo's compilation on Linux to be fully static. This means that libc is bundled inside the binary and not dynamically linked. This makes Lumo work on NixOS because otherwise it wouldn't be able to find libc (since Nix has weird paths with hashes and stuff).
• Now you probably have a different libc on your computer than the one Lumo was linked against. So the native packages you're installing are being linked against your version which may have incompatibilities with the Lumo's binary libc.

[hlolli]

https://github.com/nodejs/node/wiki/statically-linked-executable

from here it sounds like fully-static nexe can't use the standard glibc?

[darwin]

Fully static linking on linux was requested by me in #137.

What about building and bundling two versions of lumo? And let launcher script decide which one to launch based on a command-line flag?

[hlolli]

@darwin is lumo already in nixpkgs repo? If nix needs fully-static then some nix-expression could be written to download the fully-static version of lumo (could be made as a release parallel to default non-static releases).

[darwin]

I'm sorry. I don't know anything about nix. My problem was running Lumo on old Ubuntu 14.04, which is what Travis CI offers. I believe the problem was that Lumo was compiled agains pretty recent libc, but Ubuntu had pretty old one. That caused a mismatch in symbols when Lumo linked old libc dynamically.

[darwin]

I think the fundamental problem is that Linux expects you to compile stuff or use packages compiled specifically for given OS version. One pre-compiled lumo binary shared between all different systems cannot cut it. Except being statically linked. And then you run into issues you linked.

[anmonteiro]

Right. I'm inclined to just accept this PR for now and figure out things in another issue later.

As I said before, I don't really mind dropping NixOS support, I don't know anything about Nix and I think someone should just handle that downstream in nixpkg

[darwin]

@anmonteiro Ok, go for it. My use-case is not that important.

[arichiardi]

Just curious here, can't Nixos create a sandbox with exactly the glibc version necessary to run? This looks like something a devop dev would definitely want to do (for example for Lumo compiled statically)

[anmonteiro]

I don't know about NixOS. Overall I think it's preferable to have a dynamically linked binary to avoid bugs like the one this PR fixes.