what LLVM does mesa need to build "r300" ?

[Ken Moffat]

On Sun, Jun 10, 2018 at 07:11:23PM -0400, Dennis Clarke wrote:
> On 6/10/18 11:03 AM, Robert Heller wrote:
> > At Sun, 10 Jun 2018 10:41:22 -0400 Dennis Clarke <dclarke at blastwave.org> wrote:
> > > Dear Xorg:
> > > 
> > >       For some days now I have been going in circles trying to get a
> > > build going from git but endlessly run into oddball dependecy issues on
> > > Debian buster :
> > > .
> > > .
> > > .
> > > checking for RADEON... yes
> > > configure: error: --enable-llvm is required when building r300
> > > build.sh: "./autogen.sh" failed on mesa/mesa
> > > build.sh: error processing:  "mesa/mesa"
> > 

I only build a very few packages from git - I do a little on
(beyond) linuxfromscratch (BLFS), and we prefer releases.  My last
build used 18.0.3, although our svn books have moved on since then.

Anyway, in the 18.0.3 release, it looks as if llvm-3.9.0 is the
minimum.  BUT - on x86, x86_64 --enable-llvm defaults to on, so no
need to enable it unless you are on some other Arch.

That error message sounds as if r300 is enabled (I must admit, I
thought only r600 and later needed llvm, but I've never had an r300
and I do build for r600) and that llvm is either incomplete, or too
old.  When I last looked, llvm (only, i.e. not clang) was needed,
and with AMDGPU enabled (as well as host) - but I've now been
building clang for a while (for rust) so that might have changed.
And in older llvm versions the target name might have been
different.

For a released mesa, reading what configure produced will eventually
lead you to the required package/file/version (according to what it
tests for, e.g. for llvm it looks for llvm-config which is probably
in a -dev package).

> > You probably need to pass "--enable-llvm" to build.sh or else edit build.sh
> > to include --enable-llvm on the command line to configure or autogen.sh.
> > 
> 
> I do this sort of thing once every few years as an acid test of the
> whole xorg build process. Something went out the window in the last few
> years .. don't know what but the process went from "works" to "doesn't".
> 

In "every few years" a lot changes.

For x86_64 (and theoretically for i686, although not often tested)
in BLFS we build much of Xorg (not obscure drivers, not the docs
AFAICS).  And apart from version upgrades, not very much has changed
in the Xorg-7.7 (I think we're all still on that ?) era.  New
protocol headers, before that I tried to ditch many of the legacy
fonts, but one of my colleagues reinstated several to avoid warning
messages when using twm for testing.

What you have to remember with BLFS is that we now include Python3
and meson in our base system (LFS).  And a lot of things are moving
to meson.  Also, in our development (svn) books we try to update
most packages soon after a new version appears.  Sometimes (probably
not in Xorg or Mesa) that can leave some packages broken for a
while, until somebody tries to build them.

Also, our dependencies list current versions : in many cases, an
older version will also work.  But for building Xorg itself you
should be using current versions anyway.  And our "recommended"
dependencies often mean "you can build without that, but you'll
need to discover the specific configure (or cmake) switches".

Oh, and we use /lib and /usr/lib on x86_64, not lib64.  I assume
that you may need to add --libdir=/usr/lib64 (or wherever) to our
instructions if your distro uses that.

But with those caveats, I think our method will work for you *for
released versions*.

If you want to try git versions of some packages, fine, but expect
breakge from time to time.  Unless you have a lot of time and
horsepower, building everything from git sounds like a recipe for
frequent pain and bug reports.

So I suggest that you start with current releases.  If you are on
x86, I think our process will work (I'm sure there are others!).

> 
> So maybe I need to just focus on mesa and mesa only and just mess with
> it to get it built all by itself and then see what breaks next. Fair and
> reasonable approach I think.
> 

As I think I've said above, I suggest you build a current release
before trying a git version.

> So .. any hints from anyone on how to poke mesa in the guts and let it
> build?  Given that I have every weird dependency and the kitchen sink
> installed ... and that is saying something right there let me tell you.
> 
> Dennis

When, or if, you get to trying mesa git, take a look at its build
script to see what it is doing.  I'm only really familiar with
configure scripts, but I guess that autoreconf maybe gets invoked -
in that case you will end up with a configure script where you can
take the time to search for error messages and then work backwards
to discover what it is actually looking for.  Fun! (for some
definitions of fun).

ĸen
-- 
              Keyboard not found, Press F1 to continue