what LLVM does mesa need to build "r300" ?

Dennis Clarke dclarke at blastwave.org
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


More information about the xorg mailing list