what LLVM does mesa need to build "r300" ?

Mon Jun 11 00:48:00 UTC 2018

On 6/10/18 8:19 PM, Ken Moffat wrote:
> 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.

I usually go and look at what the folks over at LFS are up to and it is
a great resource.  However in this case I thought it best to look at the
build logs from Debian :

https://buildd.debian.org/status/package.php?p=mesa

One needs only click on the link "installed" for a given arch.
In this case ye amd64.  Lots of great info there.

> 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.
> 

Well, I was not too surprised it was needed and the first snag I hit was
that my old old build box from 2012 wasn't going to fly at all.  Worked
great back then but Debian 8 isn't helping here.  I guess five or six
years is a long long time in the Linux world and hardly a blink in the
UNIX world .. but such is life.

> 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.

I wasn't changing anything and just following along blindly the steps
that  Peter Hutterer has at :

   http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html

Again .. that was 2012.

> 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).

Yep .. got that.  :-\

>>> 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.

Well source .. yes. However build process?  The build process seems to 
now drag in horrific things like python mako ??

https://cgit.freedesktop.org/mesa/mesa/commit/?id=2b37bea010a9c9333a813cc77d28629e1382c0be

So someone figured that it's ok to introduce some oddball tools as a
build dependency.  My oh my what ever happened to Makefile and make :-\

Anyways ... sure .. a lot changes and here we are and dependency hell
is the best description.  Sort of makes me wonder if anyone would ever
get Xorg off the ground on a machine with no X installed and a compiler
and a pot of coffee.  The answer seems to be "no way".

> 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. 

Yep ... https://www.x.org/wiki/Releases/7.7/

> 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.

I'm happy to get the essential adobe fonts and monospace stuff for my
xterms. As a starting point.

> 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.

*sigh*

It has been entirely too long since I tried out LFS and I think the last
great effort I made was Red Hat zoot on sparc and Debian who-knows-what
on an embedded PowerPC just for fun.  Things all pretty much worked back
then.  I do have Debian sid on power and it works pretty well. Even did
a nice bootstrap of gcc 8.1.0 with no real issues.  However I am not yet
looking at building xorg over there on that box today .. starting with
plain jane x86_64 here first.

> 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".

I pretty much go with the latest if it makes sense. That means GNU make
from the sources however things like GNU Make 4.1 work fine.

> Oh, and we use /lib and /usr/lib on x86_64, not lib64.

right on ... me too.  I couldn't be bothered with multi-arch atm.

>  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.

ha .. well here I am.

I could look at the jhbuild process :

     https://www.x.org/wiki/JhBuildInstructions/

However I am not quite finished smashing my forehead into this brick
  wall.  Yet.  Soon.  Not yet.

> 
> 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!).
> 

Well, LFS seems to always work.  At least based on folks I have talked
to and you know ... it may be a good idea to just dump this whole git
source process and give up ... maybe.

>>
>> 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.

    *nod*

> 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

Doing that manually actually.

At the moment I mean.

> 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).

Yep ... seems to be what I do.  The whole idea here is that someone
somewhere with the horsepower and then time should look at sources and
test from the outside of a given project.  Otherwise, how do we know
any of it works?  Let's not even get into "trust".  That is a whole
other kettle of fish and mad discussions are flying in the sqlite ml
on that topic from some old silverbacks.  Myself included.

Dennis