Re: [Xquartz-dev] What's the story with Xaw3d?
Am 13.05.2009 um 18:48 schrieb Ken Preslan:
I don't think the dependencies for emacs+x11 are quite right. I've seen the same thing after upgrading the port for some low-level X11 library. Uninstalling emacs and reinstalling it has always fixed it for me, though.
Recent Emacsen use GTK+2 as default in X11. Which is a pity. A private version of the port file might be a solution ... -- Greetings Pete In a world without walls and fences, who needs gates and windows?
On May 14, 2009, at 14:12, Peter Dyballa wrote:
Am 13.05.2009 um 18:48 schrieb Ken Preslan:
I don't think the dependencies for emacs+x11 are quite right. I've seen the same thing after upgrading the port for some low-level X11 library. Uninstalling emacs and reinstalling it has always fixed it for me, though.
Recent Emacsen use GTK+2 as default in X11. Which is a pity. A private version of the port file might be a solution ...
I think if you don't use the motif, gtk, or carbon variants, you'll use athena widgets for emacs in MacPorts.
Well I've been building away on the Freedom from MacPorts front - and now have a working gtk+ environment - running against the 2.3.3 X11 libraries. It's mostly really easy apart from the jpeg library which needs some help to patch its files for libtool (thanks to MacPorts for this). Many thanks for the pkginfo files in /usr/X11/lib!!! However - gtk-demo (and my emacs compiled with gtk) says: Xlib: extension "RANDR" missing on display "/tmp/launch-HZZyYL/:0". which is odd because the library is there. I figure I can disable this in the GTK build - but wondered if it was worth flagging. On 15 May 2009, at 00:53, Jeremy Huddleston wrote:
On May 14, 2009, at 14:12, Peter Dyballa wrote:
Am 13.05.2009 um 18:48 schrieb Ken Preslan:
I don't think the dependencies for emacs+x11 are quite right. I've seen the same thing after upgrading the port for some low-level X11 library. Uninstalling emacs and reinstalling it has always fixed it for me, though.
Recent Emacsen use GTK+2 as default in X11. Which is a pity. A private version of the port file might be a solution ...
I think if you don't use the motif, gtk, or carbon variants, you'll use athena widgets for emacs in MacPorts.
This is what I did originally. Why can't MacPorts offer an option to build against the installed X11 libraries?
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
The server doesn't support RANDR... it has nothing to do with your client-side libs. On May 15, 2009, at 02:24, Peter Collinson wrote:
Well I've been building away on the Freedom from MacPorts front - and now have a working gtk+ environment - running against the 2.3.3 X11 libraries. It's mostly really easy apart from the jpeg library which needs some help to patch its files for libtool (thanks to MacPorts for this). Many thanks for the pkginfo files in /usr/X11/lib!!!
However - gtk-demo (and my emacs compiled with gtk) says:
Xlib: extension "RANDR" missing on display "/tmp/launch-HZZyYL/:0".
which is odd because the library is there. I figure I can disable this in the GTK build - but wondered if it was worth flagging.
On 15 May 2009, at 00:53, Jeremy Huddleston wrote:
On May 14, 2009, at 14:12, Peter Dyballa wrote:
Am 13.05.2009 um 18:48 schrieb Ken Preslan:
I don't think the dependencies for emacs+x11 are quite right. I've seen the same thing after upgrading the port for some low-level X11 library. Uninstalling emacs and reinstalling it has always fixed it for me, though.
Recent Emacsen use GTK+2 as default in X11. Which is a pity. A private version of the port file might be a solution ...
I think if you don't use the motif, gtk, or carbon variants, you'll use athena widgets for emacs in MacPorts.
This is what I did originally. Why can't MacPorts offer an option to build against the installed X11 libraries?
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
OK - I can tell gtk++ that. Thanks. On 15 May 2009, at 18:14, Jeremy Huddleston wrote:
The server doesn't support RANDR... it has nothing to do with your client-side libs.
On May 15, 2009, at 02:24, Peter Collinson wrote:
Well I've been building away on the Freedom from MacPorts front - and now have a working gtk+ environment - running against the 2.3.3 X11 libraries. It's mostly really easy apart from the jpeg library which needs some help to patch its files for libtool (thanks to MacPorts for this). Many thanks for the pkginfo files in /usr/X11/lib!!!
However - gtk-demo (and my emacs compiled with gtk) says:
Xlib: extension "RANDR" missing on display "/tmp/launch-HZZyYL/:0".
which is odd because the library is there. I figure I can disable this in the GTK build - but wondered if it was worth flagging.
On 15 May 2009, at 00:53, Jeremy Huddleston wrote:
On May 14, 2009, at 14:12, Peter Dyballa wrote:
Am 13.05.2009 um 18:48 schrieb Ken Preslan:
I don't think the dependencies for emacs+x11 are quite right. I've seen the same thing after upgrading the port for some low-level X11 library. Uninstalling emacs and reinstalling it has always fixed it for me, though.
Recent Emacsen use GTK+2 as default in X11. Which is a pity. A private version of the port file might be a solution ...
I think if you don't use the motif, gtk, or carbon variants, you'll use athena widgets for emacs in MacPorts.
This is what I did originally. Why can't MacPorts offer an option to build against the installed X11 libraries?
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
This is a FYI - not a bug: It seems that for gtk+=2.16.1 the 'configure' test to assert HAVE_RANDR is # Check for the RANDR extension if $PKG_CONFIG --exists "xrandr >= 1.2.99" ; then AC_DEFINE(HAVE_RANDR, 1, [Have the Xrandr extension library]) X_PACKAGES="$X_PACKAGES xrandr" fi For 2.3.3 - /usr/X11/lib has randr 1.3.0 Commenting all this out and rebuilding stops the complaint from Xlib in gtk-demo. On 15 May 2009, at 18:14, Jeremy Huddleston wrote:
The server doesn't support RANDR... it has nothing to do with your client-side libs.
On May 15, 2009, at 02:24, Peter Collinson wrote:
Well I've been building away on the Freedom from MacPorts front - and now have a working gtk+ environment - running against the 2.3.3 X11 libraries. It's mostly really easy apart from the jpeg library which needs some help to patch its files for libtool (thanks to MacPorts for this). Many thanks for the pkginfo files in /usr/X11/lib!!!
However - gtk-demo (and my emacs compiled with gtk) says:
Xlib: extension "RANDR" missing on display "/tmp/launch-HZZyYL/:0".
which is odd because the library is there. I figure I can disable this in the GTK build - but wondered if it was worth flagging.
On 15 May 2009, at 00:53, Jeremy Huddleston wrote:
On May 14, 2009, at 14:12, Peter Dyballa wrote:
Am 13.05.2009 um 18:48 schrieb Ken Preslan:
I don't think the dependencies for emacs+x11 are quite right. I've seen the same thing after upgrading the port for some low-level X11 library. Uninstalling emacs and reinstalling it has always fixed it for me, though.
Recent Emacsen use GTK+2 as default in X11. Which is a pity. A private version of the port file might be a solution ...
I think if you don't use the motif, gtk, or carbon variants, you'll use athena widgets for emacs in MacPorts.
This is what I did originally. Why can't MacPorts offer an option to build against the installed X11 libraries?
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (3)
-
Jeremy Huddleston
-
Peter Collinson
-
Peter Dyballa