Re: Xorg Cross Compiling
On Fri, Oct 29, 2010 at 11:45:59AM -, Harsha Sukeerthi wrote: /usr/local/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: r300_dri.so.test: hidden symbol `__sync_sub_and_fetch_4' in /usr/local/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(linux-atomic.o) is referenced by DSO The problem is that the code wants to use an atomic instruction that GCC doesn't have a builtin for. Check your -march settings or whether the architecture supports that at all. Joerg ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] Deprecation of xf86-video-nv
On Tue, Mar 30, 2010 at 10:33:01PM -0400, Matt Turner wrote: this limits nvidia driver usage to specific libc implementation, with specific version. glibc is kind of the de facto libc. What do you expect here? Them not to link to the C library? Provide a second binary linking against uclibc? And what then about all the other libc's? In fact, that was the problem we (DragonFly) run into back in the early days. Getting the kernel module to work as one issue. But as soon as the libc ABI divergated from the FreeBSD (4.x) ABI and the latter the 5.x only libGL, all things were lost. In short, the libGL is more painful part of the nvidia blob... Joerg ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: what is XF86VM?
On Tue, Aug 04, 2009 at 05:24:43PM +0800, kedahanzi wrote: Dear everyone, what is XF86VM? Extension to change the video mode of the server. Consider games that want to use a lower resolution for full screen operation. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Mon, Jun 08, 2009 at 04:20:00PM -0400, Adam Jackson wrote: Security is handled out of band like any other project. We'll release patches for at least the most recent release, probably do a point release for same, and anyone shipping anything older gets to backport. In practise, this didn't happen though. I don't care about most other parts, but this one is and was a huge regression compared to the monolithic word. Another issue is of course the undocumented incompatibility. Typical example: you can build xf86-video-intel against xorg-server-1.4.x Trying to use it shows all kinds of trouble. Proper failure in this case is better than all kind of mysterious bugs. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org release engineering?
On Tue, Jun 09, 2009 at 08:13:03AM -0700, Alan Coopersmith wrote: Assuming you mean http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=5bf703700ee4a5d6eae20da07cb7a29369667aef the patch is available from git, like all other changes. See earlier part about following git history :) I can't find much discussion in the xorg_security list mail in my inbox archives (list archives obviously aren't public) but it looks like no one declared that they believed it was an exploitable security issue, just a bug. I wouldn't care about most off-by-one issues. This one is under full user control though as xset can be used to make the server process arbitrary directories (e.g. under /tmp). Anyway, it is an issue of the past. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.7.0
On Thu, Apr 16, 2009 at 04:47:14AM +0200, Joerg Sonnenberger wrote: (b) Xv doesn't crash the Xserver any more, which is good. When xcompmgr is running, it doesn't show the video though (black window). I take that partially back. With DRI disabled, Xv still crashes the X server. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.7.0
On Wed, Apr 15, 2009 at 06:29:33PM -0700, Carl Worth wrote: Compared to the 2.6 series, 2.7.0 has a large number of bug fixes, (see the list below), but also a few significant features, such as: (a) The new check in i830_lvds.c line 1425 disables my internal display. (b) Xv doesn't crash the Xserver any more, which is good. When xcompmgr is running, it doesn't show the video though (black window). This is on NetBSD with xorg-server 1.4.2 and libdrm-2.4.7. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 07, 2009 at 02:32:38PM +0200, Nicolas Mailhot wrote: This is not something specific to core fonts. Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution Are you *really* sure about that? I haven't tried Firefox 3, but older version definitely crashed if fontconfig wouldn't find fonts. Even if the X server itself advertised the presence of core fonts. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Fix cast int-to-pointer and pointer-to-int
On Thu, Feb 05, 2009 at 06:25:40PM +0100, Tomas Carnecky wrote: On 02/04/2009 09:04 PM, Joerg Sonnenberger wrote: On Wed, Feb 04, 2009 at 08:43:43PM +0100, Tomas Carnecky wrote: By first casting to long and then to the final type. Of course this assumes that sizeof(long) == sizeof(void *). If the Win32 folks care enough about warnings, we could make macros for this. Please use either uintptr_t (prefered) or size_t (fallback) instead of long. Also really make this a macro so that it can easily be searched for. uintptr_t doesn't guarantee what we need either. It only guarantees void* - intptr_t - void* conversion, but we also need 'intptr_t - void* - intptr_t'. The man page (stdint.h) doesn't say that intptr_t has to be the same width as pointers. It could be 128bits and gcc would still throw a warning. But if that's considered a non-issue, I'll change the code. Frankly, that's a problem to worry about when it comes up and that sounds strongly like a fictional problem. In any case, as long as the value came originally from a pointer (and why would it be valid otherwise?), it doesn't matter. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Fix cast int-to-pointer and pointer-to-int
On Wed, Feb 04, 2009 at 08:43:43PM +0100, Tomas Carnecky wrote: By first casting to long and then to the final type. Of course this assumes that sizeof(long) == sizeof(void *). If the Win32 folks care enough about warnings, we could make macros for this. Please use either uintptr_t (prefered) or size_t (fallback) instead of long. Also really make this a macro so that it can easily be searched for. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Fix cast int-to-pointer and pointer-to-int
On Wed, Feb 04, 2009 at 02:10:36PM -0800, Ian Romanick wrote: On Wed, Feb 04, 2009 at 09:04:05PM +0100, Joerg Sonnenberger wrote: On Wed, Feb 04, 2009 at 08:43:43PM +0100, Tomas Carnecky wrote: By first casting to long and then to the final type. Of course this assumes that sizeof(long) == sizeof(void *). If the Win32 folks care enough about warnings, we could make macros for this. Please use either uintptr_t (prefered) or size_t (fallback) instead of long. Also really make this a macro so that it can easily be searched for. mod +1 I think autoconf has some magic to generate typedefs for uintptr_t and friends when they are not available. Make it look like that. :) AC_TYPE_UINTPTR_T. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Include sdk header dependencies and protect agains't multiple inclusion.
On Wed, Dec 17, 2008 at 03:34:04PM -0500, Thomas Dickey wrote: On Wed, Dec 17, 2008 at 06:23:09PM -0200, Paulo C?sar Pereira de Andrade wrote: The patch as a whole may not be required to apply, and not that patch verbatim, as it would require still at least a review to ensure every sdk header passes the: ifdef HAVE_FOO_CONFIG_H #include foo-config.h #endif It's failure-prone, and increases the amount of work for developers. I didn't see any figures on how much faster the build would be, to compensate for this. With any non-braindead compiler, it is the same as just including the file with include guards. E.g. GCC knows about such include files and optimises the include away for any but the first time. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: dolt?
On Thu, Nov 06, 2008 at 09:03:56AM -0500, James Cloos wrote: Should we dolitfy the rest of the libraries? If you do, please also fix all applications to consistently use libtool for linking. Many currently don't and fail on platforms without transitive linker like AIX. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LBX? or faster remote X?
On Tue, Nov 04, 2008 at 01:31:50PM -0500, Benjamin M. Schwartz wrote: Any alternatives? NBX Maybe you mean NX? http://en.wikipedia.org/wiki/NX_technology Sorry, yes. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
