I managed to compile this three times, with different packages, then a bit over 24 hours ago I decided to automate it with a compile-script, to make it easy for myself and others to do this in the future, and maybe try other upgrade packages.
Yeah, well, it was most frustrating, no matter what I tried, xorg-server kept hitting conflicting definitions.
So I went back to my notes, tried doing it manually, still got the conflicts. Tried, and tried, no go, late last night I gave up.
Obviously, I have missed something somewhere, that I forgot to make a note of.
Fortunately, I do have a set of binaries from when it did work, and I have created PETs.
These binaries are my first successful "go" at compiling all the upgrades, and is an absolutely minimal upgrade. libX11 is compiled without xcb support, as it requires a later version than what is currently in Wary. The existence of the older xcb, which some other libraries use, does not seem to conflict with libX11 library's non-use of xcb.
For the record, these are the packages that I upgraded:
The PET is here (7.2MB):
So, if Wary chooses to run 'vesa' only on your computer, and you know that you have Intel video hardware (and you know that the older i810 driver is not going to work), try this PET. It works great on my Acer netbook with N450 CPU and Pineview graphics. This PET is for recent Intel video hardware 2009/2010.
If you are interested in attempting to compile other recent (non-Intel) X drivers, install these two packages. The first one provides the extra DRI drivers from the MesaLib package, the second has all the "dev" components:
Comments:Posted on 12 Oct 2010, 15:09 by technosaurus
I have been playing with uclibc and dietlibc a bit and have learned a counterintuitive lesson... sometimes multiple definitions comes from missing a definition. for instance
when the compiling is scrolling by you can see the problems with -DENABLE* etc... or -DHAVE_CONFIG_H ... these should be cflags in the pkg-config .pc or in a separate .h file so that later versions don't miss it, but they often are not ... and god forbid a matching environment variable is present
--- this makes it very difficult to track down if you aren't obsessively observant and compiling everything at the same time
I wonder if it would help to write a wrapper that captures these (I already wrote something similar so that I could easily use the -fwhole-program option on larger projects)
basically something like
make 2&>1 >file && grep "some_string" file |tr "\n" "\n" |sort |uniq
Posted on 12 Oct 2010, 17:40 by BarryK
Tearing my hair out
Last night I was becoming so frustrated, as it worked before, and I was pretty sure that I was using the same packages but now it doesn't work.
But, I have just had a thought, based on your post. Perhaps I compiled the packages in a different order when it worked, and I neglected to properly record that order. One or two packages out of order could pick up a wrong definition.