Opened 2 years ago

Closed 2 years ago

Last modified 3 months ago

#7661 closed feature request (fixed)

GHC build system does not detect opt-3.0 and friends

Reported by: singpolyma Owned by: dterei
Priority: normal Milestone:
Component: Compiler Version: 7.7
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Building GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

It is common to install LLVM tools with a version suffix (such as opt-3.0, llc-3.0, etc) so that multiple versions may co-exist. For example, the Debian package llvm-3.0 does this.

It would be nice if the build system could detect such tools without needing --with-opt, etc, specifically.

Attachments (1)

0001-fix-Find-LLVM-tools-when-version-number-at-end-e.g.-.patch (1.7 KB) - added by kgardas 2 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 2 years ago by dterei

So I'm not that familiar with the build system and m4 but looking at this.

However, wouldn't a user typically install llvm on Debian by installing the 'llvm' package. This installs the tools without version suffixes. Its arguable that in the case of a user installing llvm-3.0 package and not the llvm package we shouldn't be trying to handle this for them.

My concern is that I'll only be able to detect opt-3.0 or opt-2.7 or opt-3.2 by enumerating different version possibilities in the configure.ac. Which seems ugly...

comment:2 Changed 2 years ago by thoughtpolice

Well, those distributions typically make the GHC package (which you may use for a bootstrap compiler) depend specifically on llvm-3.0, for those co-existence reasons. So out of the box, you're not necessarily aware that you need the llvm package, or that it's even there! This is very much the case on my ARM/Linux installs (Ubuntu 12.10.) This is the annoying bit. In general I just fix this by symlinking appropriately into my $HOME/bin.

I think you could probably encapsulate most of the hairy machinery in an m4 macro to search for 'llc-X.Y' and 'opt-X.Y' variants, after looking for non-suffixed versions.

comment:3 Changed 2 years ago by dterei

  • Owner set to dterei

Interesting. What do you mean by co-existence reasons sorry? This reason seems fairly compelling to me, just checked the ghc package on Ubuntu then. I'll sleep on it and write out the m4 macro tomorrow. (the ugliness of the macro isn't the concern, that is trivial, it's the maintenance of it for future llvm versions. Easy but annoying).

comment:4 Changed 2 years ago by singpolyma

In my case I'm using llvm-3.0 because default llvm is 3.1, which has regressions when it comes to ARM.

I'd suggest searching for opt-* and then checking if llc-samething exists and using both if found. Hardcoding a list of known suffixes seems bad.

comment:5 Changed 2 years ago by davidterei@…

commit 64aaaa19aa32c69a13daa375c8316041a44eed5c

Author: David Terei <[email protected]>
Date:   Sun Feb 10 23:24:27 2013 -0800

    Find LLVM tools when version number at end (e.g., llc-3.0) (#7661)

 aclocal.m4   |   37 +++++++++++++++++++++++++++++++++++++
 configure.ac |    7 +++++--
 2 files changed, 42 insertions(+), 2 deletions(-)

comment:6 Changed 2 years ago by dterei

  • Resolution set to fixed
  • Status changed from new to closed

comment:7 Changed 2 years ago by kgardas

  • Owner dterei deleted
  • Resolution fixed deleted
  • Status changed from closed to new

Hi David,

unfortunately this is not working on my Ubuntu 12.04.2 LTS on pandaboard. I do have both llc-3.0 and opt-3.0 in /usr/bin and in PATH:

$ which llc-3.0
/usr/bin/llc-3.0
$ which opt-3.0
/usr/bin/opt-3.0

but GHC's configure does not detect them. Configuring with simple ./configure ends with:

Configure completed successfully.

   Building GHC version  : 7.7.20130214

   Build platform        : arm-unknown-linux
   Host platform         : arm-unknown-linux
   Target platform       : arm-unknown-linux

   Bootstrapping using   : /usr/bin/ghc
      which is version   : 7.4.1

   Using gcc                 : /usr/bin/gcc
      which is version       : 4.6.3
   Building a cross compiler : NO

   ld       : /usr/bin/ld
   Happy    : /usr/bin/happy (1.18.9)
   Alex     : /usr/bin/alex (3.0.1)
   Perl     : /usr/bin/perl
   dblatex  : 
   xsltproc : 

   Using LLVM tools
      llc   : 
      opt   : 

   HsColour was not found; documentation will not contain source links

and settings file looks:

$ cat settings
[("GCC extra via C opts", " -fwrapv"),
 ("C compiler command", "/usr/bin/gcc"),
 ("C compiler flags", " -fno-stack-protector  -Wl,--hash-size=31 -Wl,--reduce-memory-overheads"),
 ("ld command", "/usr/bin/ld"),
 ("ld flags", "     --hash-size=31     --reduce-memory-overheads"),
 ("ld supports compact unwind", "YES"),
 ("ld supports build-id", "YES"),
 ("ld is GNU ld", "YES"),
 ("ar command", "/usr/bin/ar"),
 ("ar flags", "q"),
 ("ar supports at file", "YES"),
 ("touch command", "touch"),
 ("dllwrap command", "/bin/false"),
 ("windres command", "/bin/false"),
 ("perl command", "/usr/bin/perl"),
 ("target os", "OSLinux"),
 ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}"),
 ("target word size", "4"),
 ("target has GNU nonexec stack", "False"),
 ("target has .ident directive", "True"),
 ("target has subsections via symbols", "False"),
 ("Unregisterised", "NO"),
 ("LLVM llc command", "llc"),
 ("LLVM opt command", "opt")
 ]

There are two issues with this patch I'm able to see now.

1) in aclocal.m4 in FIND_LLVM_PROG you use

    if test "$1" == ""; then

but this should be:

    if test "$$1" == ""; then

to result in for example "$LLC" == "" instead of "LLC" == ""

2) Ubuntu (and Debian probably does the same), installs LLVM-3.0 package into /usr/lib/llvm-3.0 directory and creates a links to opt/llc into /usr/bin with the prefixes -3.0. That means:

$ ls -la /usr/bin/llc-3.0 
lrwxrwxrwx 1 root root 23 Dec 11  2011 /usr/bin/llc-3.0 -> ../lib/llvm-3.0/bin/llc

The result is that your find test where you find for file will not work as this is not a file, but link. You will also need to find for link (i.e. -type l)

Both issues are fixed by attached patch.

comment:8 Changed 2 years ago by kgardas

  • Owner set to dterei

comment:9 Changed 2 years ago by kgardas

  • Status changed from new to patch

comment:10 Changed 2 years ago by dterei

  • Resolution set to fixed
  • Status changed from patch to closed

Thanks Karel!

I went with a slightly modified version of your patch as I want configure to find the highest version of the llvm tools regardless if the some of the binaries are files or links.

comment:11 Changed 2 years ago by davidterei@…

commit c043732145c274476f904d9b4387740b2a47b401

Author: David Terei <[email protected]>
Date:   Thu Feb 14 15:58:58 2013 +0100

    Fix issues with finding llvm tools again (#7661).
    
    Patch modified from one by Karel Gardas <[email protected]>.

 aclocal.m4 |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

comment:12 Changed 2 years ago by singpolyma

  • Owner dterei deleted
  • Resolution fixed deleted
  • Status changed from closed to new

This has regressed. Bisect sez:

355002c40254f27bb5ca817d7d2664fa58e9640c is the first bad commit
commit 355002c40254f27bb5ca817d7d2664fa58e9640c
Author: David Terei <[email protected]>
Date:   Wed Feb 20 04:05:50 2013 -0800

    Better handling of find llvm tools. Use IFS as opposed to more hacky tr
    approach. This way can handle spaces in paths.

:100644 100644 deedafe75d0418e2f864625b4bef52e30c5d26cb b38418bf06c1c2b76d7c9a04d2ecd126b95b8068 M	aclocal.m4

comment:13 Changed 2 years ago by singpolyma

The following fixes this regression:

diff --git a/aclocal.m4 b/aclocal.m4
index 2ab4ad5..dab7438 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -2022,7 +2022,7 @@ AC_DEFUN([FIND_LLVM_PROG],[
         for p in ${PATH}; do
             if test -d "${p}"; then
                 $1=`${FindCmd} "${p}" -type f -perm +111 -maxdepth 1 -regex '.
-                if test -n "$1"; then
+                if test -n "$$1"; then
                     break
                 fi
             fi

comment:14 Changed 2 years ago by singpolyma

  • Owner set to dterei

comment:15 Changed 2 years ago by singpolyma

  • Status changed from new to patch

comment:16 Changed 2 years ago by davidterei@…

commit f2c477e6c2e7753997947bb0395be99faca169b9

Author: David Terei <[email protected]>
Date:   Wed Jun 19 18:51:03 2013 -0700

    Fix #7661 regression.
    
    Patch from singpolyma.

 aclocal.m4 |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

comment:17 Changed 2 years ago by dterei

  • Resolution set to fixed
  • Status changed from patch to closed

Thanks, pushed.

comment:18 Changed 3 months ago by Austin Seipp <austin@…>

In 1dfab7a8ace5f09f00f8fb695932b4324e88b822/ghc:

Fix detection of llvm-x.x

Summary:
Four bug fixes and a little refactoring.
* `find -perm \mode` should be `find -perm /mode` (#9697)

* `find -regex '$3' should be `find -regex "$3"` (#7661)

From `man sh` on my system (Ubuntu 14.04):
"Enclosing characters in single quotes preserves the literal meaning of all
the characters ..."

* LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for
  detection of #9439.

* -pgmlo and -pgmlc were undocumented because of an xml tag misplacement.

Test Plan:
The aclocal.m4 macro has seen about 10 iterations since its inception. Without a
testsuite, I can't guarantee this version is bug free either. It's all pretty
frustrating.

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D683

GHC Trac Issues: #9697, #7661, #9439
Note: See TracTickets for help on using tickets.