[Xpert]xdm updates
Hi, During last weeks I've commited to the XFree86 CVS repository various patches to xdm. As far as I can tell and from the tests I did, there should be no problems with them. However I'd appreciate if people using XFree86's xdm in real world conditions (with several X terminals for instance) could try this updated version, and report failures in case it breaks something. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Static linking X applications: a difficulty
Jonathan Woithe wrote (in a message from Thursday 14) * given this new dynamic locale functionality, how exactly is one to make a static executable which will run on all systems? You need to build the static library with #define BuildLoadableXlibI18n NO in host.def. Unfortunatly there's currently no way to set this for the static library only (ie build the shared lib with loadable modules and the static one without them). Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: windows-1252 vs. iso-8859-1
Hanspeter Roth wrote (in a message from Friday 25) On Oct 25 at 19:55, Juliusz Chroboczek spoke: Would you be so kind as to explain what you mean? meta http-equiv=Content-Type content=text/html; charset=windows-1252 I just commited a fixed version. Thanks for noticing it. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xdm without graphics card
Received: from localhost (root@localhost [127.0.0.1]) by harvest.herrb.com (8.12.6/8.12.1) with ESMTP id g96Dt4TD017347 Hi list! I want to install a terminal server on a PC without grpahics card(plaesa don't ask why).I wonder if it is possible. Yes. If so, can anyone explain how? Just disable the local server in /etc/X11/xdm/Xservers (add a '#' in the front of the last line) and then use the preferren method for your OS to start xdm on your server. (/etc/init.d/xdm or such). Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]NV17 and X
[EMAIL PROTECTED] wrote (in a message from Sunday 29)
Mark Vojkovich [EMAIL PROTECTED] wrote :
i810_accel.c: In function `I810AccelInit':
i810_accel.c:222: `I810_FRONT' undeclared (first use in this function)
i810_accel.c:222: (Each undeclared identifier is reported only once
i810_accel.c:222: for each function it appears in.)
i810_accel.c: In function `I810SelectBuffer':
i810_accel.c:587: `I810_BACK' undeclared (first use in this function)
i810_accel.c:590: `I810_DEPTH' undeclared (first use in this function)
i810_accel.c:588: warning: unreachable code at beginning of switch statement
i810_accel.c:594: `I810_FRONT' undeclared (first use in this function)
*** Error code 1
Stop in /usr/src/XF4/xc/programs/Xserver/hw/xfree86/drivers/i810.
*** Error code 1
This is error on OpenBSD 3.1 i386 latest stable. X version is current cvsup from
official host cvsup.xfree86.org.
Any ideas how to compile?
Try this patch in xc/programs/Xserver/hw/xfree86/drivers/i810/:
Index: i810_accel.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_accel.c,v
retrieving revision 1.13
diff -u -r1.13 i810_accel.c
--- i810_accel.c2002/09/11 00:29:31 1.13
+++ i810_accel.c2002/09/29 16:21:39
@@ -51,6 +51,7 @@
#include i810.h
#include i810_reg.h
+#include i810_common.h
static unsigned int i810Rop[16] = {
0x00, /* GXclear */
Index: i830_accel.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i830_accel.c,v
retrieving revision 1.1
diff -u -r1.1 i830_accel.c
--- i830_accel.c2002/09/11 00:29:32 1.1
+++ i830_accel.c2002/09/29 16:21:39
@@ -58,6 +58,7 @@
#include i830.h
#include i810_reg.h
+#include i830_common.h
static unsigned int i810Rop[16] = {
0x00, /* GXclear */
Matthieu
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 dies early without error
Markus Gutschke wrote (in a message from Monday 9) [EMAIL PROTECTED] wrote: Sep 9 18:36:13 [kernel] PAX: terminating task: /usr/X11R6/bin/XFree86(XFree86):23363, uid/euid: 0/0, EIP: 08247BB8, ESP: BFF31D0C o So it IS the kernel's fault. Google says PAX controls security. I have someplace to start now, but feel free to shout out the quick fix if you see one. This is what is says in the PAX patch file: + Enabling this feature will enforce the non-executable flag on + memory pages thereby making it harder to execute 'foreign' code + in a program. This will also break programs that rely on the + old behaviour and expect that dynamically allocated memory via + the malloc() family of functions is executable (which it is not). + Notable examples are the XFree86 4.x server, the java runtime + and wine. + Do the PAX patches allow mprotect() calls to make the allocated pages executable ? The XFree86 ELF loader currently miss a few mprotect() calls, but I've a patch that adds the missing calls and make the loader happy again on OpenBSD architectures that have non-executable heap now. It should work too with PAX if it implements mprotect(). Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xf86MapVidMem: could not mmap screen
Louis Guillaume wrote (in a message from Wednesday 29) I had to make some modifications in xc/programs/Xserver/hw/xfree86/os-support/bus/macppcPci.c so that it uses the Bandit bridge instead of the UniNorth. It compiled but I get this at runtime... Fatal server error: xf86MapVidMem: could not mmap screen [s=2,a=a] (Invalid argument) You probably need to run at securelevel=0. It may also be that the NetBSD/macppc kernel doesn't allow mmap()ing of the VGA region at all. In this case just change ppcMapVidMem in bsd_video.c to make that error non fatal. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]GCC 3.0.3 and X 4.2.0 compile problem
Kevin Clevenger wrote (in a message from Wednesday 13) When compling X 4.2.0 with gcc 3.0.3 on a glibc 2.2.5 system I get the following. Using gcc 2.95.3 on the same system compiles correctly. I have tried altering the -traditional flag in the imakemdep.h file to no avail. Other people I've asked say that cpp in gcc 3.0 still supports -traditional. What's special about your configuration that makes it not support -traditional ? The -traditional flag is required with gcc's cpp because otherwise it does silly things to imake input. (Adds white space before and after macro expansion results, tries to interpret backslashes where it should leave them alone, etc.) It's really unfortnate if the GNU people have removed the -traditional option to cpp in gcc 3.0. XFree86 will have to provide a non broken C pre-processor for imake to work with gcc 3, in this case. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]GCC 3.0.3 and X 4.2.0 compile problem
Kevin Clevenger wrote (in a message from Wednesday 13) When compling X 4.2.0 with gcc 3.0.3 on a glibc 2.2.5 system I get the following. Using gcc 2.95.3 on the same system compiles correctly. I have tried altering the -traditional flag in the imakemdep.h file to no avail. Other people I've asked say that cpp in gcc 3.0 still supports -traditional. What's special about your configuration that makes it not support -traditional ? The -traditional flag is required with gcc's cpp because otherwise it does silly things to imake input. (Adds white space before and after macro expansion results, tries to interpret backslashes where it should leave them alone, etc.) It's really unfortnate if the GNU people have removed the -traditional option to cpp in gcc 3.0. XFree86 will have to provide a non broken C pre-processor for imake to work with gcc 3, in this case. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: CVS from Dec. 2nd broken on Linux: errno problems
Olivier Cahagne wrote (in a message from Sunday 2) (I guess this is related to Matthieu Herrb's recent commits on errno code) I also tried as root, but there's no difference, it seems like the files are here but imake does not see them. [...] cc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c In file included from /usr/include/signal.h:300, from imake.c:178: /usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from imake.c:230: /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory Hmm, I doubt it's my fixes that are causing this. I didn't touch imake for now. And it still builds on a RedHat 7.0/i386 system I use for testing. This looks to me more like the traditional breakage when installed kernel headers don't match the ones for glibc. Linux is not the system I have the more experience with, so I'm not able to suggest you a fix. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]shared and static extension libraries re(^6)-visited
Branden Robinson wrote (in a message from Thursday 18) I'd like to solicit opinions, especially from the Core Team, about the shared vs. static extension library situation. Debian just went through a bit of pain and suffering as regards SDL in our development branch, partly because we have 12 architectures to supprt for our next release. [] Also, if I've gotten any facts wrong in the above analysis, please correct me. I'm not from the XFree86 core team, so feel free to discard my message... Your analysis seem basically correct to me, to build a shared object loadable via dlopen() you need a position independant version of all code that will be loaded that way. OTOH, I'd like to say that the common habit of linking shared libraries together to allow lazy Makefiles to only list the first library of a list of dependent libraries should be discouraged, as it can create lots of problems (for instance it makes it impossible to use this Makefile on systems without shared libraries or on systems where shared libs don't have dependencies). Having remainded that, providing _pic.a versions for the libraries that are only available as static in XFree86 seems reasonable to me, to make it possible to make dlopen'able PIC module. I can even propose an implementation. How to decide which libraries should be provided as _pic.a ? Given that in my implementation the 'DoPicLib' variable will control the build of this library, I propose the following default value for each library XXX: #define DoPicLib HasSharedLibrary !SharedLibXXX And below is a proposed patch to implement it (the definition of DoPicLib in each directory is left as an exercice :-) Matthieu Index: Imake.rules === RCS file: /home/x-cvs/xc/config/cf/Imake.rules,v retrieving revision 3.101 diff -u -r3.101 Imake.rules --- Imake.rules 2001/10/02 11:44:12 3.101 +++ Imake.rules 2001/10/21 18:48:55 @@ -2550,6 +2550,20 @@ /* + * Rule to build libXXX_pic.a from PIC objects for a library + */ +#ifndef PicLibraryTarget +#definePicLibraryTarget(libname,objlist) @@\ +AllTarget(LibraryTargetNameSuffix(libname,_pic)) @@\ + @@\ +LibraryTargetNameSuffix(libname,_pic): objlist $(EXTRALIBRARYDEPS) @@\ + RemoveFile($@) @@\ + MakeLibrary($@,objlist) @@\ + RanLibrary($@) @@\ + _LinkBuildLibrary($@) +#endif /* PicLibraryTarget */ + +/* * SubdirLibraryRule - */ #ifndef SubdirLibraryRule Index: Library.tmpl === RCS file: /home/x-cvs/xc/config/cf/Library.tmpl,v retrieving revision 3.15 diff -u -r3.15 Library.tmpl --- Library.tmpl2001/08/27 17:40:55 3.15 +++ Library.tmpl2001/10/21 18:49:08 @@ -3,7 +3,7 @@ * that Imakefiles in the various library subtrees will need. * * Before including this, you must set the following boolean variables: - * DoNormalLib, DoSharedLib, DoDebugLib, DoProfileLib + * DoNormalLib, DoSharedLib, DoDebugLib, DoProfileLib, DoPicLib * * To get automatic generation of standard rules, also set the variables: * LibName, SoRev, HasSharedData, and optionally HugeLibrary and IncSubdir. @@ -21,8 +21,15 @@ XCOMM $XFree86: xc/config/cf/Library.tmpl,v 3.15 2001/08/27 17:40:55 dawes Exp $ +/* + * Some libraries may not define DoPicLib + */ +#ifndef DoPicLib +# define DoPicLib NO +#endif + #ifndef LibraryCplusplusOptions -# if DoSharedLib defined(SharedLibraryCplusplusOptions) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCplusplusOptions) # define LibraryCplusplusOptions SharedLibraryCplusplusOptions # else # define LibraryCplusplusOptions DefaultCplusplusOptions @@ -48,14 +55,14 @@ #ifndef CplusplusSource # ifndef LibraryCcCmd -# if DoSharedLib defined(SharedLibraryCcCmd) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCcCmd) # define LibraryCcCmd SharedLibraryCcCmd # else # define LibraryCcCmd CcCmd # endif # endif # ifndef LibraryCCOptions -# if DoSharedLib defined(SharedLibraryCCOptions) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCCOptions) # define LibraryCCOptions SharedLibraryCCOptions # else # define LibraryCCOptions DefaultCCOptions @@ -73,14 +80,14 @@ # endif #else # ifndef LibraryCplusplusCmd -# if DoSharedLib defined(SharedLibraryCplusplusCmd) +# if (DoSharedLib || DoPicLib) defined(SharedLibraryCplusplusCmd) # define LibraryCplusplusCmd SharedLibraryCplusplusCmd # else # define LibraryCplusplusCmd CplusplusCmd # endif # endif # ifndef LibraryCplusplusOptions -# if DoSharedLib defined(SharedLibraryCplusplusOptions) +# if (DoSharedLib ||
Re: [Xpert]3.3.6 Makefile generation bug
Samium Gromoff wrote (in a message from Sunday 23) Hello folks, /me have been recently struck by the following issue when i modify cf/cf/xfree86site.def::DefaultGcc2i386Opt to contain -mcpu=pentium, all makefiles, xmakefile and Makefile.proto`s start to contain -mcpu=1 what is inconsistent with my definition of cflags /me feels this is a bug, and while 3.3.6 isnt maintained anymore its useful to fix it... Actually i spent 2+ hours while hunting it and trying to override this behaviour, but i`m not an Makefile expert so i failed... ;) In xc/config/cf/Imake.cf there is code to #undef'ine the symbols predefined by cpp, in order to avoid the kind of problems you're seeing. The following patch adds an #undef pentium to the 4.1.0 source. You should be able to adapt it to 3.3.6. Index: xc/config/cf/Imake.cf === RCS file: /cvs/XF4/xc/config/cf/Imake.cf,v retrieving revision 1.4 diff -u -r1.4 Imake.cf --- xc/config/cf/Imake.cf 2001/09/06 22:07:51 1.4 +++ xc/config/cf/Imake.cf 2001/09/23 06:51:56 @@ -631,6 +631,9 @@ # endif # undef i686 # endif +# ifdef pentium +# undef pentium +# endif # ifdef k6 # ifndef i386Architecture # define i386Architecture Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Stopping and restarting X from a script..
Burt Bicksler wrote (in a message from Tuesday 4) Hi, reliable way to kill X from a script? Is there anything other than greping the output of ps, extracting the process ID for X and passing that to kill? If not, is there an example script somewhere that you could point me to? The pid of the X server is in /tmp/.Xdisplaynumber-lock. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
