Skip to content

Local Static Build Not Working #2

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

Closed
krakrjak opened this issue Jul 10, 2020 · 6 comments
Closed

Local Static Build Not Working #2

krakrjak opened this issue Jul 10, 2020 · 6 comments

Comments

@krakrjak
Copy link

I'm sure this stock code will build in the Docker container used for submission, but when I attempt to stack build this repository locally I get these errors:

Building all executables for `icfpc-mmxx-starterkit-haskell' once. After a successful build of all of them, only specified executables will be rebuilt.
icfpc-mmxx-starterkit-haskell> configure (exe)
Configuring icfpc-mmxx-starterkit-haskell-0.0.0...
icfpc-mmxx-starterkit-haskell> build (exe)
Preprocessing executable 'main' for icfpc-mmxx-starterkit-haskell-0.0.0..
Building executable 'main' for icfpc-mmxx-starterkit-haskell-0.0.0..
[1 of 2] Compiling Main
[2 of 2] Compiling Paths_icfpc_mmxx_starterkit_haskell
Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.0.1.0/build/main/main ...
/home/krakrjak/.stack/snapshots/x86_64-linux-tinfo6/1f3e2ea39d44c7b8e8779a75afb917bb4c3ecf974c3607b66b7ce871d274bfa2/8.8.3/lib/x86_64-linux-ghc-8.8.3/network-3.1.1.1-H5yw1GXuMJB7JJ4oD68Cdy/libHSnetwork-3.1.1.1-H5yw1GXuMJB7JJ4oD68Cdy.a(HsNet.o):function hsnet_getaddrinfo: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan.o)(.note.stapsdt+0x70): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_tan.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32.o)(.note.stapsdt+0x5c): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32.o)(.note.stapsdt+0xa4): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32.o)(.note.stapsdt+0xf4): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan-fma.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan-fma.o)(.note.stapsdt+0x70): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_tan-fma.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma.o)(.note.stapsdt+0x5c): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma.o)(.note.stapsdt+0xa4): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma.o)(.note.stapsdt+0xf4): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan-fma4.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan-fma4.o)(.note.stapsdt+0x70): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_tan-fma4.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma4.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma4.o)(.note.stapsdt+0x5c): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma4.o)(.note.stapsdt+0xa4): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(sincos32-fma4.o)(.note.stapsdt+0xf4): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan-avx.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan-avx.o)(.note.stapsdt+0x70): error: relocation refers to local symbol "" [1], which is defined in a discarded section
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_tan-avx.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

--  While building package icfpc-mmxx-starterkit-haskell-0.0.0 using:
      /home/krakrjak/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_3.0.1.0_ghc-8.8.3 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.0.1.0 build exe:main --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

stack --version

Version 2.3.1, Git revision de2a7b694f07de7e6cf17f8c92338c16286b2878 (8103 commits) x86_64 hpack-0.33.0

gcc --version

gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ld --version

GNU ld (GNU Binutils for Ubuntu) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

Am I missing a development library? I'm running Ubuntu 20.04 (focal).

@beevee
Copy link
Member

beevee commented Jul 10, 2020

@aergus can you help with this issue?

@aergus
Copy link
Contributor

aergus commented Jul 10, 2020

This somewhat looks like this bug, but I'd need to try to reproduce the environment to analyze it further.

But maybe the best way of solving this problem would be giving up static builds. Other compiled languages like C++, C# and Java seem to be using the base image both for building and for running the code. Can't we do this for Haskell as well? (If you agree, I can make pull requests here and in the Dockerfile repository.)

@beevee
Copy link
Member

beevee commented Jul 10, 2020

Yeah, sure, we can give up static builds with the current standard for our build/run images.

@beevee
Copy link
Member

beevee commented Jul 10, 2020

@krakrjak does current version work for you?

@krakrjak
Copy link
Author

krakrjak commented Jul 10, 2020

Works for me!!!

@beevee beevee closed this as completed Jul 11, 2020
@koalaman
Copy link

koalaman commented Feb 8, 2021

(No action is required, just posting for anyone else who finds this issue while debugging this error)

My understanding of the problem is that the static libraries have new SystemTap DTrace markers embedded, which are described in sections named .note.stapsdt. These sections are not supported by gold aka ld.gold, Google's faster ld alternative.

You can instead use traditional ld aka ld.bfd, since it uses the general Binary File Descriptor libraries that correctly account for these sections. The GHC flag for this is -optl-fuse-ld=bfd

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants