[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-sparse
Subject:    Re: problem building sparse 0.6.0 (sparse-llvm)
From:       Luc Van Oostenryck <luc.vanoostenryck () gmail ! com>
Date:       2019-09-28 18:37:13
Message-ID: 20190928183712.vs4ujsd4x4afp5pf () desk ! local
[Download RAW message or body]

On Sat, Sep 28, 2019 at 02:20:29PM +0100, Ramsay Jones wrote:
> On 28/09/2019 02:44, Luc Van Oostenryck wrote:
> > On Sat, Sep 28, 2019 at 02:27:40AM +0100, Ramsay Jones wrote:
> >> On 28/09/2019 00:00, Luc Van Oostenryck wrote:
...
> >>> I suppose that `llvm-config --host-target` returns x86_64-unknown-cygwin ?
> >>
> >> Ah no, I had meant to mention this:
> >>
> >>   $ llvm-config --host-target
> >>   x86_64-unknown-windows-cygnus
> >>   $ 
> >>
> >> ... which agrees with clang, but not llc.
> > 
> > Then the patch could simply be something like:
> > +       LLC_ARCH_OPTS="$LLC_ARCH_OPTS -mtriple=$(llvm-config --host-target)"
> > 
> > but I'm not sure how this would behave with cygwin32 or when using -m32.
> 
> Yeah, I don't know either. Unfortunately, my cygwin32 installation
> is *very* old and on an Windows XP laptop that I would rather not
> connect to the internet at this point ... (Also, I don't think cygwin
> supports windows XP anyway, so ...)
> 
> Anyway, I think it is somewhat odd that clang and the llvm tools
> don't agree on the host 'triple' used during configuration. ;-)

From what I understand one is the triple for the build/config *host*
and the other is for llvm/clang *target*. The first one is produced
and used by the config/build system at build time, the second one is
produced and used by LLVM/clang itself at run-time. They share syntax
and the first is used as default for the second but that's all (but
yes, this doesn't explain why it was working in the previous version).

> I would rather not, but I guess I may have to download the cygwin
> source packages for clang/llvm and take a look at how the binary
> packages are configured/built. I suppose this could be a problem
> with the cygwin packaging, or with upstream - dunno! :(
> 
> Hmm, I will _hopefully_ find time to look at that soon, but I don't
> think anyone needs a quick solution to this ... :-D

Yes, indeed. This cygwin/sparse-llvm combo is quite 'exotic'
(and, as far as I know, nobody is using sparse-llvm). I would be
perfectly fine with a patch like the one here above.

Best regards.
-- Luc
[prev in list] [next in list] [prev in thread] [next in thread]