bug#3877: Bug probably solved

bug#3877: Bug probably solved

[Peter Dyballa]

Hello!

It looks as if the cause lies in incompatible versions (of  
libraries), most probably Xft2, and here C header and PC files. I'll  
retry a build later tonight with the updated extra files removed.

--
Greetings

   Pete

Programming today is a race between software engineers striving to  
build bigger and better idiot-proof programs, and the Universe trying  
to produce bigger and better idiots. So far, the Universe is winning.
				– Rich Cook

bug#3877: Bug probably solved

[Chong Yidong]

> It looks as if the cause lies in incompatible versions (of  
> libraries), most probably Xft2, and here C header and PC files. I'll  
> retry a build later tonight with the updated extra files removed.

Hi Peter,

Was this resolved?

bug#3877: Bug probably solved

[Peter Dyballa]

Am 16.08.2009 um 01:08 schrieb Chong Yidong:

>> It looks as if the cause lies in incompatible versions (of
>> libraries), most probably Xft2, and here C header and PC files. I'll
>> retry a build later tonight with the updated extra files removed.
>
> Hi Peter,
>
> Was this resolved?


No, not really. I'd have to change some statements in the Makefiles  
to make ld bind the binaries to particular libraries (most probably  
statically) and haven't yet used my spare-time to investigate on this  
topic, copy good examples from other software. Besides, maybe I am  
the last one who tries to compile up-to-date software on an old set  
of soft- and PPC hardware. Apple's Tiger, Mac OS X 10.4(.11), is now  
four or five years old, the 'recent' Mac OS X 10.5.x, Leopard, is  
going to be superseded by Snow Leopard, Mac OS X 10.6, any day now...

Since I am sure that this is the reality (not a 'buggy' software from  
GNU/FSF) I am a bit reluctant and rather pay attention to not xkill  
GNU Emacs.

--
Greetings

   Pete

Clovis' Consideration of an Atmospheric Anomaly:
         The perversity of nature is nowhere better demonstrated
         than by the fact that, when exposed to the same atmosphere,
         bread becomes hard while crackers become soft.

bug#3877: Bug probably solved

[Peter Dyballa]

Am 16.08.2009 um 01:08 schrieb Chong Yidong:

>> It looks as if the cause lies in incompatible versions (of
>> libraries), most probably Xft2, and here C header and PC files. I'll
>> retry a build later tonight with the updated extra files removed.
>
> Hi Peter,
>
> Was this resolved?


I think it is not. I build GNU Emacs 23.1.50 now, a few days, with  
GTK and need some more xkills. Before, with Xaw3d, sporadically cores  
were built upon xkill. Both variants of the X client are built with  
shared libraries from MacPorts (plus some inevitable ones from the  
system), which all are, supposedly, fitting each-other. When both  
variants act so differently than one has to have something like a  
bug, related to libXaw3d or libXt or libXmu presumingly, which the  
Athena 3D variant uses.

(The next ten or such days I'll presumingly be on holidays.)

--
Greetings

   Pete

We have to expect it, otherwise we would be surprised.

bug#3877: X protocol error: BadDrawable

[Glenn Morris]

Do you still see this with the latest version?
If so, we need a backtrace from a build with debugging information in
order to be able to do anything.

bug#3877: X protocol error: BadDrawable

[Peter Dyballa]

Am 11.07.2011 um 04:41 schrieb Glenn Morris:

>
> Do you still see this with the latest version?
> If so, we need a backtrace from a build with debugging information in
> order to be able to do anything.


I tried to repeat what I was doing two years ago. So many things  
obviously have changed, so no X protocol error happens anymore. I'd  
like to try one more thing, compile with the complete set of m17n  
libraries and libraries from the Fink package manager.

--
Greetings

   Pete

Journalism is printing what someone else does not want printed;  
everything else is public relations.
			– George Orwell

bug#3877: X protocol error: BadDrawable

[Peter Dyballa]

Am 11.07.2011 um 04:41 schrieb Glenn Morris:

>
> Do you still see this with the latest version?
> If so, we need a backtrace from a build with debugging information in
> order to be able to do anything.


The GNU Emacs I've built with libm17n support from the Fink package  
manager too behaves OK. Maybe it was indeed due to the exotic  
combination of slightly incompatible libraries.

I think this old bug report can be closed!

--
Greetings

   Pete

Government is actually the worst failure of civilized man. There has  
never been a really good one, and even those that are most tolerable  
are arbitrary, cruel, grasping and unintelligent.
				– H. L. Mencken