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

Arch Linux: GHC's configure script fails when LDFLAGS contains pack-relative-relocs #6525

Closed
hseg opened this issue Mar 16, 2024 · 31 comments
Closed

Arch Linux: GHC's configure script fails when LDFLAGS contains pack-relative-relocs #6525

hseg opened this issue Mar 16, 2024 · 31 comments
Labels
component: arch-linux component: build resolution: upstream issue

Comments

@hseg
Copy link

hseg commented Mar 16, 2024 •
edited
Loading

General summary/comments

On a fresh system ($XDG_DATA_HOME/stack empty), a bare stack build fails to build, erroring out at Installing GHC. However, stack setup && stack build succeeds. This is counter to my understanding of stack build's intended behaviour when it fails to find an installed ghc.

Steps to reproduce

#!/bin/bash

good="$(mktemp -d)"
bad="$(mktemp -d)"

stack --stack-root "$bad"  --verbose build 2>&1 | tee stack-bad.log
stack --stack-root "$good" --verbose setup 2>&1 | tee stack-good.log
echo '>>> Stack build'                          | tee -a stack-good.log
stack --stack-root "$good" --verbose build 2>&1 | tee -a stack-good.log

Expected

stack build notices no ghc is installed, invokes stack setup, then proceeds with build with the installed ghc.

Actual

Logs attached (ignore the S-8506 error in the good log, that is due to the testing directory not containing a stack.yaml file):
stack-bad.log
stack-good.log

Stack version

stack --version
Version 2.15.3, Git revision cffdec6ea6cf4500e08c92fea044c48a6032759d x86_64 hpack-0.36.0

Method of installation

https://aur.archlinux.org/packages/stack-static, patched to install 2.15.3 binary release.

Platform

Arch Linux 6.7.9
@hseg
Copy link
Author

hseg commented Mar 16, 2024 •
edited
Loading

(This should go without saying, but this workflow used to work as late as two weeks ago with stack-static 2.15.1. At least it's good to know the workaround of explicitly calling stack setup works.)

@mpilgrem
Copy link
Member

@hseg, thanks for reporting.

On Windows 11, with Stack 2.15.3, first run of stack build outside of a project directory:

On the Ubuntu distribution of Linux (via WSL), Stack 2.15.3 does the same.

Do you get the same problem on Arch Linux with an 'official' build of Stack 2.15.3 for Linux?

@mpilgrem mpilgrem changed the title Stack build on a fresh system fails, needs stack setup first Arch Linux: stack build on a fresh system fails, needs stack setup first Mar 16, 2024
@hseg
Copy link
Author

hseg commented Mar 17, 2024 via email

@mpilgrem
Copy link
Member

By 'official', I meant the binary distributions provided via this repository - but I would include the ones provided via GHCup too. Understood on a 'fresh install' - I think I deleted enough of my Stack root to mimic that (I deleted the entire Stack root on Ubuntu).

@hseg
Copy link
Author

hseg commented Mar 17, 2024 via email

@mpilgrem
Copy link
Member

That pacman/stack-2.15.3-linux-x86_64/stack is indeed the same as the 'official' Stack 2.15.3:

$ file /home/mpilgrem/.local/bin/stack
/home/mpilgrem/.local/bin/stack: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=27d126ba061fdc227fccd6ae92feb90715899073, stripped

@hseg
Copy link
Author

hseg commented Mar 17, 2024 via email •
edited
Loading

@hseg
Copy link
Author

hseg commented Mar 17, 2024 •
edited
Loading

Github really doesn't like email responses, does it? Cleaned up previous comment, sorry for the mess in your inboxes.
The following are the files I attempted to attach to the previous comment:
makepkg.log
stack-build-envvars.log
stack-build.log

And since Github doesn't like files without filetypes:

pkgname=test-stack
pkgver=1
pkgrel=1
pkgdesc='Testing running stack in PKGBUILD'
arch=('x86_64')
url='https://github.com/commercialhaskell/stack'
license=('CC0')
makedepends=('stack')
source=()

prepare() {
    #stack setup
    :
}

build() {
    stack build --verbose
}

package() {
    :
}

@mpilgrem
Copy link
Member

I am not familiar with makepkg. In the failure log, this line during GHC's configuration process seems important:

2024-03-18 00:35:55.435076: [error] configure: error: Failed to determine machine word size. Does your toolchain actually work?

It seems that something disables GHC's configuration on installation. That is, if this is an issue, it currently seems to me to be at the level of GHC rather than Stack.

@hseg
Copy link
Author

hseg commented Mar 18, 2024 via email

@mpilgrem
Copy link
Member

Stack installs GHC by, essentially, following programmatically the manual install instructions in the INSTALL file provided with the GHC binary distribution: https://downloads.haskell.org/~ghc/9.6.4/ghc-9.6.4-x86_64-fedora33-linux.tar.xz. Stack itself does not pay any attention to any of those environment variables.

I searched GHC's issues for makepkg but did not identify an existing issue: https://gitlab.haskell.org/search?group_id=2&scope=issues&search=makepkg.

As you understand better than me what is makepkg and how it might be affecting adversely GHC's configure script, you are probably better placed than me to raise a GHC issue.

@mpilgrem mpilgrem changed the title Arch Linux: stack build on a fresh system fails, needs stack setup first Arch Linux: makepkg default settings disable GHC's configure script Mar 18, 2024
@mpilgrem
Copy link
Member

Pinging @hasufell (an expert in installing GHC on various Linux distributions) in case he can provide any insight.

@hseg
Copy link
Author

hseg commented Mar 18, 2024 via email

@hseg
Copy link
Author

hseg commented Mar 18, 2024 •
edited
Loading

... Logs didn't attach, here they are:
stack.log

@hseg hseg changed the title Arch Linux: makepkg default settings disable GHC's configure script Arch Linux: Packages with C components fail to build with LDFLAGs containing pack-relative-relocs Mar 18, 2024
@hseg hseg changed the title Arch Linux: Packages with C components fail to build with LDFLAGs containing pack-relative-relocs Arch Linux: Packages with C components fail to build with LDFLAGS containing pack-relative-relocs Mar 18, 2024
@hseg hseg changed the title Arch Linux: Packages with C components fail to build with LDFLAGS containing pack-relative-relocs Arch Linux: GHC with LDFLAGS containing pack-relative-relocs Mar 18, 2024
@hseg hseg changed the title Arch Linux: GHC with LDFLAGS containing pack-relative-relocs Arch Linux: GHC's configure script fails when LDFLAGS contains pack-relative-relocs Mar 18, 2024
@mpilgrem
Copy link
Member

@hseg, that stack.log file seems to be 0 bytes in size. Can you re-supply it?

@mpilgrem
Copy link
Member

@hseg, also - to rule things out - noting "supported since glibc 2.36, GNU Binutils 2.38 and LLVM 15": can you confirm your system has all of those pre-requisities?

@mpilgrem
Copy link
Member

mpilgrem commented Mar 18, 2024 •
edited
Loading

Found on the Internet - by analogy, could it be LLVM-related:

@mpilgrem
Copy link
Member

Extracts from GHC's configure script:

# ac_fn_c_compute_int LINENO EXPR VAR INCLUDES
# --------------------------------------------
# Tries to find the compile-time value of EXPR in a program that includes
# INCLUDES, setting VAR accordingly. Returns whether the value could be
# computed
ac_fn_c_compute_int ()
{

...

# The cast to long int works around a bug in the HP C Compiler
# version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
# declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'.
# This bug is HP SR number 8606223364.
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking size of void *" >&5
$as_echo_n "checking size of void *... " >&6; }
if ${ac_cv_sizeof_void_p+:} false; then :
  $as_echo_n "(cached) " >&6
else
  if ac_fn_c_compute_int "$LINENO" "(long int) (sizeof (void *))" "ac_cv_sizeof_void_p"        "$ac_includes_default"; then :

else
  if test "$ac_cv_type_void_p" = yes; then
     { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error 77 "cannot compute sizeof (void *)
See \`config.log' for more details" "$LINENO" 5; }
   else
     ac_cv_sizeof_void_p=0
   fi
fi

fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_sizeof_void_p" >&5
$as_echo "$ac_cv_sizeof_void_p" >&6; }



cat >>confdefs.h <<_ACEOF
#define SIZEOF_VOID_P $ac_cv_sizeof_void_p
_ACEOF


if test "x$ac_cv_sizeof_void_p" = "x0"; then
    as_fn_error $? "Failed to determine machine word size. Does your toolchain actually work?" "$LINENO" 5
fi

@hseg
Copy link
Author

hseg commented Mar 18, 2024 •
edited
Loading

Oops. Another attempt at attaching the log
stack.log
As for the package versions:

$ pacman -Q binutils glibc llvm-libs 
binutils 2.42-2
glibc 2.39-1
llvm-libs 17.0.6-2

Don't have llvm itself installed, just the runtime libraries. Unsure what's going on there.

@hseg
Copy link
Author

hseg commented Mar 18, 2024

Indeed, tracing the ./configure output, it appears it's invoking GCC, so that bit isn't exotic.

@hseg
Copy link
Author

hseg commented Mar 18, 2024

Found https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/merge_requests/6#note_171460, will report there later today, see what they have to say

@hasufell
Copy link
Contributor

hasufell commented Mar 18, 2024 •
edited
Loading

Archlinux is a clusterf*ck. It has been one of the worst distributions to use Haskell on. First they forced dynamic linking via their PKGBUILDs, causing so much trouble with cabal and other toolings. They really have no idea what they are doing.

We're already warning users about arch being broken crap: https://www.haskell.org/downloads/

Do not use the Haskell development tools provided by Arch, they are broken. For more information see [1] [2].

This just reinforces it. Don't use arch. They don't know what they are doing.

Wrt the LDFLAGs... I asked some people knowledgeable about linking and they think it's bonkers to force pack-relative-relocs.

@hseg
Copy link
Author

hseg commented Mar 18, 2024 •
edited
Loading

Reported this at Arch as well, here's hoping we find a solution better than "burn it all down"
https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/merge_requests/6#note_171667

Though the brokenness of Haskell on Arch is indeed why I build all my Haskell programs statically, relying on stack for dependency resolution rather than
pacman.

@mpilgrem
Copy link
Member

I am going to close this issue, from Stack's perspective, as it seems to be, squarely, 'upstream'. The discussion and links here should be of help to other Arch Linux users who encounter it.

@hasufell
Copy link
Contributor

Reported this at Arch as well, here's hoping we find a solution better than "burn it all down"
https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/merge_requests/6#note_171667

Though the brokenness of Haskell on Arch is indeed why I build all my Haskell programs statically, relying on stack for dependency resolution rather than
pacman.

I still think this should also be raised as a GHC issue.

@hseg
Copy link
Author

hseg commented Mar 19, 2024

Fair enough, raised: https://gitlab.haskell.org/ghc/ghc/-/issues/24565
Another tangent that could be explored here -- why is it that stack build with these LDFLAGS fails, but stack setup && stack build succeeds?

@mpilgrem
Copy link
Member

On that question, the answer seems to be that the environment was set differently in each case (which you can see in the logs in the line [debug] menv = fromList ...).

If we take the log files above in order:

  • stack-bad.log: LDFLAGS not set -> GHC configures
  • stack-good.log: LDFLAGS not set -> GHC configures
  • makepkg.log: LDFLAGS set -> GHC does not configure
  • stack-build-envvars.og: LDFLAGS set -> GHC does not configure
  • stack-build.log: LDFLAGS not set -> GHC configures
  • stack.log: LDFLAGS set -> GHC does not configure

The logs above do not, in fact, include a case where (a) LDFLAGS was set and (b) stack setup succeeded.

@hseg
Copy link
Author

hseg commented Mar 19, 2024 via email

@hseg hseg mentioned this issue Mar 21, 2024
Closed
@hseg
Copy link
Author

hseg commented Mar 21, 2024

In reraising this for Arch, found the root cause -- ghc and other packages were building with LD=ld.gold, which doesn't support these LDFLAGS. GHC is now testing $LD $LDFLAGS works before settling on that choice of LD. Might this be an idea for stack to implement as a sanity check? Suggested this for cabal as well: haskell/cabal#9828

@hasufell
Copy link
Contributor

Yes, the choice of gold was an odd one. GHCup is already forcing ld.bfd on alpine, because gold is causing problems.

@mpilgrem
Copy link
Member

GHC 9.6.5, now released, includes "Ensuring we take LDFLAGS into account when configuring a linker (#24565)."

@ZeekoZhu ZeekoZhu mentioned this issue Aug 12, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: arch-linux component: build resolution: upstream issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hasufell @hseg @mpilgrem