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.

Sign up for GitHub

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

Jump to bottom

static linking fails on Fedora #1051

Open
blp opened this issue Aug 16, 2021 · 3 comments
Open

static linking fails on Fedora #1051

blp opened this issue Aug 16, 2021 · 3 comments
Labels
bug Something isn't working

Comments

@blp
Copy link
Contributor

blp commented Aug 16, 2021

I consistently get the following linker error on two different Fedora systems with tip of master:

/home/bpfaff/.stack/programs/x86_64-linux/ghc-tinfo6-8.8.4/lib/ghc-8.8.4/unix-2.7.2.2/libHSunix-2.7.2.2.a(Files.o):ghc_2.c:function ghczuwrapperZC1ZCunixzm2zi7zi2zi2ZCSystemziPosixziFilesZCmknod: error: undefined reference to '__xmknod'

It works OK if I delete all the lines in package.yaml of the form - -optl-static.
@ryzhyk
Copy link
Contributor

ryzhyk commented Aug 19, 2021

@blp, I know you wrote these instructions in the readme, but just to double check, do you have glibc-static and friends installed on these systems?

dnf install glibc-static gmp-static libstdc++-static

@blp
Copy link
Contributor Author

blp commented Aug 20, 2021

@blp, I know you wrote these instructions in the readme, but just to double check, do you have glibc-static and friends installed on these systems?

I do.

This is a really weird error. I can't find anyone else mentioning something similar on the Internet.

@ryzhyk ryzhyk added the bug Something isn't working label Aug 25, 2021
@rredpoppy
Copy link

same issue here. I also get some warnings: .stack/programs/x86_64-linux/ghc-tinfo6-8.8.4/lib/ghc-8.8.4/unix-2.7.2.2/libHSunix-2.7.2.2.a(User.o):ghc_2.c:function ghczuwrapperZC6ZCunixzm2zi7zi2zi2ZCSystemziPosixziUserZCgetgrgidzur: warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

ryzhyk added a commit that referenced this issue Jul 23, 2022
@ryzhyk
Dynamically link compiler executable.
7059a5a 
DDlog used to rely on static linking to reduce runtime dependencies.
Unfortunately, this no longer works well on recent Ubuntu and Fedora
releases (see #1051).  The problem appears to be in the `unix` Haskell
package, which may still load dynamic libraries (in particular glibc)
using `dlopen` when using static linking.  As far as I can tell it uses
older versions of Linux static libraries, which require some deprecated
libc symbols (specifically `__xmnod`).  This will probably get fixed
eventually, but overall static linking probably was not a good idea, so
we switch to the more standard dynamic linking method.
ryzhyk added a commit to ddlog-dev2/differential-datalog that referenced this issue Jul 23, 2022
@ryzhyk
Dynamically link compiler executable.
919fac1 
DDlog used to rely on static linking to reduce runtime dependencies.
Unfortunately, this no longer works well on recent Ubuntu and Fedora
releases (see vmware#1051).  The problem appears to be in the `unix` Haskell
package, which may still load dynamic libraries (in particular glibc)
using `dlopen` when using static linking.  As far as I can tell it uses
older versions of Linux static libraries, which require some deprecated
libc symbols (specifically `__xmnod`).  This will probably get fixed
eventually, but overall static linking probably was not a good idea, so
we switch to the more standard dynamic linking method.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@blp @rredpoppy @ryzhyk