You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GHC version obtained via ghcup seems to be build without the _GNU_SOURCE compiler macro.
This causes it to default to lazy symbol loading .
This in turn hides compilation errors because missing symbols will only show up when they are actually called.
hsthrift compilation fails under nixos because it is compiling GHC with _GNU_SOURCE and in turn does not default to lazy loading of symbols, this causes "undefined symbol" errors during compilation.
To reproduce this run:
export LD_BIND_NOW=1
cabal test fb-util:string-quasi
This will correctly fail with the following error:
Configuring test suite 'string-quasi' for fb-util-0.1.0.0..
Preprocessing test suite 'string-quasi' for fb-util-0.1.0.0..
Building test suite 'string-quasi' for fb-util-0.1.0.0..
[1 of 2] Compiling SpecRunner ( tests/github/SpecRunner.hs, /root/git/hsthrift/dist-newstyle/build/x86_64-linux/ghc-8.4.4/fb-util-0.1.0.0/t/string-quasi/build/string-quasi/string-quasi-tmp/SpecRunner.o )
[2 of 2] Compiling StringQuasiTest ( tests/StringQuasiTest.hs, /root/git/hsthrift/dist-newstyle/build/x86_64-linux/ghc-8.4.4/fb-util-0.1.0.0/t/string-quasi/build/string-quasi/string-quasi-tmp/StringQuasiTest.o )
<command line>: can't load .so/.DLL for: /root/git/hsthrift/dist-newstyle/build/x86_64-linux/ghc-8.4.4/fb-util-0.1.0.0/build/libHSfb-util-0.1.0.0-inplace-ghc8.4.4.so (/root/git/hsthrift/dist-newstyle/build/x86_64-linux/ghc-8.4.4/fb-util-0.1.0.0/build/libHSfb-util-0.1.0.0-inplace-ghc8.4.4.so: undefined symbol: alignedAlloc)
PR #89
Already addresses this particular compilation issue but I think it would be prudent to disable lazy loading in the CI to catch these errors in the future.
The text was updated successfully, but these errors were encountered:
Issue facebookincubator#88 and facebookincubator#90 describe that depending on system GHC can lazily link
all symbols or strictly link them at link time. To ensure we
consistently test that all the symbols in the binary are available, we
need to set LD_BIND_NOW to a non empty string. This will force ld to resolv
all symbols (see https://man7.org/linux/man-pages/man8/ld.so.8.html) at
link time.
Summary:
The following PR addresses various build issues that occur when GHC does load symbols strictly at build times. exi's did an investigation in #90. GHC on NixOS is compiled with _GNU_SOURCE leading to dlsym using RTLD_DEFAULT, causing strict loading. For hsthrift his means various symbols cannot be found at compile time and error out.
With the following stack I am able to build hsthrift and Glean NixOS. However I have **not** tested it on any other platform just yet (Notable the docker image).
I want to highlight commit 83ed60e, since it moves Utils/Executor.cpp to cpp/Executor.cpp and I am not sure if that's okay.
The rest of the PR should be straight forward.
This is branch includes PR #89 and should cleanly rebase if needed.
Pull Request resolved: #91
Reviewed By: pepeiborra
Differential Revision: D37779175
Pulled By: dsp
fbshipit-source-id: ddd593f77b7c99eb037c9e469bf2a5c62c76fe98
The GHC version obtained via ghcup seems to be build without the _GNU_SOURCE compiler macro.
This causes it to default to lazy symbol loading .
This in turn hides compilation errors because missing symbols will only show up when they are actually called.
hsthrift compilation fails under nixos because it is compiling GHC with _GNU_SOURCE and in turn does not default to lazy loading of symbols, this causes "undefined symbol" errors during compilation.
To reproduce this run:
This will correctly fail with the following error:
PR #89
Already addresses this particular compilation issue but I think it would be prudent to disable lazy loading in the CI to catch these errors in the future.
The text was updated successfully, but these errors were encountered: