[PATCH]: Fix GLX crashes on RISC cpus.

pcpa at mandriva.com.br pcpa at mandriva.com.br
Sat Dec 29 08:08:17 PST 2007


Quoting Alan Coopersmith <Alan.Coopersmith at Sun.COM>:

> Paulo Cesar Pereira de Andrade wrote:
>>   Good to know :-)  Now it is only required to have people to work on it.
>> Basically a work that very few people consider important or even notice,
>> and that usually doesn't produce copyrightable work. Unfortunately AFAIK,
>> most "janitors" on OSS are "good samaritans" that work on their free
>> time.
>
> I do some of that at work while waiting for other builds to finish or when
> otherwise procrastinating.   I've left a bunch of the janitorial bugs alone
> so they can serve as introductory work for new developers getting into the
> code, but apply patches from bugzilla and the like.

  I understand. Maybe I am talking about "advanced janitors" (I am not
saying you are not an "advanced janitor") :-) i.e. people that doesn't
write new features, but will do things like git bitsect and test different
versions, invest several hours in debugging sessions, doing things like
"ErrorF debug" until finding some wrong code, and then inspecting variables,
stack, etc (this requires a lot of time invested with close to zero return,
personally, I have sastisfaction finding and fixing obscure bugs, but I
am weird :-).
  I used to do this kind of thing for XFree86 and other projects, but
nowadays I have my own personal projects, etc...

>> kind of problems with duplicated symbols. And there isn't a clear way to
>> find out dependencies or proper "build order" in modular X org.
>
> "less util/modular/build.sh" has always worked for me to find proper
> build order.

  I am using a different approach. I am sorry I don't have all scripts
complete, neither know exactly what approach was used to generate
util/modular scripts (but a review should not hurt :-) but the current
code is like this:

o search all .deps directories
o create a <module>.deps file where contents are basically
  --
  <dependency>:<dependency-mtime>  # rpm package of file
  --

Example of first lines of xorg-server.deps:
--
/usr/include/X11/extensions/Xcup.h:1198443181   # 
x11-proto-devel-7.3-2mdv2008.0
/usr/include/asm/sockios.h:1186061974   # glibc-devel-2.6.1-4.1mdv2008.0
/usr/include/asm-generic/ioctl.h:1186061951     # 
glibc-devel-2.6.1-4.1mdv2008.0
/usr/include/dbus-1.0/dbus/dbus-macros.h:1189532431     #
libdbus-1_3-devel-1.0.2-10mdv2008.0
/usr/include/termios.h:1195662581       # glibc-devel-2.6.1-4.1mdv2008.0
--

  I am adding this to <module>.deps file to -devel rpm packages, but the
proper name could be a -packager package :-) Note that rpm packages don't
always match X Org packages, but I am trying to rework it, example, in
Mandriva all *proto are in a single package.
  Also note that the perl scripts may need some updates, as some files
may always be generated, currently, and at least in my build, xorg-server.h
is always being regenerated. It also prints warning if some include not
in /usr/include or /usr/lib/gcc is used (and ofcourse, doesn't list
dependencies on headers inside the build tree :-)

  The mtime field is usede by another script, that call tell what has
been modified, or if new dependencies exist, or if old dependencies
were droped, among others. But needs manual intervention to check if a
package really needs to be rebuilt.

  After generating these files, another script reads the <module>.deps
files and builds a list like:
rpm-name : (rpm-dep1, rpm-dep2, ...)

and then, just use "tsort | tac" to print "build order" as well as detect
possible cyclic dependencies.

  I need to also create a possible other method for ``modules'' that
aren't compiled (i.e. things like data files, m4 macros, etc), or a
dependency list is not generated (possibly some hand written Makefile,
or the like). Cavassin at Mandriva suggested me to use or write a variant
of an old rpm script (dep) that basically uses strace and logs all
opens and execs during builds (since the concept is simple, I will
try it soon, but I believe it will be really slow :-).


> -- 
>     -Alan Coopersmith-           alan.coopersmith at sun.com
>      Sun Microsystems, Inc. - X Window System Engineering

Paulo






More information about the xorg mailing list