Re: what LLVM does mesa need to build "r300" ?
On Mon, Jun 11, 2018 at 1:11 AM, Dennis Clarke wrote: > > The strange magic words "--enable-llvm" issued to ye "build.sh" result > in being told quickly "no, don't do that ... go away" : > > > fs$ ./util/modular/build.sh --clone --autoresume --enable-llvm built.modules > /usr/local/xorg > the argument '--enable-llvm' of option '--autoresume' looks like an option > itself > The error message is quite helpful in this case, and worth reading closely. The --autoresume option requires an argument, probably "build.modules" which doesn't look like an option itself, and you have inserted your --enable-llvm just in the middle. Regards, Tormod ___ 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
Re: what LLVM does mesa need to build "r300" ?
On Sun, Jun 10, 2018 at 08:48:00PM -0400, Dennis Clarke wrote: > > Otherwise, how do we know > any of it works? All I can do is tell you what _I_ built, on top of LFS from 31st May, on the desktop machine where I'm typing this. My usage is pretty boring - urxvt terms, firefox, gimp, selected PDF viewers, falkon (browser - but without KDE), as well as libreoffice, inkscape, and multimedia progs. All seem to be working normally in my usage. At the risk of going terribly O/T I'll attach the list of what I build for Xorg, in order and with versions. I agree that for something like LFS a from-scratch build is necessary to prove things still fit together (I can remember a few packages which have caused breakage, but I think they were all long after Xorg in *my* build order (but then, I've seen reports this week of LFS users building e.g. LLVM very early and having to change some instructions to stop it being used for other packages). ĸen -- Keyboard not found, Press F1 to continue Packages I built for Xorg on 1st June - AFAICS these are all working adequately. Before I boot the new system I build libpng, libjpeg-turbo and cmake, along with other things which are probably not relevant to building Xorg. After I have booted the new system, I build the following packages which I regard as "docbook-related", I build these on all my systems so I've not tried to build Xorg without them for longer than I can remember. sgml-common-0.6.3 OpenSP-1.5.2 openjade-1.3.2 docbook31 docbook-4.5 docbook-dsssl-1.79 SGMLSpm-1.1 docbook-utils-0.6.14 libxml2-2.9.8 (I also build the python2 module, but that is only for gimp-help) libxslt-1.1.32 docbook-xml-4.5 docbook-xsl-1.79.2 xmlto-0.0.28 And then, in a tty on the new system, I built the following freetype-2.9.1 fontconfig-2.13.0 XML-Simple-2.25 util-macros-1.19.2 xorgproto-2018.4 libXau-1.0.8 libXdmcp-1.1.2 xcb-proto-1.13 libxcb-1.13 xtrans-1.3.5 libX11-1.6.5 libXext-1.3.3 libFS-1.0.7 libICE-1.0.9 libSM-1.2.2 libXScrnSaver-1.2.2 libXt-1.1.5 libXmu-1.1.2 libXpm-3.5.12 libXaw-1.0.13 libXfixes-5.0.3 libXcomposite-0.4.4 libXrender-0.9.10 libXcursor-1.1.15 libXdamage-1.1.4 libfontenc-1.1.3 libXfont2-2.0.3 libXft-2.3.2 libXi-1.7.9 libXinerama-1.1.3 libXrandr-1.5.1 libXres-1.2.0 libXtst-1.2.3 libXv-1.0.11 libXvMC-1.0.10 libXxf86dga-1.1.4 libXxf86vm-1.1.4 libdmx-1.1.4 libpciaccess-0.14 libxkbfile-1.0.9 libxshmfence-1.3 xcb-util-0.4.0 pixman-0.34.0 libdrm-2.4.92 xcb-util-keysyms-0.4.0 # For Python modules, BLFS often pulls them in via pypi # but where a module is used by multiple other modules # I prefer to get a (recent) version - I've been burned # by modules updating their pypi version. docutils-0.14 MarkupSafe-1.0 six-1.11.0 gi-1.2 # I build Sphinx in the hope that one day I'll have time for # building the kernel docs. But I also use it for llvm docs # on this machine Sphinx-1.7.4 llvm-6.0.0.src - the full set of parts, for x86 and AMDGPU # I used to build elfutils here, but libelf is now in LFS itself libvdpau-1.1.1 # wayland etc in case I want to try to build kde wayland-1.15.0 funcsigs-1.0.2 Beaker-1.9.1 Mako-1.0.4 wayland-protocols-1.14 mesa-18.0.3 glu-9.0.0 xbitmaps-1.1.2 iceauth-1.0.8 mkfontdir-1.0.7 mkfontscale-1.1.3 # Random Xorg packages, I can probably drop some of # these, but finding time to check if anything needs # them is the problem. At least htey build. rgb-1.0.4 setxkbmap-1.3.1 xauth-1.0.10 xcursorgen-1.0.6 xdpyinfo-1.3.2 xdriinfo-1.0.6 xev-1.2.2 xgamma-1.0.6 xhost-1.0.7 xkbcomp-1.4.1 xmodmap-1.0.9 xprop-1.2.3 xrandr-1.5.0 xrdb-1.1.1 xrefresh-1.0.6 xset-1.2.4 xsetroot-1.1.2 xwd-1.0.7 xcursor-themes-1.0.5 xkeyboard-config-2.23.1 libepoxy-1.5.2 xorg-server-1.20.0 mtdev-1.1.5 libevdev-1.5.9 libinput-1.10.7 # This machine uses libinput and has an intel CPU with # included video. On other machines I build radeon, # but those were back in April, probably old xorg-server. # And on other machines I still build evdev, but again # I haven't done that for a few months. xf86-input-libinput-0.27.1 xf86-video-intel-20180223 libva-2.1.0 intel-vaapi-driver-2.1.0 xcalc-1.0.4.1 xclock-1.0.7 xinit-1.4.0 rxvt-unicode-9.22 xorg-conf-keyboard : setup a keyboard.conf file dejavu-fonts-ttf-2.37 (lots of other TTF/OTF fonts here) fluxbox-1.3.7 - my initial window manager. ___ 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
Re: what LLVM does mesa need to build "r300" ?
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 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, ou
Re: what LLVM does mesa need to build "r300" ?
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 > > 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 ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/
Re: what LLVM does mesa need to build "r300" ?
On 6/10/18 11:03 AM, Robert Heller wrote: At Sun, 10 Jun 2018 10:41:22 -0400 Dennis Clarke 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" 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". OKay, so from what I can see and with many hours of experimentation here on two machines there really are not any up to date docs that cover how to build all of xorg. What instructions do exist need an update and I'll be happy to look into that if and when I see a single full build complete. That works. More or less works. Not today. Maybe not this week but who knows. The strange magic words "--enable-llvm" issued to ye "build.sh" result in being told quickly "no, don't do that ... go away" : fs$ ./util/modular/build.sh --clone --autoresume --enable-llvm built.modules /usr/local/xorg the argument '--enable-llvm' of option '--autoresume' looks like an option itself Usage: build.sh [options] [prefix] . . . etc etc etc 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. 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 ___ 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
Re: what LLVM does mesa need to build "r300" ?
At Sun, 10 Jun 2018 10:41:22 -0400 Dennis Clarke 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" 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. > > OKay .. however I have that : > > fs$ dpkg-query -l | grep -i "llvm" > ii libllvm5.0:amd641:5.0.2-2 amd64 > Modular compiler and toolchain technologies, runtime librar > ii llvm-5.01:5.0.2-2 amd64 > Modular compiler and toolchain technologies > ii llvm-5.0-dev1:5.0.2-2 amd64 > Modular compiler and toolchain technologies, libraries and > ii llvm-5.0-runtime1:5.0.2-2 amd64 > Modular compiler and toolchain technologies, IR interpreter > ii llvm-5.0-tools 1:5.0.2-2 amd64 > Modular compiler and toolchain technologies, tools > fs$ > > Do I need a particular colour or flavour or ? Sorry for the sarcasm > but I have seen some interesting dependencies pop up such as python mako > template jazz. A lot sure has changed in a few years. > > Any hints? > > > 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 > > -- Robert Heller -- 978-544-6933 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services ___ 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
what LLVM does mesa need to build "r300" ?
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" OKay .. however I have that : fs$ dpkg-query -l | grep -i "llvm" ii libllvm5.0:amd641:5.0.2-2 amd64 Modular compiler and toolchain technologies, runtime librar ii llvm-5.01:5.0.2-2 amd64 Modular compiler and toolchain technologies ii llvm-5.0-dev1:5.0.2-2 amd64 Modular compiler and toolchain technologies, libraries and ii llvm-5.0-runtime1:5.0.2-2 amd64 Modular compiler and toolchain technologies, IR interpreter ii llvm-5.0-tools 1:5.0.2-2 amd64 Modular compiler and toolchain technologies, tools fs$ Do I need a particular colour or flavour or ? Sorry for the sarcasm but I have seen some interesting dependencies pop up such as python mako template jazz. A lot sure has changed in a few years. Any hints? 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
