Re: gEDA-user: PCB Gtk port

[Daniel Nilsson <daniel@xxxxxxxxxxxxxxx>]

On Mon, Feb 28, 2005 at 07:23:22PM -0500, Dave McGuire wrote:
> On Feb 28, 2005, at 7:00 PM, Daniel Nilsson wrote:
> >>  Yes, it is ridiculous for GTK+ to *require* fancy font-handling
> >>techniques for applications that do not require them.  Doing TrueType
> >>fonts and antialiasing for menu choice is just plain excessive.
> >>
> >>  Especially when it means the application will only run under Linux.
> >
> >Why do you say that? GTK+ application runs under a wide variety of
> >operating systems.
> 
>   Well, if you can get it built.  I finally did, and it broke 
> EVERYTHING ELSE on that machine...I went to start up gnome-terminal on 
> one of my SunRays and it blew up complaining about my display lacking 
> the RENDER extension.  So anything that links against GTK+ will now 
> automatically require that optional X server extension that is nowhere 
> near universally implemented.  This strikes me as a very large problem.

So I knew that building GTK+ 2.6 on Solaris is a bit of a hazzle due
to the Xrender stuff, that's why I wanted to point you to the
libraries yesterday that I used to make it work. I have GTK+ 2.6
running under Solaris 8 / SPARC, it does not require the XRENDER
extension on the Xserver. I know how you feel though, I thought too
that starting with GTK+ 2.something that you were out of luck unless
you had XRENDER on the Xserver. But after reading up on it I found
those libraries from Keith that made it all work, they did pay
attention to make sure that users on Sun/AIX/Tru64 etc etc shouldn't
be unable to use apps requiring GTK+ 2.6.

I don't understand how your build of GTK+ 2.6 could break the (SUN
supplied ?) gnome-terminal ? You didn't overwrite the system wide GTK+
libraries in /usr did you ?

To prove that the whole thing I just built GTK-PCB on Solaris 8 and
took it for a spin. The GUI comes up and looks good, but the
application dumps core when trying to load a file. This is since
gui_output_set_name_label receives a null pointer from LoadPCB in
file.c:215. It's downhill from there until it finally blows up in
strlen in libc.

-- 
Daniel Nilsson