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 <dcla...@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
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
