Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run hsthrift CI with LD_BIND_NOW=1 environment variable #90

Open
exi opened this issue Jul 9, 2022 · 0 comments
Open

Run hsthrift CI with LD_BIND_NOW=1 environment variable #90

exi opened this issue Jul 9, 2022 · 0 comments

Comments

@exi
Copy link

exi commented Jul 9, 2022

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.

dsp added a commit to dsp/hsthrift that referenced this issue Jul 12, 2022
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.
facebook-github-bot pushed a commit that referenced this issue Jul 12, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant