Updating my Xorg on RHEL 6 etc
Dear X folks : One of the things I have long wanted to do is build X from the ground up and replace the version running on my workstation. This probably is not recommended by the Red Hat folks as I am using RHEL 6 workstation and I am sure that future updates from them would mess with any custom work I am doing. Or perhaps not? Really I don't know. I was going to create a small Debian Linux virtual machine within VMware and then use that to try a build with all X related bits going into /opt under something like /opt/X11. Has anyone done this sort and thing AND written a blog somewhere about it ? Just looking for pointers in the right direction, along with "be careful of .." type stuff. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Updating my Xorg on RHEL 6 etc
> On Tue, Jan 15, 2013 at 8:09 AM, Dennis Clarke > wrote: > > > > Dear X folks : > > > > One of the things I have long wanted to do is build X from the > ground up and replace the > > version running on my workstation. This probably is not recommended > by the Red Hat folks > > as I am using RHEL 6 workstation and I am sure that future updates > from them would mess > > with any custom work I am doing. Or perhaps not? Really I don't know. > > Well RHEL6 gets updates to fairly new bits every second minor release > or so, and yes we don't recommend doing it yourself :-P I sort of figured that was the case. Murky deep waters therein and my workstation runs really really well. All with the exception of dealing with my NVidia Quadro 3500 graphics card, which RHEL seems to think can not do 3-D desktop features. I was thinking, well gee, latest X can do nearly anything one dreams of .. why not .. etc etc > But we have a tinderbox running on RHEL6 and it builds using jhbuild, > > You should probably start by reading: > http://wiki.x.org/wiki/ModularDevelopersGuide Excellent, thank you. I will certainly take a look as well as perhaps roll out a fully separate Debian Linux box for this experiment of mine. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Updating my Xorg on RHEL 6 etc
> > Has anyone done this sort and thing AND written a blog somewhere > about it ? > > > >Just looking for pointers in the right direction, along with "be > careful of .." type stuff. > > you can install a second X server from git (or anywhere) next to your > existing one: > http://who-t.blogspot.com.au/2012/05/testing-x-servers-from-git.html Excellent, thank you. > Obviously, for a production environment I recommend sticking to the > Red Hat supported bits, especially since we keep it quite up-to-date anyway. Well yes, my RHEL world is pretty stable ( I mean rock solid ) and I don't like to mess with that, however I also like to test and do various little things without feeling restricted by my OS vendor ( you know, Microsoft, Oracle etc ). ;-) I will most likely fire up a Debian box for this and see what the issues are with this fancy NVidia Quadro card that RHEL says can not do 3-D acceleration. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Updating my Xorg on RHEL 6 etc
> you can install a second X server from git (or anywhere) next to your > existing one: > http://who-t.blogspot.com.au/2012/05/testing-x-servers-from-git.html side question, who in your opinion makes the absolute best graphics hardware avail for the niX and X world ? Seriously, your opinion. I currently have : $ lspci | grep -i quadro 07:00.0 VGA compatible controller: NVIDIA Corporation G71GL [Quadro FX 3500] (rev a1) With xdpyinfo claims : sedna.adbs.ca $ xdpyinfo name of display::0.0 version number:11.0 vendor string:Red Hat, Inc. vendor release number:11006000 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x5200022, revert to PointerRoot number of extensions:27 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo XVideo-MotionCompensation default screen number:0 number of screens:1 screen #0: dimensions:3320x1080 pixels (878x285 millimeters) resolution:96x96 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x16a depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xfa8033 KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:64 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits . . . etc etc However RHEL 6.3 workstation claims that accelerated 3D graphics is not available. I get this by clicking on the System -> Preferences -> Desktop Effects. Not sure what the issue is but I am guessing it must be either the hardware ( NVidia Quadro FX 3500 ) or the driver in play. even stranger, there are two physical screens but only one in xdpyinfo. That seems wrong or perhaps some XINERAMA magic. Either way ... building a whole new X is a tad extreme but the extreme usually works. Any thoughts you have would be greatly appreciated. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Updating my Xorg on RHEL 6 etc
> When RHEL6.4 is released it would probably be more worth doing, as its > planned to have a newer Mesa. Ah well .. I'll should just await the 6.4 release. I figure it can't be far down the road from this : $ cat /etc/redhat-release Red Hat Enterprise Linux Workstation release 6.3 (Santiago) Of course one wonders .. why not just run the NVidia drivers for Linux ? A brief search on the NVidia site reveals : Linux x64 (AMD64/EM64T) Display Driver --- Version: 304.64 Certified Release Date: 2012.11.06 Operating System: Linux 64-bit Language: English (U.S.) File Size: 64.5 MB Which makes me wonder .. what damage that could do to my otherwise wonderful RHEL workstation. In any case .. the open source drivers may be "good enough" and I could wait 6.4 or roll the dice with the NVidia software. Either way I wonder if the ATI graphics cards are a better choice. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Updating my Xorg on Debian etc
- Original Message - From: Dave Airlie Date: Monday, January 14, 2013 8:43 pm Subject: Re: Updating my Xorg on RHEL 6 etc To: Dennis Clarke Cc: xorg@lists.x.org >> you can install a second X server from git (or anywhere) next to your >> existing one: >> http://who-t.blogspot.com.au/2012/05/testing-x-servers-from-git.html > Following those instructions line by line on a clean Debian 6.0.6 install and running into problems out of the gate : aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg Building to run Linux / x86_64 () Fri Jan 18 23:05:01 EST 2013 Skipping util module component macros... == == Processing module/component: "font/util" ==configuration options: autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd /opt/xorg/share/aclocal/xorg-macros.m4:1780: XORG_INSTALL is expanded from... /opt/xorg/share/aclocal/xorg-macros.m4:1760: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: configure.ac: tracing configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: running: /usr/bin/autoheader configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: running: automake --add-missing --copy --no-force configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... unsupported checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... no checking whether __INTEL_COMPILER is declared... no checking whether __SUNPRO_C is declared... no ./configure: line 4157: PKG_PROG_PKG_CONFIG: command not found checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking if gcc supports -Werror=unknown-warning-option... no checking if gcc supports -Werror=unused-command-line-argument... no checking if gcc supports -Wall... yes checking if gcc supports -Wpointer-arith... yes checking if gcc supports -Wmissing-declarations... yes checking if gcc
trying to build X from git on Debian 6.0.6
Trying to follow the simple instructions at http://who-t.blogspot.com.au/2012/05/testing-x-servers-from-git.html but I get problems within the first three seconds. Little things like needing automake, autogen and such I get. That is okay to deal with. However needing "xorg-macros version 1.12 or higher" I do not see what the issue is there because the blog says you get everything you need in one shot. But .. you don't. So I guess I am asking .. what's the procedure to fire off a build of X ? Dennis --- Begin Message --- - Original Message - From: Dave Airlie Date: Monday, January 14, 2013 8:43 pm Subject: Re: Updating my Xorg on RHEL 6 etc To: Dennis Clarke Cc: xorg@lists.x.org >> you can install a second X server from git (or anywhere) next to your >> existing one: >> http://who-t.blogspot.com.au/2012/05/testing-x-servers-from-git.html > Following those instructions line by line on a clean Debian 6.0.6 install and running into problems out of the gate : aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg Building to run Linux / x86_64 () Fri Jan 18 23:05:01 EST 2013 Skipping util module component macros... == == Processing module/component: "font/util" ==configuration options: autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd /opt/xorg/share/aclocal/xorg-macros.m4:1780: XORG_INSTALL is expanded from... /opt/xorg/share/aclocal/xorg-macros.m4:1760: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: configure.ac: tracing configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: running: /usr/bin/autoheader configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: running: automake --add-missing --copy --no-force configure.ac:26: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2758: XORG_INSTALL is expanded from... aclocal.m4:2738: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... unsupported checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... no checking whether __INTEL_COMPILER is declared...
Re: trying to build X from git on Debian 6.0.6
> > However needing "xorg-macros version 1.12 or higher" I do not see what
> > the issue is there because the blog says you get everything you need
> > in one shot.
>
> Running 'apt-cache search xorg-macros' leads to the xutils-dev package,
> which includes these macros.
Tried that right away and then had to back the package out. Turns out that a
version
level is required and the deb package in the stable repo is too far out of
date.
> However, it rather looks like you're missing the pkg-config package:
Thank you .. I will give that a shot .. let's see here :
aster $ su -
Password:
root@aster:~#
root@aster:~# aptitude search pkg-config
p pkg-config - manage compile and link flags for librarie
root@aster:~# aptitude install pkg-config
The following NEW packages will be installed:
libglib2.0-0{a} libglib2.0-data{a} libpcre3{a} pkg-config
shared-mime-info{a}
0 packages upgraded, 5 newly installed, 0 to remove and 4 not upgraded.
Need to get 3,251 kB of archives. After unpacking 10.9 MB will be used.
Do you want to continue? [Y/n/?]
Get:1 http://mirror.csclub.uwaterloo.ca/debian/ squeeze/main libpcre3 amd64
8.02-1.1 [234 kB]
Get:2 http://mirror.csclub.uwaterloo.ca/debian/ squeeze/main libglib2.0-0 amd64
2.24.2-1 [1,122 kB]
Get:3 http://mirror.csclub.uwaterloo.ca/debian/ squeeze/main libglib2.0-data
all 2.24.2-1 [994 kB]
Get:4 http://mirror.csclub.uwaterloo.ca/debian/ squeeze/main pkg-config amd64
0.25-1.1 [59.2 kB]
Get:5 http://mirror.csclub.uwaterloo.ca/debian/ squeeze/main shared-mime-info
amd64 0.71-4 [841 kB]
Fetched 3,251 kB in 4s (727 kB/s)
Selecting previously deselected package libpcre3.
(Reading database ... 29177 files and directories currently installed.)
Unpacking libpcre3 (from .../libpcre3_8.02-1.1_amd64.deb) ...
Selecting previously deselected package libglib2.0-0.
Unpacking libglib2.0-0 (from .../libglib2.0-0_2.24.2-1_amd64.deb) ...
Selecting previously deselected package libglib2.0-data.
Unpacking libglib2.0-data (from .../libglib2.0-data_2.24.2-1_all.deb) ...
Selecting previously deselected package pkg-config.
Unpacking pkg-config (from .../pkg-config_0.25-1.1_amd64.deb) ...
Selecting previously deselected package shared-mime-info.
Unpacking shared-mime-info (from .../shared-mime-info_0.71-4_amd64.deb) ...
Processing triggers for man-db ...
Setting up libpcre3 (8.02-1.1) ...
Setting up libglib2.0-0 (2.24.2-1) ...
Setting up libglib2.0-data (2.24.2-1) ...
Setting up pkg-config (0.25-1.1) ...
Setting up shared-mime-info (0.71-4) ...
root@aster:~# exit
logout
aster $
aster $ rm -rf xorg/
aster $ rm -rf /opt/xorg/*
aster $ mkdir -p xorg/util
aster $ git clone git://anongit.freedesktop.org/git/xorg/util/modular
xorg/util/modular
Cloning into xorg/util/modular...
remote: Counting objects: 2345, done.
remote: Compressing objects: 100% (1214/1214), done.
remote: Total 2345 (delta 1487), reused 1765 (delta 1125)
Receiving objects: 100% (2345/2345), 1.05 MiB | 835 KiB/s, done.
Resolving deltas: 100% (1487/1487), done.
aster $ cd xorg
aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg
Building to run Linux / x86_64 ()
Mon Jan 21 12:36:04 EST 2013
==
== Processing module/component: "util/macros"
==configuration options:
Cloning into util/macros...
remote: Counting objects: 582, done.
remote: Compressing objects: 100% (421/421), done.
remote: Total 582 (delta 355), reused 263 (delta 161)
Receiving objects: 100% (582/582), 124.37 KiB, done.
Resolving deltas: 100% (355/355), done.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I /opt/xorg/share/aclocal
configure.ac:25: warning: AC_INIT: not a literal:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
autoreconf: configure.ac: tracing
configure.ac:25: warning: AC_INIT: not a literal:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf
configure.ac:25: warning: AC_INIT: not a literal:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:25: warning: AC_INIT: not a literal:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
configure.ac:30: installing `./install-sh'
configure.ac:30: installing `./missing'
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
configure: creating ./config.status
config.status: creating xorg-macros.pc
config.status: creating Makefile
config.status: creating xorg-macros.m4
make: Nothing to be done for `all
Re: trying to build X from git on Debian 6.0.6
> > So the problem, at the moment, is the source me thinks. > > > Try again. > > $ (echo '#include '; echo SSIZE_MAX ) | cpp -E | tail -1 > 9223372036854775807L > $ grep '^# *include' /usr/include/limits.h > #include > #include > # include_next > # include > # include > # include > $ grep '\bSSIZE_MAX' /usr/include/bits/posix1_lim.h > #ifndef SSIZE_MAX > # define SSIZE_MAX LONG_MAX hrmm .. so then, the var should be defined ... but isn't. Any idea why the build fails at that point ? I could just edit the source and change that to LONG_MAX and see what happens. dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: trying to build X from git on Debian 6.0.6
> On Mon, Jan 21, 2013 at 12:53:24 -0500, Dennis Clarke wrote:
>
> > So the problem, at the moment, is the source me thinks.
> >
> Try again.
aster $ diff ./font/util/bdftruncate.c_backup ./font/util/bdftruncate.c
170c170
< if (line_len > SSIZE_MAX) {
---
> if (line_len > LONG_MAX ) {
That progresses neatly and then blows up moments later with :
make all-recursive
make[1]: Entering directory `/home/dclarke/xorg/font/util'
Making all in man
make[2]: Entering directory `/home/dclarke/xorg/font/util/man'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/dclarke/xorg/font/util/man'
make[2]: Entering directory `/home/dclarke/xorg/font/util'
CC bdftruncate.o
CCLD bdftruncate
CC ucs2any.o
ucs2any.c: In function 'zstrdup':
ucs2any.c:103: warning: implicit declaration of function 'strdup'
ucs2any.c:103: warning: nested extern declaration of 'strdup'
ucs2any.c:103: error: assignment makes pointer from integer without a cast
ucs2any.c: In function 'usage':
ucs2any.c:444: error: string length '913' is greater than the length '509' ISO
C90 compilers are required to support
make[2]: *** [ucs2any.o] Error 1
make[2]: Leaving directory `/home/dclarke/xorg/font/util'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dclarke/xorg/font/util'
make: *** [all] Error 2
build.sh: "make " failed on font/util
build.sh: error processing module/component: "font/util"
aster $
Hrmmm .. I guess these CFLAGS are not going to work :
aster $ echo $CFLAGS
-m64 -g -malign-double -std=iso9899:199409 -pedantic-errors -mno-mmx -mno-sse
-fexceptions -fpic -fvisibility=default -mtune=opteron -march=opteron
-m128bit-long-double -mpc80 -Wl,-rpath=/usr/local/lib:/usr/local/gcc4/lib64
-Wl,-q
aster $
Is there a README somewhere that points to a build instruction sheet or INSTALL
doc or similar ?
dc
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: trying to build X from git on Debian 6.0.6
> > So you are using insane C flags and you want us to debug them? try > dropping -pedantic-errors, and maybe -std= Not at all .. I don't have a point of reference and those CFLAGS were in my .profile ... I just never thought to look at them. I was certainly able to build piles of stuff like that and then thought .. why not? aster $ rm -rf xorg/ aster $ rm -rf /opt/xorg/* aster $ mkdir -p xorg/util aster $ git clone git://anongit.freedesktop.org/git/xorg/util/modular xorg/util/modular Cloning into xorg/util/modular... remote: Counting objects: 2345, done. remote: Compressing objects: 100% (1214/1214), done. remote: Total 2345 (delta 1486), reused 1764 (delta 1125) Receiving objects: 100% (2345/2345), 1.05 MiB | 19 KiB/s, done. Resolving deltas: 100% (1486/1486), done. aster $ cd xorg aster $ aster $ echo $CFLAGS -m64 -g -malign-double -mno-mmx -mno-sse -fexceptions -fpic -fvisibility=default -mtune=opteron -march=opteron -m128bit-long-double -mpc80 -Wl,-q aster $ aster $ aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg Building to run Linux / x86_64 () Mon Jan 21 20:56:17 EST 2013 == == Processing module/component: "util/macros" ==configuration options: Cloning into util/macros... remote: Counting objects: 582, done. remote: Compressing objects: 100% (421/421), done. . . . seems to be moving right along .. So this is usually the process : 1) look around for a maillist 2) ask really silly questions 3) hopefully get pointed to a README or FAQ or a blog or get told I'm an id10t etc 4) try what I get told or see etc .. flail .. make coffee 5) fail? If success go to (8) 6) ask questions on a mailist in hope ... 7) goto (2) 8) issue many thanks ... learn .. study .. try to figure out what next I am in the (2) <--> (7) loop and making progress ... so this is typical I would say. dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: trying to build X from git on Debian 6.0.6
> Dave. As an explanation, I hope, ultimately, to get a nice up to date Radeon driver on my Debian wheezy laptop[1] as per : http://www.x.org/wiki/radeonBuildHowTo So really I have a plan .. to get to a better quality build with great graphics which can actually play high quality framerate video etc because at the moment if I insert a Star Wars DVD and fire up VLC then I have to hit the power button to get the machine back. Hitting CTRL-ALT-BACKSPACE gets totally ignored and the machine locks up. So my hope is that my Debian wheezy laptop runs much better as well as my day to RHEL6 workstation. All from /opt/xorg of course and without killing the vendor packages. So .. at least .. that is the plan and I have months to get there. I do apologize for wandering in like an id10t and just asking questions. I know that I will mess up. Over and over. Hopefully at the end I can write a really detailed blog that allows others to do the same with nearly perfectly easy to follow "do this and then this" type instructions. Dennis [1] mars $ lspci 00:00.0 Host bridge: Advanced Micro Devices [AMD] Family 14h Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Wrestler [Radeon HD 6320] 00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] 00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 42) 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller (rev 40) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge (rev 40) 00:15.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0) 00:15.1 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB700/SB800/SB900 PCI to PCI bridge (PCIE port 1) 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 0 (rev 43) 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 6 00:18.6 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 5 00:18.7 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 7 02:00.0 Ethernet controller: Atheros Communications Inc. AR8152 v2.0 Fast Ethernet (rev c1) 03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01) ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: trying to build X from git on Debian 6.0.6
> So you are using insane C flags and you want us to debug them? try > dropping -pedantic-errors, and maybe -std= > > Dave. Much better progress .. for a while : == == Processing module/component: "xcb/proto" ==configuration options: Cloning into xcb/proto... remote: Counting objects: 1227, done. remote: Compressing objects: 100% (519/519), done. remote: Total 1227 (delta 855), reused 990 (delta 695) Receiving objects: 100% (1227/1227), 273.79 KiB, done. Resolving deltas: 100% (855/855), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --copy --no-force configure.ac:9: installing `./install-sh' configure.ac:9: installing `./missing' xcbgen/Makefile.am:3: installing `./py-compile' autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for xmllint... no configure: WARNING: xmllint not found; unable to validate against schema. checking for a Python interpreter with version >= 2.5... none configure: error: no suitable Python interpreter found build.sh: "autogen.sh" failed on xcb/proto build.sh: error processing module/component: "xcb/proto" aster $ okay looks like something called xmllint is required ... I'll hunt for that and then try again. Thank you very much .. I think this is progress. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: trying to build X from git on Debian 6.0.6
> On 01/21/13 05:08 PM, Dennis Clarke wrote: > > Hrmmm .. I guess these CFLAGS are not going to work : > > > > aster $ echo $CFLAGS > > -m64 -g -malign-double -std=iso9899:199409 -pedantic-errors > > Current X sources require some C99 features, but you've told your > compiler to play dumb and refuse to compile C99 sources with > that -std flag set to the 1994 update to C89. Well good day to you Sir. It is good to see that you are well, at least I hope so, and that you are still deeply into X. It would be of the very greatest value if you were still doing the good work that you do on Solaris also. I was afraid to even breech the topic and it was only after a week of my own quiet flail and mistakes that I dare wander into this maillist. My hope was that a bare bones Debian install would be a good path of least resistance with an actual Xorg package being built on Solaris somewhere down the road. Indeed, yes, good to see your name on an email. Having said all that, I am less comfortable in Linux than Solaris but such is life. I had CFLAGS in my .profile ( .bashrc etc ) that simply shot me in the foot. At the moment I am going to try to use these : aster $ echo $CFLAGS -m64 -g -malign-double -fexceptions -fpic -fvisibility=default -mtune=opteron -march=opteron -m128bit-long-double -mpc80 -Wl,-q At least reasonable if not a bit verbose. I am not too sure where the libs required for X will reside otherwise I would do -Wl,--rpath=foo now to ensure the dynamic section of the ELF struct pointed to the correct RPATH. For now I think I will stay in a tight loop going from "try, fail, identify" through to "reset, correct the deps needed, try again" until everything just builds out of the gate. Hopefully the final bits of getting X to start with a dead simple wm like twm will be a no brainer. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
xcb/libxcb : configure: error: XCB requires xsltproc.
This was once titled "trying to build X from git on Debian 6.0.6" however the
essential dependecies and initial falling over on my own face seems to have
been passed. May as well get specific as each problem occurs.
All seems to be progressing neatly, however :
aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg
Building to run Linux / x86_64 ()
Tue Jan 22 16:04:16 EST 2013
==
== Processing module/component: "util/macros"
==configuration options:
.
.
.
make[1]: Leaving directory `/home/dclarke/xorg/xcb/pthread-stubs'
==
== Processing module/component: "xcb/libxcb"
==configuration options:
Cloning into xcb/libxcb...
remote: Counting objects: 2611, done.
remote: Compressing objects: 100% (1170/1170), done.
remote: Total 2611 (delta 1781), reused 2034 (delta 1368)
Receiving objects: 100% (2611/2611), 553.61 KiB | 584 KiB/s, done.
Resolving deltas: 100% (1781/1781), done.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I /opt/xorg/share/aclocal
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:26: installing `./config.guess'
configure.ac:26: installing `./config.sub'
configure.ac:16: installing `./install-sh'
configure.ac:16: installing `./missing'
src/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for a Python interpreter with version >= 2.6... python
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory... ${prefix}/lib/python2.6/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.6/site-packages
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for CHECK... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works.
Re: xcb/libxcb : configure: error: XCB requires xsltproc.
- Original Message - From: Alan Coopersmith Date: Tuesday, January 22, 2013 5:32 pm Subject: Re: xcb/libxcb : configure: error: XCB requires xsltproc. To: Dennis Clarke Cc: xorg@lists.x.org > On 01/22/13 02:26 PM, Dennis Clarke wrote: > > Not sure how to provide xsltproc if it isn't in the sources pulled > from git. > > Despite the name starting with "x", xsltproc is not an X.Org application, ah, that will do it then. > but part of the software for using XSLT stylesheets to transform XML > documents. > > It's listed in the XML tools section of the list of tools required to > build X: > http://www.x.org/wiki/ModularDevelopersGuide#Required_Tools looks like that site is down : Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 608011835 Varnish cache server Perhaps there is a mirror ? dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Error 503 Service Unavailable
Is there someone that can give that server a nudge ? http://www.x.org/wiki/ModularDevelopersGuide#Required_Tools still tossing a 503 :-( dc --- Begin Message --- On 01/22/13 02:26 PM, Dennis Clarke wrote: > Not sure how to provide xsltproc if it isn't in the sources pulled from git. Despite the name starting with "x", xsltproc is not an X.Org application, but part of the software for using XSLT stylesheets to transform XML documents. It's listed in the XML tools section of the list of tools required to build X: http://www.x.org/wiki/ModularDevelopersGuide#Required_Tools -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc --- End Message --- ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Error 503 Service Unavailable
> On Ter, 2013-01-22 at 20:10 -0500, Dennis Clarke wrote: > > Is there someone that can give that server a nudge ? > > > > http://www.x.org/wiki/ModularDevelopersGuide#Required_Tools > > > > still tossing a 503 :-( > > yeah all http://www.freedesktop.org/ > is giving us a Guru Meditation: > (Varnish cache server) > Might be a not bad idea to toss out varnish and just leave in Apache 2.4.3 and the usual bits. In the mean while I will assume that the sources I am looking for are at ftp://xmlsoft.org/libxslt/libxslt-1.1.28.tar.gz If I build that into /usr/local then maybe, perhaps, I can go back to trying to a build of X and see what happens next. dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Error 503 Service Unavailable
> On Wed, 23 Jan 2013, 01:30:33 GMT, Dennis Clarke > wrote: > > > In the mean while I will assume that the sources I am looking for > are at > > > > ftp://xmlsoft.org/libxslt/libxslt-1.1.28.tar.gz > > > > If I build that into /usr/local then maybe, perhaps, I can go back to > > trying to a build of X and see what happens next. > The Debian packaged version should be okay. Perhaps you need to > "apt-get install libxslt-dev"? > Managed to get past that just fine .. then after a few more installs of this lib and that tool and a few odds and sods I ended up with a really ugly bit. I'll post that in a separate message with an appropriate subject line. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied
Rightly so, my build halted when it tried to make a change in /lib/udev/rules.d which is well outside of my /opt/xorg target directory. Do I need to isolate this module, build it as root, and then go back to being a regular user or ?? details attached . Dennis == == Processing module/component: "driver/xf86-input-vmmouse" ==configuration options: Cloning into driver/xf86-input-vmmouse... remote: Counting objects: 513, done. remote: Compressing objects: 100% (343/343), done. remote: Total 513 (delta 295), reused 286 (delta 170) Receiving objects: 100% (513/513), 102.05 KiB | 105 KiB/s, done. Resolving deltas: 100% (295/295), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: configure.ac: tracing configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: libtoolize --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoconf configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoheader configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: automake --add-missing --copy --no-force configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:41: installing `./config.guess' configure.ac:41: installing `./config.sub' configure.ac:33: installing `./install-sh' configure.ac:33: installing `./missing' shared/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking how to run the C preprocessor... gcc -std=gnu99 -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... no checking whether __INTEL_COMPILER is declared... no checking whether __SUNPRO_C is declared... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking if gcc -std=gnu99 supports -Werror=unknown-warning-option... no checking if gcc -std=gnu99 supports -Werror=unused-command-line-argument... no checking if gcc -std=gnu99 supports -Wall... yes checking if gcc -std=gnu99 supports -Wpointer-arith... yes checking if gcc -std=gnu99 supports -Wmissing-declarations... yes checking if gcc -std=gnu99 supports -Wformat=2... yes checking if gcc -std=gnu99 supports -Wstrict-prototypes... yes checking if gcc -std=gnu99 supports -Wmissing-prototypes... yes checking if gcc -std=gnu99 supports -Wnested-externs... yes checking if gcc -std=gnu99 supports -Wbad-function-cast... yes checking if gcc -std=gnu99 supports -Wold-style-definition... yes checking if gcc -std=gnu99 supports -Wdeclaration-after-statement... yes checking if gcc -std=gnu99 supports -Wunused... yes checking if gcc -std=gnu99 supports -Wuninitialized... yes checking if gcc -std=gnu99 supports -Wshadow... yes checking if g
driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied
Rightly so, my build halted when it tried to make a change in /lib/udev/rules.d which is well outside of my /opt/xorg target directory. Do I need to isolate this module, build it as root, and then go back to being a regular user or ?? details attached . Dennis == == Processing module/component: "driver/xf86-input-vmmouse" ==configuration options: Cloning into driver/xf86-input-vmmouse... remote: Counting objects: 513, done. remote: Compressing objects: 100% (343/343), done. remote: Total 513 (delta 295), reused 286 (delta 170) Receiving objects: 100% (513/513), 102.05 KiB | 105 KiB/s, done. Resolving deltas: 100% (295/295), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: configure.ac: tracing configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: libtoolize --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoconf configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoheader configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: automake --add-missing --copy --no-force configure.ac:24: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:41: installing `./config.guess' configure.ac:41: installing `./config.sub' configure.ac:33: installing `./install-sh' configure.ac:33: installing `./missing' shared/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking how to run the C preprocessor... gcc -std=gnu99 -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... no checking whether __INTEL_COMPILER is declared... no checking whether __SUNPRO_C is declared... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking if gcc -std=gnu99 supports -Werror=unknown-warning-option... no checking if gcc -std=gnu99 supports -Werror=unused-command-line-argument... no checking if gcc -std=gnu99 supports -Wall... yes checking if gcc -std=gnu99 supports -Wpointer-arith... yes checking if gcc -std=gnu99 supports -Wmissing-declarations... yes checking if gcc -std=gnu99 supports -Wformat=2... yes checking if gcc -std=gnu99 supports -Wstrict-prototypes... yes checking if gcc -std=gnu99 supports -Wmissing-prototypes... yes checking if gcc -std=gnu99 supports -Wnested-externs... yes checking if gcc -std=gnu99 supports -Wbad-function-cast... yes checking if gcc -std=gnu99 supports -Wold-style-definition... yes checking if gcc -std=gnu99 supports -Wdeclaration-after-statement... yes checking if gcc -std=gnu99 supports -Wunused... yes checking if gcc -std=gnu99 supports -Wuninitialized... yes checking if gcc -std=gnu99 supports -Wshadow... yes checkin
Re: driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied
> > Do I need to isolate this module, build it as root, and then go back > to being a > > regular user or ?? > > vmmouse gets the directory to install the udev rules from pkgconfig by > default, or --with-udev-rules-dir at configure time. if you don't need > the > rules, you can consider the installation as successful though and continue > to the next module. Not too sure how to deal with that. I generally just do a pull from git and then fire off a build. This proceeds neatly until it hits the vmmouse module which stops the process. I don't see an option anywhere to skip it and I don't know if it is a "need" or a "want". What I could do is put the username doing the compile into a group called "xorg" and give that group write permissions to a few specific directories. Is that what you suggest ? Or am I supposed to do this build as the root user? Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied
- Original Message - From: Peter Hutterer Date: Thursday, January 24, 2013 6:24 pm Subject: Re: driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied To: Dennis Clarke Cc: x...@lists.freedesktop.org > On Thu, Jan 24, 2013 at 01:11:36PM -0500, Dennis Clarke wrote: > > > > > > Do I need to isolate this module, build it as root, and then go > back > > > to being a > > > > regular user or ?? > > > > > > vmmouse gets the directory to install the udev rules from > pkgconfig by > > > default, or --with-udev-rules-dir at configure time. if you don't > need > > > the > > > rules, you can consider the installation as successful though and > continue > > > to the next module. > > > > Not too sure how to deal with that. I generally just do a pull from > git and > > then fire off a build. This proceeds neatly until it hits the > vmmouse module > > which stops the process. I don't see an option anywhere to skip it > and > > I don't know if it is a "need" or a "want". > > > > What I could do is put the username doing the compile into a group called > > "xorg" and give that group write permissions to a few specific directories. > > > > Is that what you suggest ? Or am I supposed to do this build as the > root user? > > - custom user with the right permissions or root is one option > - set $CONFFLAGS in the environment to --with-udev-rules-dir. other modules > will ignore it, those that don't would likely run into the same permission > issue anyway I am trying to do this compile as anyone would do any other software package which would generally have an install stage that comes after the compile and test phases. So the safe bet is to set CONFFLAGS with something like this : --with-udev-rules-dir=/opt/xorg/udev Dis that and the compile now proceeds but there will need to be some funky install done later to copy those bits in /opt/xorg/udev over to the /etc dir. Maybe .. not sure. Doing a compile as root is just not going to happen. Not without a full system backup first. ps .. spoke too soon. the compile just failed again and quickly too : == == Processing module/component: "driver/xf86-input-synaptics" ==configuration options: --with-udev-rules-dir=/opt/xorg/udev Cloning into driver/xf86-input-synaptics... remote: Counting objects: 6253, done. remote: Compressing objects: 100% (3270/3270), done. remote: Total 6253 (delta 4327), reused 4343 (delta 2943) Receiving objects: 100% (6253/6253), 1.32 MiB | 1.05 MiB/s, done. Resolving deltas: 100% (4327/4327), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: configure.ac: tracing configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: libtoolize --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoconf configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoheader configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: automake --add-missing --copy --no-force configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:39: installing `./config.guess' configure.ac:39: installing `./config.sub' configure.ac:34: installing `./install-sh' configure.ac:34: installing `./missing' src/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' configure: WARNING: unrecognized options: --with-udev-rules-dir checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking build system type... x86
Re: driver/xf86-input-vmmouse : cannot create regular file `/lib/udev/rules.d/69-xorg-vmmouse.rules': Permission denied
> > > > I am trying to do this compile as anyone would do any other software > package > > which would generally have an install stage that comes after the > compile and > > test phases. So the safe bet is to set CONFFLAGS with something > like > > this : --with-udev-rules-dir=/opt/xorg/udev > > > > Did that and the compile now proceeds but there will need to be some > funky > > install done later to copy those bits in /opt/xorg/udev over to the > /etc dir. > > there is no good answer to this. we can make the driver compile and install > so it works out of the box _or_ we can make the driver compile as user, > without installing udev files. We can't get both, permissions get in > the way here. I am thinking that maybe there is a "install.sh" stage that can be written after the whole compile is done as a user. I see "X" as one of those essentials in the niX world and it is worth while to flail into this and see what I get. I know that I can bootstrap latest GCC without issue and after checking into the Linux From Scratch project repeatedly over the past decade it may be possible one day to have a distro that bootstraps from a USB key, pulls down a pile of sources and then bootstraps GCC, then bootstraps a generic kernel and finally userspace with X. Probably a silly dream but I nearly have GCC build with a script that wget's tarballs and just "does stuff". Anyways, without going way to far OT I just hit a snag : > > configure: error: Package requirements (mtdev) were not met: > > No package 'mtdev' found root@aster:~# aptitude search mtdev nothing found ... I need to figure out what mtdev is, what X wants and then get it sorted out. :-\ > it's quite hard documenting some of those "secrets". e.g. the udev dir > variable I literally only found in the configure.ac file after reading > your > email. it's documented (./configure --help shows it), but that > requires that > one knows what udev rules are, etc. So the tricky bit here is where to > start and when to stop documenting? Never hold back from writing 100 line comments in the source ! :-) I don't know. I knew that X was the real Mt. Everest to climb and since no one seems to just jump in and try it out from sources, I would, you know, get oxygen gear and give it a go. > > we don't have a useful list of dependencies because it's a moving target, > and it depends on the module set you're building. Well I was following a blog that claims I get everything from soup to nuts with this approach. Seemed like a good way to climb the mountain. > You can use your distro to install the build-deps for you though. The > sledgehammer approach on Fedora is yum-builddep "xorg-x11-*" Hr I guess I could try that on Debian and see what I see. Normally I run a RHEL workstation and Solaris servers but for this purpose I setup a bare bones Debian with no X and not much else. This is progressing well, I just need to go figure out what mtdev is?!?! Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
bug id=57303
Looks like I ran headlong into bug id=57303. following the same process I have been on for a week or so now I do the following : aster $ rm -rf xorg/ aster $ rm -rf /opt/xorg/* aster $ mkdir -p xorg/util aster $ CONFFLAGS=\-\-with\-udev\-rules\-dir\=/opt/xorg/udev aster $ export CONFFLAGS aster $ git clone git://anongit.freedesktop.org/git/xorg/util/modular xorg/util/modular Cloning into xorg/util/modular... remote: Counting objects: 2345, done. remote: Compressing objects: 100% (1214/1214), done. remote: Total 2345 (delta 1486), reused 1765 (delta 1125) Receiving objects: 100% (2345/2345), 1.05 MiB | 729 KiB/s, done. Resolving deltas: 100% (1486/1486), done. aster $ cd xorg aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg proceeds neatly until : == == Processing module/component: "driver/xf86-video-ark" ==configuration options: --with-udev-rules-dir=/opt/xorg/udev Cloning into driver/xf86-video-ark... remote: Counting objects: 353, done. remote: Compressing objects: 100% (231/231), done. remote: Total 353 (delta 197), reused 216 (delta 111) Receiving objects: 100% (353/353), 57.77 KiB, done. Resolving deltas: 100% (197/197), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: configure.ac: tracing configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: libtoolize --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: /usr/bin/autoconf configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: /usr/bin/autoheader configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: automake --add-missing --copy --no-force configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark configure.ac:41: installing `./config.guess' configure.ac:41: installing `./config.sub' configure.ac:34: installing `./install-sh' configure.ac:34: installing `./missing' src/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' configure: WARNING: unrecognized options: --with-udev-rules-dir checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking how to run the C preprocessor... gcc -std=gnu99 -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... no checking whether __INTEL_COMPILER is declared... no checking whether __SUNPRO_C is declared... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking if gcc -std=gnu99 supports -Werror=unknown-warning-option... no checking if gcc -std=gnu99 supports -Werror=unused-command-line-argument... no checking if gcc -std=gnu99 supports -Wall... yes checking if
bug id=57303
Looks like I ran headlong into bug id=57303. following the same process I have been on for a week or so now I do the following : aster $ rm -rf xorg/ aster $ rm -rf /opt/xorg/* aster $ mkdir -p xorg/util aster $ CONFFLAGS=\-\-with\-udev\-rules\-dir\=/opt/xorg/udev aster $ export CONFFLAGS aster $ git clone git://anongit.freedesktop.org/git/xorg/util/modular xorg/util/modular Cloning into xorg/util/modular... remote: Counting objects: 2345, done. remote: Compressing objects: 100% (1214/1214), done. remote: Total 2345 (delta 1486), reused 1765 (delta 1125) Receiving objects: 100% (2345/2345), 1.05 MiB | 729 KiB/s, done. Resolving deltas: 100% (1486/1486), done. aster $ cd xorg aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg proceeds neatly until : == == Processing module/component: "driver/xf86-video-ark" ==configuration options: --with-udev-rules-dir=/opt/xorg/udev Cloning into driver/xf86-video-ark... remote: Counting objects: 353, done. remote: Compressing objects: 100% (231/231), done. remote: Total 353 (delta 197), reused 216 (delta 111) Receiving objects: 100% (353/353), 57.77 KiB, done. Resolving deltas: 100% (197/197), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: configure.ac: tracing configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: libtoolize --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: /usr/bin/autoconf configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: /usr/bin/autoheader configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark autoreconf: running: automake --add-missing --copy --no-force configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/ark configure.ac:41: installing `./config.guess' configure.ac:41: installing `./config.sub' configure.ac:34: installing `./install-sh' configure.ac:34: installing `./missing' src/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' configure: WARNING: unrecognized options: --with-udev-rules-dir checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking how to run the C preprocessor... gcc -std=gnu99 -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... no checking whether __INTEL_COMPILER is declared... no checking whether __SUNPRO_C is declared... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking if gcc -std=gnu99 supports -Werror=unknown-warning-option... no checking if gcc -std=gnu99 supports -Werror=unused-command-line-argument... no checking if gcc -std=gnu99 supports -Wall... yes checking if gcc -s
Re: bug id=57303
> On 01/25/13 01:28 PM, Dennis Clarke wrote: > > build.sh: error processing module/component: "driver/xf86-video-ark" > > > > Looks like I need mibstore.h and based on the bug report it lives at > : > > > > http://www.opensource.apple.com/source/X11server/X11server-85/kdrive/xorg-server-1.6.0/mi/mibstore.h > > > > > > Any chance to make a change and push it back into the git repo to > get passed this ? > > Nope. Better for you to edit the list of modules you pass the build > script to > not try to build drivers no one can maintain any more since the > hardware hasn't > been seen in a decade or two. You mean my old PCI Matrox Millenium isn't up to date ? :-) Well, yep, agree. Now then, how does one instruct the build process to bypass such things ? dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: bug id=57303
> > Any chance to make a change and push it back into the git repo to > get passed this ? > > Nope. Better for you to edit the list of modules you pass the build > script to > not try to build drivers no one can maintain any more since the > hardware hasn't > been seen in a decade or two. Why not just stuff this header in the src dir and forget about it ? /*- * mibstore.h -- * Header file for users of the MI backing-store scheme. * * Copyright (c) 1987 by the Regents of the University of California * * Permission to use, copy, modify, and distribute this * software and its documentation for any purpose and without * fee is hereby granted, provided that the above copyright * notice appear in all copies. The University of California * makes no representations about the suitability of this * software for any purpose. It is provided "as is" without * express or implied warranty. */ #ifndef _MIBSTORE_H #define _MIBSTORE_H #include "screenint.h" extern void miInitializeBackingStore( ScreenPtr /*pScreen*/ ); #endif /* _MIBSTORE_H */ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: bug id=57303
> > because this won't be the last change that breaks this module and if we > don't have anyone who actually runs and maintains this driver, any work > spent on it is wasted. > Fair enough. I only want the NVidia and ATI Radeon drivers at the moment anyways and should comment out everything else. I'll dig into that build script, see where it lists the "modules" or "drivers" and then try again from the top, with feeling. And coffee. Thanks for the reply. dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: bug id=57303
> > build.sh takes a --modfile arg listing all the modules you want to build. awesome. I looked in there and saw the tseng driver for an IBM PS/2 from 1994 I think. Not needed. Well, at the moment the only trouble spot I seem to hit was something called a newport driver, so I commented that out in the build.sh script : aster $ diff util/modular/build.sh_backup util/modular/build.sh 893c893 < build driver xf86-video-newport --- > # build driver xf86-video-newport Fire off a rebuild and see : aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg Building to run Linux / x86_64 () Fri Jan 25 19:46:35 EST 2013 Skipping util module component macros... Skipping font module component util... Skipping doc module component xorg-sgml-doctools... Skipping doc module component xorg-docs... Skipping proto module component bigreqsproto... Skipping proto module component compositeproto... Skipping proto module component damageproto... Skipping proto module component dmxproto... Skipping proto module component dri2proto... Skipping proto module component fixesproto... Skipping proto module component fontsproto... Skipping proto module component glproto... Skipping proto module component inputproto... Skipping proto module component kbproto... Skipping proto module component randrproto... Skipping proto module component recordproto... Skipping proto module component renderproto... Skipping proto module component resourceproto... Skipping proto module component scrnsaverproto... Skipping proto module component videoproto... Skipping proto module component x11proto... Skipping proto module component xcmiscproto... Skipping proto module component xextproto... Skipping proto module component xf86bigfontproto... Skipping proto module component xf86dgaproto... Skipping proto module component xf86driproto... Skipping proto module component xf86vidmodeproto... Skipping proto module component xineramaproto... Skipping xcb module component proto... Skipping util module component makedepend... Skipping lib module component libxtrans... Skipping lib module component libXau... Skipping lib module component libXdmcp... Skipping xcb module component pthread-stubs... Skipping xcb module component libxcb... Skipping xcb module component util... Skipping xcb module component util-image... Skipping xcb module component util-keysyms... Skipping xcb module component util-renderutil... Skipping xcb module component util-wm... Skipping lib module component libX11... Skipping lib module component libXext... Skipping lib module component libdmx... Skipping lib module component libfontenc... Skipping lib module component libFS... Skipping lib module component libICE... Skipping lib module component libSM... Skipping lib module component libXt... Skipping lib module component libXmu... Skipping lib module component libXpm... Skipping lib module component libXaw... Skipping lib module component libXfixes... Skipping lib module component libXcomposite... Skipping lib module component libXrender... Skipping lib module component libXdamage... Skipping lib module component libXcursor... Skipping lib module component libXfont... Skipping lib module component libXft... Skipping lib module component libXi... Skipping lib module component libXinerama... Skipping lib module component libxkbfile... Skipping lib module component libXrandr... Skipping lib module component libXRes... Skipping lib module component libXScrnSaver... Skipping lib module component libXtst... Skipping lib module component libXv... Skipping lib module component libXvMC... Skipping lib module component libXxf86dga... Skipping lib module component libXxf86vm... Skipping lib module component libpciaccess... Skipping pixman module component ... Skipping mesa module component drm... Skipping mesa module component mesa... Skipping data module component bitmaps... Skipping app module component appres... Skipping app module component bdftopcf... Skipping app module component beforelight... Skipping app module component bitmap... Skipping app module component editres... Skipping app module component fonttosfnt... Skipping app module component fslsfonts... Skipping app module component fstobdf... Skipping app module component iceauth... Skipping app module component ico... Skipping app module component listres... Skipping app module component luit... Skipping app module component mkcomposecache... Skipping app module component mkfontdir... Skipping app module component mkfontscale... Skipping app module component oclock... Skipping app module component rgb... Skipping app module component rendercheck... Skipping app module component rstart... Skipping app module component scripts... Skipping app module component sessreg... Skipping app module component setxkbmap... Skipping app module component showfont... Skipping app module component smproxy... Skipping app module component twm... Skipping app module component viewres... Skipping app modul
Re: bug id=57303
> > Fire off a rebuild and see : > > aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg > > Building to run Linux / x86_64 () > > Fri Jan 25 19:46:35 EST 2013 > > Skipping util module component macros... > > skipping means it didn't build it, so judging by the output you > skipped all modules. > Just my luck :-) Well I have it down to the following very repeatable steps : aster $ rm -rf xorg/ aster $ rm -rf /opt/xorg/* aster $ mkdir -p xorg/util aster $ git clone git://anongit.freedesktop.org/git/xorg/util/modular xorg/util/modular Cloning into xorg/util/modular... remote: Counting objects: 2345, done. remote: Compressing objects: 100% (1214/1214), done. remote: Total 2345 (delta 1487), reused 1765 (delta 1125) Receiving objects: 100% (2345/2345), 1.04 MiB | 517 KiB/s, done. Resolving deltas: 100% (1487/1487), done. aster $ cd $HOME/xorg aster $ CONFFLAGS=\-\-with\-udev\-rules\-dir\=/opt/xorg/udev aster $ export CONFFLAGS aster $ cp -p util/modular/build.sh util/modular/build.sh_backup aster $ diff $HOME/build.sh util/modular/build.sh 858c858 < # build driver xf86-video-geode --- > build driver xf86-video-geode 874c874 < #build driver xf86-video-i740 --- > build driver xf86-video-i740 879,880c879,880 < #build driver xf86-video-apm < #build driver xf86-video-ark --- > build driver xf86-video-apm > build driver xf86-video-ark 893c893 < # build driver xf86-video-newport --- > build driver xf86-video-newport 897c897 < #build driver xf86-video-s3 --- > build driver xf86-video-s3 907c907 < #build driver xf86-video-vmware --- > build driver xf86-video-vmware aster $ cp -p $HOME/build.sh util/modular/build.sh Then fire away the build and await the results. I know that I am still compiling buckets of drivers I will never use, but I don't miss the cpu time at all .. so why not. On another note I am one of those poor sad souls that has piles of servers running all manner of revs of Solaris on all manner of weird hardware. Even this : titan-i386-SunOS5.8 $ uname -a SunOS titan 5.8 Generic_127722-03 i86pc i386 i86pc titan-i386-SunOS5.8 $ titan-i386-SunOS5.8 $ cat /etc/release Solaris 8 2/02 s28x_u7wos_08a INTEL Copyright 2002 Sun Microsystems, Inc. All Rights Reserved. Assembled 18 December 2001 titan-i386-SunOS5.8 $ titan-i386-SunOS5.8 $ psrinfo -v Status of virtual processor 0 as of: 01/26/13 05:55:55 on-line since 04/28/11 17:39:44. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 01/26/13 05:55:55 on-line since 04/28/11 17:39:48. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. How is that for bizarre old hardware ? I don't think anyone will ever know how many packages from Blastwave were compiled on that very machine and they went out to the world to run flawlessly all the way up to x86_64 based Solaris 10 servers. I always had a morbid curiosity with compiling awesome software on old bucket systems running the oldest UNIX kicking around. I just may try this process on old Solaris 8 sparc and i386 however I will need to get a version of git running first. Not very likely. Solaris 10 is far more likely to happen. In any case gents, this is moving along towards success wonderfully and maybe this weekend I will be able to fire up new X with a simple xterm and see it working. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
should I file a bug report ?
While going through the process of building X from git I run into plenty of little stoppages. Should I be filing bug reports on these or just comment them out and move on ? Dennis == == Processing module/component: "driver/xf86-video-sis" ==configuration options: --with-udev-rules-dir=/opt/xorg/udev Cloning into driver/xf86-video-sis... remote: Counting objects: 2232, done. remote: Compressing objects: 100% (652/652), done. remote: Total 2232 (delta 1735), reused 1991 (delta 1560) Receiving objects: 100% (2232/2232), 2.52 MiB | 1.29 MiB/s, done. Resolving deltas: 100% (1735/1735), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: configure.ac: tracing configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: libtoolize --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoconf configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: /usr/bin/autoheader configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg autoreconf: running: automake --add-missing --copy --no-force configure.ac:25: warning: AC_INIT: not a literal: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg configure.ac:41: installing `./config.guess' configure.ac:41: installing `./config.sub' configure.ac:34: installing `./install-sh' configure.ac:34: installing `./missing' src/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' configure: WARNING: unrecognized options: --with-udev-rules-dir checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking how to run the C preprocessor... gcc -std=gnu99 -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... no checking whether __INTEL_COMPILER is declared... no checking whether __SUNPRO_C is declared... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking if gcc -std=gnu99 supports -Werror=unknown-warning-option... no checking if gcc -std=gnu99 supports -Werror=unused-command-line-argument... no checking if gcc -std=gnu99 supports -Wall... yes checking if gcc -std=gnu99 supports -Wpointer-arith... yes checking if gcc -std=gnu99 supports -Wmissing-declarations... yes checking if gcc -std=gnu99 supports -Wformat=2... yes checking if gcc -std=gnu99 supports -Wstrict-prototypes... yes checking if gcc -std=gnu99 supports -Wmissing-prototypes... yes checking if gcc -std=gnu99 supports -Wnested-externs... yes checking if gcc -std=gnu99 supports -Wbad-function-cast... yes checking if gcc -std=gnu99 supports -Wold-style-definition... yes checking if gcc -std=gnu99 supports -Wdeclaration-after-statement... yes checking if gcc -std=gnu99 supports -Wunused... yes checking if gcc -std=gnu99 supports -Wuninitialized... yes checking if gcc -std=gnu99 supports -Wshad
yay, build complete. Now what ?
Firstly, let me say a gracious thank you to all who have listened, lurked, and fired excellent emails at me over the past two weeks to get this to a simple and very repeatable process. Should make a lovely article once I write it all up. Certainly Alan and Peter have shown awesome patience and forgiveness as I floundered forwards here. I will say, X is deep and wide. This morning I was just thrilled to see : aster $ rm -rf xorg/ aster $ rm -rf /opt/xorg/* aster $ mkdir -p xorg/util aster $ git clone git://anongit.freedesktop.org/git/xorg/util/modular xorg/util/modular Cloning into xorg/util/modular... remote: Counting objects: 2345, done. remote: Compressing objects: 100% (1214/1214), done. remote: Total 2345 (delta 1488), reused 1764 (delta 1125) Receiving objects: 100% (2345/2345), 1.04 MiB | 542 KiB/s, done. Resolving deltas: 100% (1488/1488), done. aster $ cd $HOME/xorg aster $ cd $HOME/xorg aster $ CONFFLAGS=\-\-with\-udev\-rules\-dir\=/opt/xorg/udev aster $ export CONFFLAGS aster $ cp -p util/modular/build.sh util/modular/build.sh_backup aster $ diff $HOME/build.sh util/modular/build.sh 858c858 < # build driver xf86-video-geode --- > build driver xf86-video-geode 874c874 < #build driver xf86-video-i740 --- > build driver xf86-video-i740 879,880c879,880 < #build driver xf86-video-apm < #build driver xf86-video-ark --- > build driver xf86-video-apm > build driver xf86-video-ark 893c893 < # build driver xf86-video-newport --- > build driver xf86-video-newport 897c897 < #build driver xf86-video-s3 --- > build driver xf86-video-s3 901c901 < #build driver xf86-video-sis --- > build driver xf86-video-sis 907c907 < #build driver xf86-video-vmware --- > build driver xf86-video-vmware aster $ cp -p $HOME/build.sh util/modular/build.sh aster $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg Building to run Linux / x86_64 () Sat Jan 26 17:24:56 EST 2013 == == Processing module/component: "util/macros" ==configuration options: --with-udev-rules-dir=/opt/xorg/udev . . . * * * * * * * hours of good stuff later * * * * * * * * * . . make[1]: Leaving directory `/home/dclarke/xorg/xkeyboard-config/man' make[1]: Entering directory `/home/dclarke/xorg/xkeyboard-config' make[2]: Entering directory `/home/dclarke/xorg/xkeyboard-config' make[2]: Nothing to be done for `install-exec-am'. test -z "/opt/xorg/share/pkgconfig" || /bin/mkdir -p "/opt/xorg/share/pkgconfig" /usr/bin/install -c -m 644 xkeyboard-config.pc '/opt/xorg/share/pkgconfig' make[2]: Leaving directory `/home/dclarke/xorg/xkeyboard-config' make[1]: Leaving directory `/home/dclarke/xorg/xkeyboard-config' Sat Jan 26 20:07:18 EST 2013 I see in /opt/xorg a nice pile of X magic along with some bizarre things under /opt/xorg/udev that I know I will have to deal with at some point. aster $ ls -lap /opt/xorg/ total 56 drwxr-xr-x 10 dclarke adbs 4096 Jan 26 19:18 ./ drwxr-xr-x 5 rootroot 4096 Jan 18 22:58 ../ drwxr-x--- 2 dclarke adbs 4096 Jan 26 20:06 bin/ drwxr-x--- 4 dclarke adbs 4096 Jan 26 19:54 etc/ drwxr-x--- 11 dclarke adbs 4096 Jan 26 19:16 include/ drwxr-x--- 8 dclarke adbs 20480 Jan 26 19:26 lib/ drwxr-x--- 2 dclarke adbs 4096 Jan 26 18:38 sbin/ drwxr-x--- 14 dclarke adbs 4096 Jan 26 20:07 share/ drwxr-x--- 2 dclarke adbs 4096 Jan 26 19:18 udev/ drwxr-x--- 3 dclarke adbs 4096 Jan 26 17:24 var/ aster $ file /opt/xorg/bin/Xorg /opt/xorg/bin/Xorg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped aster $ aster $ readelf -hlStd /opt/xorg/bin/Xorg ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x439060 Start of program headers: 64 (bytes into file) Start of section headers: 9044600 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 53 Section header string table index: 50 Section Headers: [Nr] Name Type Address OffsetLink Size EntSize Info Align Flags [ 0] NULL 0
Re: yay, build complete. Now what ?
> > Can I simply fire this up in the VMware virtual machine with a > barebone xinit ? > > yes. just make sure you set your PATH etc so you start the new bits, > not the > system-wide ones. Well that is not a problem, there is no system wide X at all on this vmware machine. > > aster $ ldd /opt/xorg/bin/xlsatoms > > linux-vdso.so.1 => (0x7fff5c59e000) > > libxcb.so.1 => not found > > libc.so.6 => /lib/libc.so.6 (0x7f3f8612e000) > > /lib64/ld-linux-x86-64.so.2 (0x7f3f86496000) > > > > set LD_LIBRARY_PATH to $prefix/lib That there looks like a build error. One should never, ever, need to specify LD_IBRARY_PATH in order to run a binary in some location like /opt/foo. The RPATH *should* be in the binary itself. Otherwise there is no promise that the binary will operate as expected. Dennis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: yay, build complete. Now what ?
> > That there looks like a build error. One should never, ever, need > to specify LD_IBRARY_PATH in order to run a binary in some location > like /opt/foo. The RPATH *should* be in the binary itself. > > > > Otherwise there is no promise that the binary will operate as > expected. > > fwiw, both debian and fedora discourage the use of RPATH > > http://wiki.debian.org/RpathIssue > http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath That may be, and 10,000 lemmings may run off a cliff but I will stop and say "that there, right there, is wrong". I think I'll look into the build scripts and see why the RPATH data is missing and why perfectly well built binaries don't know where to look to find the correct shared libs that are needed for them. Rather, the exec process and the dynamic run time linker should not ever need to ask a user where to find a foo.so. Otherwise I could hand craft a foo.so and stick it into my own $HOME/lib and wreck havoc perhaps? I should give that a try really. dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: yay, build complete. Now what ?
> > > set LD_LIBRARY_PATH to $prefix/lib > > > > That there looks like a build error. One should never, ever, need > to specify LD_IBRARY_PATH in order to run a binary in some location > like /opt/foo. The RPATH *should* be in the binary itself. > > > > Otherwise there is no promise that the binary will operate as > expected. > > fwiw, both debian and fedora discourage the use of RPATH > > http://wiki.debian.org/RpathIssue > http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath > For no better reason than "because I could" I went back and did a rebuild but this time with an RPATH of /opt/xorg/lib in the output bins : aster $ readelf -d /opt/xorg/bin/xlsatoms Dynamic section at offset 0x1a80 contains 23 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libxcb.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x000f (RPATH) Library rpath: [/opt/xorg/lib] 0x000c (INIT) 0x400a70 0x000d (FINI) 0x4016b8 0x0004 (HASH) 0x400260 0x6ef5 (GNU_HASH) 0x400328 0x0005 (STRTAB) 0x400648 0x0006 (SYMTAB) 0x400360 0x000a (STRSZ) 394 (bytes) 0x000b (SYMENT) 24 (bytes) 0x0015 (DEBUG) 0x0 0x0003 (PLTGOT) 0x601c50 0x0002 (PLTRELSZ) 528 (bytes) 0x0014 (PLTREL) RELA 0x0017 (JMPREL) 0x400860 0x0007 (RELA) 0x400830 0x0008 (RELASZ) 48 (bytes) 0x0009 (RELAENT)24 (bytes) 0x6ffe (VERNEED)0x400810 0x6fff (VERNEEDNUM) 1 0x6ff0 (VERSYM) 0x4007d2 0x (NULL) 0x0 The result is that LD_LIBRARY_PATH is not required and there is no way for this bin to accidentally pick up a system provided lib. I guess there may be a way around that, but it would mean the user did something on purpose to make that happen. aster $ ldd /opt/xorg/bin/xlsatoms linux-vdso.so.1 => (0x7fff66b44000) libxcb.so.1 => /opt/xorg/lib/libxcb.so.1 (0x7f0d4ddc8000) libc.so.6 => /lib/libc.so.6 (0x7f0d4da62000) libXau.so.6 => /opt/xorg/lib/libXau.so.6 (0x7f0d4d85e000) libXdmcp.so.6 => /opt/xorg/lib/libXdmcp.so.6 (0x7f0d4d658000) /lib64/ld-linux-x86-64.so.2 (0x7f0d4dff2000) dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xorg-server 1.14.0
says Error 503 Service Unavailable I wonder if anyone within the Xorg project has given some thought to just outright replacement of that web server with something else? dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Open Shared Memory and Render Pictures
On 08/05/2016 12:38 PM, Ilya Anfimov wrote: X Window Sys- tem Protocol X Consortium Standard. For those that want to know : X Window System Protocol X Consortium Standard. https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.pdf ___ 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
new dependency for libtizcore required for mesa?
Dear X-types: Is there a new minimal dependency list? While running a build I see this : == == Processing: "mesa/mesa" ==configuration options: Cloning into 'mesa/mesa'... remote: Counting objects: 1006300, done. remote: Compressing objects: 100% (150111/150111), done. remote: Total 1006300 (delta 859623), reused 996318 (delta 851198) Receiving objects: 100% (1006300/1006300), 175.92 MiB | 5.00 MiB/s, done. Resolving deltas: 100% (859623/859623), done. Checking connectivity... done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/xorg/share/aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `bin'. libtoolize: copying file `bin/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' autoreconf: running: /usr/bin/autoconf --force autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --copy --force-missing configure.ac:61: installing 'bin/ar-lib' configure.ac:61: installing 'bin/compile' configure.ac:45: installing 'bin/config.guess' configure.ac:45: installing 'bin/config.sub' configure.ac:46: installing 'bin/install-sh' configure.ac:46: installing 'bin/missing' src/Makefile.am: installing 'bin/depcomp' parallel-tests: installing 'bin/test-driver' autoreconf: Leaving directory `.' checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether UID '16411' is supported by ustar format... yes checking whether GID '20002' is supported by ustar format... yes checking how to create a ustar tar archive... gnutar checking whether make supports nested variables... (cached) yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking for ar... ar checking the archiver (ar) interface... ar checking how to run the C preprocessor... gcc -E checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking whether gcc understands -c and -o together... (cached) yes checking dependency style of gcc... (cached) gcc3 checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for grep that handles long lines and -e... /bin/grep checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking dependency style of gcc... gcc3 checking for GNU make... make checking for python2.7... python2.7 checking for a sed that does not truncate output... /bin/sed checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking how to print strings... printf checking for a sed that does not truncate output... (cached) /bin/sed checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to ass
Re: new dependency for libtizcore required for mesa?
On 6/7/18 10:44 AM, Michal Srb wrote: On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote: Package libtizcore was not found in the pkg-config search path. Perhaps you should add the directory containing `libtizcore.pc' to the PKG_CONFIG_PATH environment variable No package 'libtizcore' found This is not a problem. It seems to be optional requirement. I see the same message in my build log. checking for RADEON... yes checking for RADEON... yes configure: error: LLVM 3.9.0 or newer is required for r600 This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find one. Ah .. oops. Thanks for the reply and I should look closer before jumping on the "what?" button. How very odd : root@xorg:~# apt-get install llvm Reading package lists... Done Building dependency tree Reading state information... Done llvm is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. root@xorg:~# Yet my old build process fails looking for LLVM? The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even in the debian package list for that matter. Fine. However llvm is definately installed and has been for a long while. I am just doing the usual per the instructions at : Testing X servers from git http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html That has worked since about 2013 however it has been a while since I tried. Something odd here ... not sure what it is yet. 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: new dependency for libtizcore required for mesa?
On 6/7/18 11:47 AM, Braiam Peguero wrote: On Thu, Jun 7, 2018 at 11:06 AM, Dennis Clarke <mailto:dcla...@blastwave.org>> wrote: On 6/7/18 10:44 AM, Michal Srb wrote: On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote: Package libtizcore was not found in the pkg-config search path. Perhaps you should add the directory containing `libtizcore.pc' to the PKG_CONFIG_PATH environment variable No package 'libtizcore' found This is not a problem. It seems to be optional requirement. I see the same message in my build log. checking for RADEON... yes checking for RADEON... yes configure: error: LLVM 3.9.0 or newer is required for r600 This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find one. Ah .. oops. Thanks for the reply and I should look closer before jumping on the "what?" button. How very odd : root@xorg:~# apt-get install llvm Reading package lists... Done Building dependency tree Reading state information... Done llvm is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. root@xorg:~# Yet my old build process fails looking for LLVM? The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even in the debian package list for that matter. Fine. However llvm is definately installed and has been for a long while. I am just doing the usual per the instructions at : Testing X servers from git http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html <http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html> That has worked since about 2013 however it has been a while since I tried. Something odd here ... not sure what it is yet. Dennis ___ xorg@lists.x.org <mailto:xorg@lists.x.org>: X.Org support Archives: http://lists.freedesktop.org/archives/xorg <http://lists.freedesktop.org/archives/xorg> Info: https://lists.x.org/mailman/listinfo/xorg <https://lists.x.org/mailman/listinfo/xorg> Your subscription address: %(user_address)s Have you checked that the version installed of llvm is >= 3.9.0? Debian Stretch by default install 3.8, while you can have 3.9 if you install the llvm-toolchain-3.9 package. That should be enough. The issue is definately version. This is an older debian 8 system and thus : root@xorg:~# apt-get install llvm-3.5 llvm-3.5-dev llvm-3.5-runtime llvm-3.5-examples llvm-3.5-doc llvm-3.5-tools Reading package lists... Done Building dependency tree Reading state information... Done llvm-3.5 is already the newest version. llvm-3.5 set to manually installed. llvm-3.5-dev is already the newest version. llvm-3.5-dev set to manually installed. llvm-3.5-runtime is already the newest version. llvm-3.5-runtime set to manually installed. The following extra packages will be installed: libjs-underscore The following NEW packages will be installed: libjs-underscore llvm-3.5-doc llvm-3.5-examples llvm-3.5-tools 0 upgraded, 4 newly installed, 0 to remove and 5 not upgraded. Need to get 1,847 kB of archives. After this operation, 10.6 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.ca.debian.org/debian/ jessie/main libjs-underscore all 1.7.0~dfsg-1 [49.9 kB] Get:2 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-doc all 1:3.5-10 [1,461 kB] Get:3 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-examples all 1:3.5-10 [181 kB] Get:4 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-tools amd64 1:3.5-10 [154 kB] Fetched 1,847 kB in 3s (598 kB/s) Selecting previously unselected package libjs-underscore. (Reading database ... 155535 files and directories currently installed.) Preparing to unpack .../libjs-underscore_1.7.0~dfsg-1_all.deb ... Unpacking libjs-underscore (1.7.0~dfsg-1) ... Selecting previously unselected package llvm-3.5-doc. Preparing to unpack .../llvm-3.5-doc_1%3a3.5-10_all.deb ... Unpacking llvm-3.5-doc (1:3.5-10) ... Selecting previously unselected package llvm-3.5-examples. Preparing to unpack .../llvm-3.5-examples_1%3a3.5-10_all.deb ... Unpacking llvm-3.5-examples (1:3.5-10) ... Selecting previously unselected package llvm-3.5-tools. Preparing to unpack .../llvm-3.5-tools_1%3a3.5-10_amd64.deb ... Unpacking llvm-3.5-tools (1:3.5-10) ... Setting up libjs-underscore (1.7.0~dfsg-1) ... Setting up llvm-3.5-doc (1:3.5-10) ... Setting up llvm-3.5-examples (1:3.5-10) ... Setting up llvm-3.5-tools (1:3.5-10) ... root@xorg:~# exit logout xorg $ xorg $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg Building to run Linux / x86_64 () Thu Jun 7 16:27:03 GMT 2018 Skipping util/macros... Skipping font/util... Skipping doc/xorg-sgml-docto
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
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" ?
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.
Re: Xorg VRAM leak because of Qt/OpenGL Application
On 07/01/2018 10:11 PM, Mathieu Westphal wrote:
Hello list,
I am working on a complex Qt/OpenGL Application.
Xorg starts leaking in VRAM when i'm using the application and never
release the memory, until I restart X of course.
$ nvidia-smi
I think you are looking at output from an nvidia tool and not memory
for the system and processes as a whole.
The version of Xorg does not matter, tested a few.
The version of the driver does not matter, as long as it's nvidia,
tested 340, 384, 390
Using 384.98 here. Very stable.
However I think you are looking at output from nvidia-smi here and not
actual process data from the /proc/$PID/stat where $PID is the pid of
your X process.
For example :
sed$ ps -ef | grep "bin\/X"
root 2488 2429 3 Jun15 tty1 13:32:18 /usr/bin/X :0
-background none -noreset -audit 4 -verbose -auth
/run/gdm/auth-for-gdm-TVlXTy/database -seat seat0 -nolisten tcp vt1
sed$ cat /proc/2488/stat
2488 (X) S 2429 2488 2488 1025 2488 4202752 15866906 3576 170 0 407
762600 6 3 20 0 2 0 4079 569253888 46342 18446744073709551615 1 1 0 0 0
0 0 3149824 1098933967 18446744073709551615 0 0 17 1 0 0 1192 0 0 0 0 0
0 0 0 0 0
sed$
The actual rss ( Resident Set Size ) is what you should have a look at.
According to PROC(5) you can get that from "stat" under /proc for a
given pid. That is field 24 here :
sed$ cat /proc/2488/stat | awk '{ print $24 }'
46342
These are pages of memory and that reports :
Resident Set Size: number of pages the process has in real memory.
This is just the pages which count toward text, data, or stack
space. This does not include pages which have not been
demand-loaded in, or which are swapped out.
Your page size may be 8192 bytes or 4096 bytes or something else:
sed$ getconf -a | grep "PAGE"
PAGESIZE 4096
PAGE_SIZE 4096
_AVPHYS_PAGES 95456
_PHYS_PAGES8187584
nix$ getconf -a | grep "PAGE"
PAGESIZE 65536
PAGE_SIZE 65536
_AVPHYS_PAGES 89121
_PHYS_PAGES95356
So while the nvidia-smi tool may seem to tell you that a process needs
more memory in the GPU it isn't telling you much about the process
running on your system.
sed$ nvidia-smi -q -d POWER,TEMPERATURE,PIDS
==NVSMI LOG==
Timestamp : Mon Jul 2 17:17:10 2018
Driver Version : 384.98
Attached GPUs : 1
GPU :86:00.0
Temperature
GPU Current Temp: 40 C
GPU Shutdown Temp : 102 C
GPU Slowdown Temp : 97 C
GPU Max Operating Temp : 80 C
Memory Current Temp : N/A
Memory Max Operating Temp : N/A
Power Readings
Power Management: Supported
Power Draw : 16.28 W
Power Limit : 110.00 W
Default Power Limit : 110.00 W
Enforced Power Limit: 110.00 W
Min Power Limit : 100.00 W
Max Power Limit : 130.00 W
Power Samples
Duration: N/A
Number of Samples : N/A
Max : N/A
Min : N/A
Avg : N/A
Processes
Process ID : 2488
Type: G
Name: /usr/bin/X
Used GPU Memory : 218 MiB
Process ID : 13211
Type: G
Name: /opt/firefox/firefox
Used GPU Memory : 21 MiB
Process ID : 32110
Type: G
Name: /opt/firefox/firefox
Used GPU Memory : 21 MiB
Process ID : 32668
Type: G
Name: /opt/firefox/firefox
Used GPU Memory : 2 MiB
sed$
Cute .. but not your actual process memory usage in your system.
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: ANN: xterm-335
On 08/14/2018 10:03 PM, Thomas Dickey wrote: Files: ftp://ftp.invisible-island.net/xterm/current/xterm-335.tgz ftp://ftp.invisible-island.net/xterm/current/xterm-335.tgz.asc ftp://ftp.invisible-island.net/xterm/patches/xterm-335.patch.gz ftp://ftp.invisible-island.net/xterm/patches/xterm-335.patch.gz.asc ftp://ftp.invisible-island.net/xterm/xterm-335.tgz ftp://ftp.invisible-island.net/xterm/xterm-335.tgz.asc Patch #335 - 2018/08/14 * add colorInnerBorder resource to make a change from patch #334 configurable (reports by H Merijn Brand, Gabriele Balducci). That was fast ... I had not yet even unpacked 334 from this weekend ;-) 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: One (Intel) GPU multiseat without Xephyr/Xnest, with a Xorg server per output
On 09/20/2018 02:46 AM, Chris Wilson wrote: Quoting Troll Berserker (2018-09-18 16:28:02) Is it possible? man 4 intel, search for ZaphodHeads -Chris ___ 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 https://www.x.org/archive/current/doc/man/man4/intel.4.xhtml Option "ZaphodHeads" "string" Specify the randr output(s) to use with zaphod mode for a particular driver instance. If you this option you must use it with all instances of the driver For example: Option "ZaphodHeads" "LVDS1,VGA1" Will assign xrandr outputs LVDS1 and VGA0 to this instance of the driver. dc ___ 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
XDrawPoint(s) etc MT safe?
Dear Xorg : Something I had not thought of came up today. Could multiple threads call XDrawPoint() and then XFlush() ? Suppose sixteen threads are dispatched to do some foo and each of them utters some XDrawPoint() calls and then XFlush()? Is that remotely thread safe? 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: XDrawPoint(s) etc MT safe?
On 10/16/2018 09:58 PM, Dennis Clarke wrote: Dear Xorg : Something I had not thought of came up today. Could multiple threads call XDrawPoint() and then XFlush() ? Suppose sixteen threads are dispatched to do some foo and each of them utters some XDrawPoint() calls and then XFlush()? Is that remotely thread safe? Sorry, assume XInitThreads() is in place. Am I stuck with using XLockDisplay() and XUnlockDisplay() and really multiple threads can not really do work simultaneously. That is the question. 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: XDrawPoint(s) etc MT safe?
On 10/17/2018 05:37 AM, Carsten Haitzler (The Rasterman) wrote: On Tue, 16 Oct 2018 22:04:15 -0400 Dennis Clarke said: On 10/16/2018 09:58 PM, Dennis Clarke wrote: Dear Xorg : Something I had not thought of came up today. Could multiple threads call XDrawPoint() and then XFlush() ? Suppose sixteen threads are dispatched to do some foo and each of them utters some XDrawPoint() calls and then XFlush()? Is that remotely thread safe? Sorry, assume XInitThreads() is in place. Am I stuck with using XLockDisplay() and XUnlockDisplay() and really multiple threads can not really do work simultaneously. That is the question. xinitthreads should make anything in xlib "mt safe".. OKay .. good enough for me .. for now at least. but ... how can you sensibly have 2 threads draw to the same target in any way ... unless you very specifically avoid ever overdrawing ... Exactly that way. 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: XDrawPoint(s) etc MT safe?
Something I had not thought of came up today. Could multiple threads call XDrawPoint() and then XFlush() ? Suppose sixteen threads are dispatched to do some foo and each of them utters some XDrawPoint() calls and then XFlush()? Is that remotely thread safe? Sorry, assume XInitThreads() is in place. Am I stuck with using XLockDisplay() and XUnlockDisplay() and really multiple threads can not really do work simultaneously. That is the question. Individual Xlib function calls are thread-safe, in that they internally lock the Display while they're running to avoid multiple threads modifying the Display state. Note how the first thing XDrawPoint does is call LockDisplay: https://gitlab.freedesktop.org/xorg/lib/libx11/blob/master/src/DrPoint.c#L36 Beauty. So I don't really need to call XLockDisplay or XUnlockDisplay inside any given thread. Looks redundant. That helps. So if you had two threads calling XDrawPoint in parallel, the second one would block at that LockDisplay until the first one was done. Perfect ... thank you! You only need XLockDisplay() if you're trying to establish an atomic sequence of actions with respect to your sibling threads. For example, if one thread was doing XQueryTree in a loop, and another was creating and destroying windows, you could end up with a sequence like: Thread A creates window 1 Thread B queries for the root window's children, learns window 1 Thread A destroys window 1 Thread B queries for window 1's children, gets BadWindow ah yes .. well I hope to never have a thread do anything like that. Thank 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: XRender / XComposite Documentation
On 10/30/2018 10:35 AM, Adam Jackson wrote: On Tue, 2018-10-30 at 02:06 -0700, x...@pengaru.com wrote: On Mon, Oct 29, 2018 at 04:04:08PM -0400, Patrick Herbst wrote: Hello, I'm desperately trying to find documentation on these extensions. Can someone point me in the right direction? Am I missing something? Any pointers? https://www.x.org/archive/X11R7.5/doc/libXrender/libXrender.txt https://www.x.org/archive/X11R7.5/doc/renderproto/renderproto.txt https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt Those are a bit dated. The current versions can be found in gitlab: https://gitlab.freedesktop.org/xorg/lib/libxrender/blob/master/doc/libXrender.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/compositeproto.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/renderprotoproto.txt - ajax I don't think your average user will ever find that. Best to go to the actual release site : https://www.x.org/releases/X11R7.7/doc/libXrender/libXrender.txt dc ___ 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: XRender / XComposite Documentation
I don't think your average user will ever find that. Best to go to the actual release site : https://www.x.org/releases/X11R7.7/doc/libXrender/libXrender.txt But that's 6 years old now, since we stopped doing X11R7.* releases. Ajax's links are the most up-to-date for people today. I agree ... but who will ever find those ? Stick them on the main site if they are up to date. dc ___ 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: XOrg in Debian10/Buster not usable with AMD Duron / Matrox G400
On 7/16/19 5:05 AM, Markus Hiereth wrote: Hello, I updated my PC with Debian 10 which contains the package xserver-xorg-core 2:1.20.4-1. I also have a very old machine still running fine. It also has a Matrox graphics PCI card and one must compile the driver for that from the sources. At least that was what I had to do. Otherwise it works great. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux support ___ 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
error: possibly undefined macro: AC_CHECK_FILE in doc/xorg-docs
While it has been a while since I tried to compile all of Xorg from sources it seemed like a worth while experiment. On a debian stable x86_64 system with the usual pile of development pkgs installed I tried : styx$ styx$ rm -rf /opt/bw/build/xorg/ styx$ rm -rf /opt/bw/xorg/* styx$ mkdir -p /opt/bw/build/xorg/util styx$ cd /opt/bw/build styx$ git clone git://anongit.freedesktop.org/git/xorg/util/modular xorg/util/modular Cloning into 'xorg/util/modular'... remote: Counting objects: 2716, done. remote: Compressing objects: 100% (1052/1052), done. remote: Total 2716 (delta 1776), reused 2528 (delta 1658) Receiving objects: 100% (2716/2716), 590.72 KiB | 994.00 KiB/s, done. Resolving deltas: 100% (1776/1776), done. styx$ cd xorg/ styx$ export PKG_CONFIG_PATH=/opt/bw/xorg/lib/pkgconfig:/opt/bw/xorg/share/pkgconfig:/opt/bw/lib:/usr/lib/x86_64-linux-gnu/pkgconfig styx$ export LD_LIBRARY_PATH=/opt/bw/xorg/lib:/opt/bw/lib styx$ export PATH=/opt/bw/xorg/bin:/opt/bw/bin:/opt/bw/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin styx$ cd /opt/bw/build/xorg styx$ ./util/modular/build.sh --clone --autoresume built.modules /opt/bw/xorg == == Processing: "doc/xorg-docs" ==configuration options: Cloning into 'doc/xorg-docs'... remote: Counting objects: 3820, done. remote: Compressing objects: 100% (1399/1399), done. remote: Total 3820 (delta 2349), reused 3716 (delta 2279) Receiving objects: 100% (3820/3820), 14.99 MiB | 4.73 MiB/s, done. Resolving deltas: 100% (2349/2349), done. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I /opt/bw/xorg/share/aclocal -I /opt/bw/xorg/share/aclocal configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd /opt/bw/xorg/share/aclocal/xorg-macros.m4:1844: XORG_INSTALL is expanded from... /opt/bw/xorg/share/aclocal/xorg-macros.m4:1824: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: configure.ac: tracing configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2979: XORG_INSTALL is expanded from... aclocal.m4:2959: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd aclocal.m4:2979: XORG_INSTALL is expanded from... aclocal.m4:2959: XORG_DEFAULT_OPTIONS is expanded from... configure.ac:38: the top level configure:11098: error: possibly undefined macro: m4_ifval If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:11102: error: possibly undefined macro: AC_CHECK_FILE autoreconf: /usr/bin/autoconf failed with exit status: 1 build.sh: "./autogen.sh" failed on doc/xorg-docs build.sh: error processing: "doc/xorg-docs" styx$ Am I missing something obvious ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: error: possibly undefined macro: AC_CHECK_FILE in doc/xorg-docs
On 8/26/19 4:01 PM, Alan Coopersmith wrote: On 8/25/19 9:27 PM, Dennis Clarke wrote: configure.ac:38: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd That sounds like you're missing pkg.m4 from pkg-config. configure:11098: error: possibly undefined macro: m4_ifval If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:11102: error: possibly undefined macro: AC_CHECK_FILE Those come from autoconf itself - either the lack of the other definitions left the m4 parser in a state it couldn't recover from, or your autoconf installation is unwell. Thank you Alan for the help! Good to see you are still out there doing all things X-like. I found the issue and had to install a few things into Debian stable and now I recall the process from years ago. It is very much like pushing a little red wagon up a hill. When the wagon hits a stone and stops I have to deal with the little stone and then go back to pushing up the hill until all the little stones have been cleared out of the way. At the moment the show stopper is : Checking for function "dlopen" : NO Library dl found: YES Checking for function "dladdr" with dependency -ldl: YES Checking for function "dl_iterate_phdr" : YES Checking for function "clock_gettime" : YES Dependency zlib found: YES 1.2.11 Dependency threads found: YES Checking for function "pthread_setaffinity_np" with dependency threads: YES Checking for function "pthread_setaffinity_np" with dependency threads: NO Dependency expat found: YES 2.2.6 Library m found: YES Message: libdrm 2.4.99 needed because amdgpu has the highest requirement Dependency libdrm_intel found: YES 2.4.99 Dependency libdrm_amdgpu found: YES 2.4.99 Dependency libdrm_radeon found: YES 2.4.99 Dependency libdrm_nouveau found: YES 2.4.99 Dependency libdrm found: YES 2.4.99 Found llvm-config '7.0.1' NO (needed >= 8.0.0 ) Dependency LLVM found: NO (tried config-tool) meson.build:1261:2: ERROR: Dependency "llvm" not found, tried config-tool A full log can be found at /opt/xorg/build/xorg/mesa/mesa/builddir/meson-logs/meson-log.txt build.sh: "meson" failed on mesa/mesa build.sh: error processing: "mesa/mesa" styx$ However : styx$ dpkg-query -l | grep 'llvm' | cut -c1-71 ii libllvm7:amd641:7.0.1-8 ii llvm 1:7.0-47 ii llvm-71:7.0.1-8 ii llvm-7-dev1:7.0.1-8 ii llvm-7-runtime1:7.0.1-8 ii llvm-dev 1:7.0-47 ii llvm-runtime 1:7.0-47 styx$ So what is this stone in the path this time as I can not figure it out. 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: error: possibly undefined macro: AC_CHECK_FILE in doc/xorg-docs
On 8/28/19 6:10 PM, Alan Coopersmith wrote: On 8/28/19 3:02 PM, Dennis Clarke wrote: Found llvm-config '7.0.1' NO (needed >= 8.0.0 ) I've not tried building Mesa with meson yet, but that reads like it only found version 7 of LLVM, but needs at least version 8. (Since Mesa implements LLVM based compilers to build code to run on the various GPUs it supports, it's very closely tied to the version of LLVM needed to build with.) Wow, that is a big problem. There is no LLVM 8 in Debian Stable release. I would hate to have to build that from source and then deal with Xorg also. However maybe that is the only way. OKay, thank you for the help and I will look for a back-port perhaps or maybe even face the sources. 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: Running X with 2 separate displays on Debian 10 (Buster)
As far as I'm concerned there is currently no xorg.conf configuration file that would store any X config, everything comes from the "auto config" Thanks in advance Did you get any reply on this at all ? 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: ANN: xterm-356
uments -L/usr/local/lib -L/usr/local/lib -o xterm button.o cachedGCs.o charproc.o charsets.o cursor.o data.o doublechr.o fontutils.o input.o linedata.o main.o menu.o misc.o print.o ptydata.o scrollback.o screen.o scrollbar.o tabs.o util.o version.o xstrings.o xtermcap.o VTPrsTbl.o TekPrsTbl.o Tekproc.o charclass.o precompose.o wcwidth.o html.o svg.o -lutil -lXaw -lXmu -lXt -lSM -lICE -lXext -lXt -lX11 -lSM -lICE testing if -lutil is needed ...yes testing if -lXaw is needed ...yes testing if -lXmu is needed ...yes testing if -lXt is needed ...yes testing if -lSM is needed ...yes testing if -lICE is needed ...yes testing if -lXext is needed ...yes testing if -lXt is needed ...yes testing if -lX11 is needed ...yes testing if -lSM is needed ...yes testing if -lICE is needed ...yes ld: error: undefined symbol: tgetstr >>> referenced by xtermcap.c:247 (./xtermcap.c:247) >>> xtermcap.o:(loadTermcapStrings) ld: error: undefined symbol: tgetent >>> referenced by xtermcap.c:509 (./xtermcap.c:509) >>> xtermcap.o:(get_termcap) ld: error: undefined symbol: tgetstr >>> referenced by xtermcap.c:556 (./xtermcap.c:556) >>> xtermcap.o:(get_tcap_erase) ld: error: undefined symbol: tgetent >>> referenced by xtermcap.c:614 (./xtermcap.c:614) >>> xtermcap.o:(set_termcap) cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake: *** [Makefile:196: xterm] Error 1 real 7.20 user 5.30 sys 1.90 vesta$ Any input would be appreciated here. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: ANN: xterm-356
On 5/11/20 8:51 PM, Thomas Dickey wrote: On Mon, May 11, 2020 at 05:10:27PM +, Dennis Clarke wrote: On 5/3/20 12:56 AM, Thomas Dickey wrote: Patch #356 - 2020/05/02 * revise fix for Debian #954730, which interfered with wheel mouse events (report by Gabriele Balducci). I ran into problems on FreeBSD 12.1 wherein I was surprised to see this error during the compile stage : I did test with FreeBSD 12.1, but didn't run into this problem. I don't recall making any recent change in this area, either. Sorry for the delay and late reply. I will look into this again today with FreeBSD 12.1 : vesta$ vesta$ freebsd-version 12.1-RELEASE-p4 vesta$ uname -apKU FreeBSD vesta 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC amd64 amd64 1201000 1201000 vesta$ Also Red Hat Enterprise Linux 7.4 : b$ b$ uname -a Linux boe13.genunix.com 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux b$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.4 (Maipo) b$ Possibly Debian on IBM Power9 ppc64le if I can get to it. misc.o print.o ptydata.o scrollback.o screen.o scrollbar.o tabs.o util.o version.o xstrings.o xtermcap.o VTPrsTbl.o TekPrsTbl.o Tekproc.o charclass.o precompose.o wcwidth.o html.o svg.o -lutil -lXaw -lXmu -lXt -lSM -lICE -lXext -lXpm -lXt -lX11 -lSM -lICE ... my generated makefile does this: /bin/sh ./plink.sh gcc -g -O2 -pthread -pthread -pthread -pthread -pthread -o resize resize.o version.o xstrings.o -lXft -L/usr/local/lib -lfontconfig -lfreetype -lXext -lutil -lXaw7 -L/usr/local/lib -lXmu -lXinerama -lXpm -L/usr/local/lib -lXt -lX11 -lSM -lICE -ltermcap My configure script said this: checking if we want full tgetent function... yes checking for full tgetent function... -ltermcap checking for termcap.h... yes ld: error: undefined symbol: tgetstr referenced by xtermcap.c:247 (./xtermcap.c:247) xtermcap.o:(loadTermcapStrings) I'd suppose that the configure script didn't succeed in the check for libtermcap -- which is actually a symbolic link to ncurses: $ ls -l /usr/lib/libtermc* lrwxr-xr-x 1 root wheel 12 Dec 6 2018 /usr/lib/libtermcap.a -> libncurses.a lrwxr-xr-x 1 root wheel 13 Dec 6 2018 /usr/lib/libtermcap.so -> libncurses.so lrwxr-xr-x 1 root wheel 14 Dec 6 2018 /usr/lib/libtermcap_p.a -> libncurses_p.a lrwxr-xr-x 1 root wheel 13 Dec 6 2018 /usr/lib/libtermcapw.a -> libncursesw.a lrwxr-xr-x 1 root wheel 14 Dec 6 2018 /usr/lib/libtermcapw.so -> libncursesw.so lrwxr-xr-x 1 root wheel 15 Dec 6 2018 /usr/lib/libtermcapw_p.a -> libncursesw_p.a To be clear I was trying to compile with strict C99 and also with XOPEN_SOURCE defined at '600' which should keep me safely within the POSIX "IEEE Std 1003.1, 2004 Edition" world. Usually works fine. usually :-) My compiler was the typical system LLVM/Clang version in FreeBSD : vesta$ cc --version FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1) Target: x86_64-unknown-freebsd12.1 Thread model: posix InstalledDir: /usr/bin vesta$ With some rather strict flags and verbose warnings : CC=/usr/bin/cc CFLAGS=-std=iso9899:1999 -pedantic -pedantic-errors -Weverything -Wno-reserved-id-macro -Wno-missing-prototypes -m64 -g -O0 -fno-fast-math -fno-builtin CPPFLAGS=-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -D_XOPEN_SOURCE=600 CXX=/usr/bin/c++ CXXFLAGS=-m64 -g -O0 -fno-fast-math -fno-builtin -Wl,-rpath=/opt/bw/lib I have also tried various gymnastics with the FreeBSD system ld linker which appears to be the LLVM linker ld.lld. Configure always runs clean and outputs a strange message as the last line but not an error state : ...yes - error-handling is a problem, because (when I can), I just report the problem in the configure script, and try to produce something that works. checking if POSIX saved-ids are supported... yes checking if we want full tgetent function... yes checking for full tgetent function... no checking for partial tgetent function... no well...,. the problem is this: the last test for tgetent fails because there's no prototype (cannot compile) rather than the intended runtime check. The existence check (for tgetent) succeeds since that just uses "nm". The original BSD termcap had no headers for declaring prototypes. That's only done in later stuff. You'll notice a termcap.h file, which is from ncurses. I don't check for that by default because a real termcap implementation (other than the GNU termcap which Slackware still uses...) hasn't got that header. I will take a look into FreeBSD ports and see how they handle XTerm : vesta$ cd xterm vesta$ pwd /usr/ports/x11/xterm vesta$ ls -lap total 48 drwxr-xr-x3 root wheel 8 Mar 17 23:56 ./ drwxr-xr-x 549 root wheel 550 Mar 17 23:56 ../ -rw-r-
Re: Suggestion for Xorg / about middle-mouse click pasting
On 7/30/20 6:39 PM, Elie Goldman Smith wrote: > Countless people on forums ... Also they are not the source code nor would I rely on what countless people say on just about any matter whatsoever. I am not sure when the horrific "popular is correct" logic became almost defacto pure truth but I reject it. I am certain I am not alone but I also do not have a mathematical proof handy to refute the "popular is correct" notion. At least not yet. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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
