Importing LIGHTING from China www.modern-lighting.com
Re: State of radeon driver
On Thu, 11 Dec 2003 02:16:01 +0100, wim delvaux [EMAIL PROTECTED] wrote: On Thursday 11 December 2003 00:48, Gerhard W. Gruber wrote: On Thu, 11 Dec 2003 00:39:57 +0100, wim delvaux [EMAIL PROTECTED] wrote: The closed source drivers on the ATI website I tried them, but no success. But I think the problem is with KDE/OpenGL because I managed to get at least the Desktop with Mesa working. Only when I try to activate the ATI provided OpenGL lib I can't start X/KDE anymore. I tried it too and also had no success. What version did you use ? I was using the ATI drivers 3.2.8. Then I tried the ones from Suse 9.0 also 3.2.8. And I also tried the 3.2.7 download but I didn't know how to install that because this was an RPM only and I found no makefiles within. When I tried to load the module it said that my kernel is compile dwith gcc2 and the module with gcc3 wich doesn't work. I found a thread on linuxquestions which was quite good. At least it got me going so far that X now uses the fglrx driver, but I still have the problem that I can't use KDE with the 3D accelerated OpenGL. When I link against Mesa everything works, but of course I have about 350 FPS on glxgears. When I trie to use the provided OpenGL lib I get this errormessage when starting X: DCOP aborting call from 'anonymous-3627' to 'kded' ERROR: KUniqueApplication: DCOP communication error! DCOP aborting call from 'anonymous-3630' to 'knotify' ERROR: KUniqueApplication: DCOP communication error! startkde: Shutting down... KLauncher: Exiting on signal 1 startkde: Running shutdown scripts... I don't think that the Radon 9800XT is so much different than the Radeon 9800Pro so the drivers should work. But I think the problem is maybe with KDE. Most of the users I found, which reported success were using Suse 9.0 so it could be that they have an updated KDE. I also tried the libGL.so from one of these users, but that gave me the same errormessage. Of course it could be that I would have needed to copy other lib*so files as well, but I don't think so. On the other hand I can run fvwm2 which works fine, but when I try to run glxgears it breaks also, so this points to the OpenGL stuff. I don't know what else I could try. Currently I install gentoo on my laptop and then I will see. I have a Radeon 900 Mobility in that, but I forgot to check how 3D works there. I plan to install gentoo on my main machine as well, but this will take quite some time until everything works. In the meantime I would be more than happy if somebody could point out what could be wrong. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: State of radeon driver
On Wed, Dec 10, 2003 at 01:44:23PM +0100, Alexander Stohr wrote: I have tried these drivers but refuse to work. They think I have an (unsupported) OEM card (=powered by ATI) while according to the identity check programs run under XP it 'should' be an ATI one (=Built by ATI) There is no general OEM barrier anymore. It only was it was in early days where no one was sure if drivers would work well on those boards. It would be kind if you can you retry this test with latest fglrx drivers and mail me the results in private or public, just as you want. Any chance for getting a powerpc build of them, for the nice new powerbooks with mobility 9600 graphic card in it ? Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Aiptek driver doesn't build on Red Hat 6.2
Fixing bug 940 breaks the build on Red Hat 6.2. I believe that the aiptek driver should only work with LINUX_INPUT, in which case, the patch I've submitted in bug 972 will stop the attempt to build aiptek on systems without LINUX_INPUT. (Please use the second patch - the first one isn't good enough). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
David Dawes wrote: If you look through the 4.3.99.15-1.3.99.16 patch, you'll find the patch hunk that removes xc/lib/font/FreeType/ft2build.h. I don't know why it didn't happen for you. Well, you're right. After patching I'm left with some zero-length files. The patch documentation says, that patch should normally remove such empty files automatically, based on timestamp analysis. I guess that it's just that I've applied several patches that caused this trouble. The first patch got the right timestamps, but the next ones probably didn't. Mea culpa. At least now I know that I should use the '-E' option when patching to remove those empty files. I've generated a list of files from the current tarball and from my local version, compared them, and it appears that I have 87 redundant files. Well, at least now I know how to avoid that in the future - patch with -E. Many thanks for your patience :) -- \hoppke (Grzegorz Grayna Niewgowski) http://lubuska.zapto.org/~hoppke/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
freetype2 problems with cvs
Hi all, http://www.mail-archive.com/[EMAIL PROTECTED]/msg04101.html In reference to the above link where david suggested some changes in the XFree86 source. Index: lib/Xft/Xft.h === RCS file: /home/x-cvs/xc/lib/Xft/Xft.h,v retrieving revision 1.32 diff -u -r1.32 Xft.h --- lib/Xft/Xft.h 25 Feb 2003 21:57:53 - 1.32 +++ lib/Xft/Xft.h 20 Nov 2003 22:03:55 - @@ -32,7 +32,8 @@ #define XftVersion XFT_VERSION #include stdarg.h -#include freetype/freetype.h +#include ft2build.h +#include FT_FREETYPE_H #include fontconfig/fontconfig.h #include X11/extensions/Xrender.h * when i try to crosscompile Qt/X11 with the /home/jassi/usr/X11R6/include headers generated by the compilation(cross) of Xfree86, the compiler cant find ft2build.h header file. So i have to explicitly mention the search path in the file. I think:: #include ft2build.h is XFree86 specific. Shudn't there be #include freetype2/ft2build.h so that any other software can figure out the headers easily. I mean the same for all the include's which can cause such problems. -Jassi
Re: freetype2 problems with cvs
On Thu, Dec 11, 2003 at 01:58:03PM -, jassi brar wrote: Hi all, http://www.mail-archive.com/[EMAIL PROTECTED]/msg04101.html In reference to the above link where david suggested some changes in the XFree86 source. Index: lib/Xft/Xft.h === RCS file: /home/x-cvs/xc/lib/Xft/Xft.h,v retrieving revision 1.32 diff -u -r1.32 Xft.h --- lib/Xft/Xft.h 25 Feb 2003 21:57:53 - 1.32 +++ lib/Xft/Xft.h 20 Nov 2003 22:03:55 - @@ -32,7 +32,8 @@ #define XftVersion XFT_VERSION #include stdarg.h -#include freetype/freetype.h +#include ft2build.h +#include FT_FREETYPE_H #include fontconfig/fontconfig.h #include X11/extensions/Xrender.h * when i try to crosscompile Qt/X11 with the /home/jassi/usr/X11R6/include headers generated by the compilation(cross) of Xfree86, the compiler cant find ft2build.h header file. So i have to explicitly mention the search path in the file. I think:: #include ft2build.h is XFree86 specific. Shudn't there be #include freetype2/ft2build.h so that any other software can figure out the headers easily. I mean the same for all the include's which can cause such problems. No, ft2build.h is correct. I you use the XFree86 installation, then you need -IProjectRoot/include/freetype2. It is arguable that it would have been better if the freetype2 headers were installed one level up, but I don't know what we'd break if we changed that now. On the other hand, an advantage of the way it is now is that it is less likely that an app will unintentionally use the XFree86-provided headers. Things that use imake that will get the build flags right. There are a few minor bugs in the way FREETYPE2INCLUDES is set, but they err on the side of redundancy. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
David Dawes wrote: Do the gcc people give a reason for not allowing a system directory to be blessed with -I? I wouldn't call it a reason, but the manual puts it like this: (...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. OK, I see. This is to prevent system directories being searched before directories containing gcc-specific replacements for system headers. Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of this '-I/usr/include': gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../exports/include -I/usr/include -I/usr/include/freetype2 -I../../exports/include/X11 -I../.. -I../../exports/include -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I. -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c In file included from charproc.c:123: /usr/include/error.h:26: parse error This is because gcc now includes /usr/include/error.h instead of error.h from programs/xterm. One should never put an explicit '-I/usr/include' or '-I/usr/local/include' in CFLAGS because this can lead to all sorts of strange behaviour. The same holds for '-L/usr/lib' or '-L/usr/local/lib' in LDFLAGS. Michael ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: freetype2 problems with cvs
On Thu, Dec 11, 2003 at 10:21:21AM -0500, David Dawes wrote: On Thu, Dec 11, 2003 at 01:58:03PM -, jassi brar wrote: Hi all, http://www.mail-archive.com/[EMAIL PROTECTED]/msg04101.html In reference to the above link where david suggested some changes in the XFree86 source. Index: lib/Xft/Xft.h === RCS file: /home/x-cvs/xc/lib/Xft/Xft.h,v retrieving revision 1.32 diff -u -r1.32 Xft.h --- lib/Xft/Xft.h 25 Feb 2003 21:57:53 - 1.32 +++ lib/Xft/Xft.h 20 Nov 2003 22:03:55 - @@ -32,7 +32,8 @@ #define XftVersion XFT_VERSION #include stdarg.h -#include freetype/freetype.h +#include ft2build.h +#include FT_FREETYPE_H #include fontconfig/fontconfig.h #include X11/extensions/Xrender.h * when i try to crosscompile Qt/X11 with the /home/jassi/usr/X11R6/include headers generated by the compilation(cross) of Xfree86, the compiler cant find ft2build.h header file. So i have to explicitly mention the search path in the file. I think:: #include ft2build.h is XFree86 specific. Shudn't there be #include freetype2/ft2build.h so that any other software can figure out the headers easily. I mean the same for all the include's which can cause such problems. No, ft2build.h is correct. I you use the XFree86 installation, then you need -IProjectRoot/include/freetype2. It is arguable that it would have been better if the freetype2 headers were installed one level up, but I don't know what we'd break if we changed that now. On the other hand, an advantage of the way it is now is that it is less likely that an app will unintentionally use the XFree86-provided headers. Things that use imake that will get the build flags right. There are a few minor bugs in the way FREETYPE2INCLUDES is set, but they err on the side of redundancy. Actually, I'll take some of that back. For consistency with default freetype2 installations, we should put ft2build.h in ProjectRoot/include. However, you still need -I.../include/freetype2 to find the other headers. This is even documented in many versions of ft2build.h: /* prefix/include/freetype2 must be in your current inclusion path */ Comments in that file suggest that the FreeType people will be changing that structure in some future release to make that unnecessary. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Thu, Dec 11, 2003 at 04:41:47PM +0100, Michael Lampe wrote: David Dawes wrote: Do the gcc people give a reason for not allowing a system directory to be blessed with -I? I wouldn't call it a reason, but the manual puts it like this: (...) the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated. OK, I see. This is to prevent system directories being searched before directories containing gcc-specific replacements for system headers. Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of this '-I/usr/include': gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../../exports/include -I/usr/include -I/usr/include/freetype2 -I../../exports/include/X11 -I../.. -I../../exports/include -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I. -DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c In file included from charproc.c:123: /usr/include/error.h:26: parse error This is because gcc now includes /usr/include/error.h instead of error.h from programs/xterm. One should never put an explicit '-I/usr/include' or '-I/usr/local/include' in CFLAGS because this can lead to all sorts of strange behaviour. Never /usr/local/include?? That's ridiculous. How are you deciding which ones are allowed and which are not? If you use these and have local headers that might conflict, then you must put -I. in explicitly first. Then there is no ambiguity. I'd say that's what needs to happen for xterm/Imakefile. If someone wants to try builds that currently rely on -I/usr/include and make sure they work correctly when they are removed, please do, and send reports of any problems. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Re: freetype2 problems with cvs
Your second reply satisfies me. -jassi On Thu, 11 Dec 2003 David Dawes wrote : On Thu, Dec 11, 2003 at 10:21:21AM -0500, David Dawes wrote: On Thu, Dec 11, 2003 at 01:58:03PM -, jassi brar wrote: Hi all, http://www.mail-archive.com/[EMAIL PROTECTED]/msg04101.html In reference to the above link where david suggested some changes in the XFree86 source. Index: lib/Xft/Xft.h === RCS file: /home/x-cvs/xc/lib/Xft/Xft.h,v retrieving revision 1.32 diff -u -r1.32 Xft.h --- lib/Xft/Xft.h 25 Feb 2003 21:57:53 - 1.32 +++ lib/Xft/Xft.h 20 Nov 2003 22:03:55 - @@ -32,7 +32,8 @@ #define XftVersion XFT_VERSION #include stdarg.h -#include freetype/freetype.h +#include ft2build.h +#include FT_FREETYPE_H #include fontconfig/fontconfig.h #include X11/extensions/Xrender.h * when i try to crosscompile Qt/X11 with the /home/jassi/usr/X11R6/include headers generated by the compilation(cross) of Xfree86, the compiler cant find ft2build.h header file. So i have to explicitly mention the search path in the file. I think:: #include ft2build.h is XFree86 specific. Shudn't there be #include freetype2/ft2build.h so that any other software can figure out the headers easily. I mean the same for all the include's which can cause such problems. No, ft2build.h is correct. I you use the XFree86 installation, then you need -IProjectRoot/include/freetype2. It is arguable that it would have been better if the freetype2 headers were installed one level up, but I don't know what we'd break if we changed that now. On the other hand, an advantage of the way it is now is that it is less likely that an app will unintentionally use the XFree86-provided headers. Things that use imake that will get the build flags right. There are a few minor bugs in the way FREETYPE2INCLUDES is set, but they err on the side of redundancy. Actually, I'll take some of that back. For consistency with default freetype2 installations, we should put ft2build.h in ProjectRoot/include. However, you still need -I.../include/freetype2 to find the other headers. This is even documented in many versions of ft2build.h: /* prefix/include/freetype2 must be in your current inclusion path */ Comments in that file suggest that the FreeType people will be changing that structure in some future release to make that unnecessary. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: place internet call from your telephone line
How to place internet calls from your telephone line with low rate of $0.039/minute!? That's very easy! You can see details here: http://www.wotec88.com attachment: Yapjack_connect.JPG
Re: External FreeType build problem
David Dawes wrote:
Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of
this '-I/usr/include':
gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef
-I../../exports/include -I/usr/include -I/usr/include/freetype2
-I../../exports/include/X11 -I../.. -I../../exports/include
-I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I.
-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT
-DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error
This is because gcc now includes /usr/include/error.h instead of error.h
from programs/xterm.
One should never put an explicit '-I/usr/include' or
'-I/usr/local/include' in CFLAGS because this can lead to all sorts of
strange behaviour.
Never /usr/local/include?? That's ridiculous. How are you deciding which
ones are allowed and which are not?
The point is (I'm refering to gcc here) that /usr/local/include and
/usr/include are searched by default but in this order:
explicitly given includes first
/usr/local/include
/usr/lib/gcc-lib/i486-linux/2.95.3/../../../../i486-linux/include
/usr/lib/gcc-lib/i486-linux/2.95.3/include
/usr/include
In this order you normally get what you expect. For example, if you have
a more recent version of some library installed in /usr/local than in
/usr. Putting '-I/usr/include' in CFLAGS changes this order and produces
unexpected results, especially if you don't do it yourself but some
'foo-config --clags'. Another example is the above xterm build error.
I think this is the real reason why newer gcc's simply ignore
'-I/usr/include'
Besides, most sane 'foo-config' scripts contain for that very reason
something like this:
- from freetype-config -
if test $echo_cflags = yes ; then
cflags=-I${prefix}/include/freetype2
if test ${prefix}/include != /usr/include ; then ==
echo -I${prefix}/include $cflags
else
echo $cflags
fi
fi
if test $echo_libs = yes ; then
libs=-lfreetype -lz
if test ${exec_prefix}/lib != /usr/lib ; then ==
echo -L${exec_prefix}/lib $libs
else
echo $libs
fi
fi
-
'-I/usr/local/include' and '-L/usr/local/lib' seem, on second thought,
not to be a problem.
If you use these and have local headers that might conflict,
I guess every unix has /usr/include/error.h
then
you must put -I. in explicitly first. Then there is no ambiguity.
I'd say that's what needs to happen for xterm/Imakefile.
Would obviously solve the xterm build problem. As would removing
'-I/usr/include'.
If someone wants to try builds that currently rely on -I/usr/include and
make sure they work correctly when they are removed, please do, and send
reports of any problems.
Which systems do not search in /usr/include automatically?
Michael
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: External FreeType build problem
On Thu, Dec 11, 2003 at 06:08:11PM +0100, Michael Lampe wrote:
David Dawes wrote:
Even worse. Current CVS fails to build xterm with gcc 2.95.3 because of
this '-I/usr/include':
gcc -c -O2 -march=i686 -fomit-frame-pointer -ansi -pedantic -Wall
-Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef
-I../../exports/include -I/usr/include -I/usr/include/freetype2
-I../../exports/include/X11 -I../.. -I../../exports/include
-I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DNO_MESSAGE_CATALOG -DFUNCPROTO=15 -DNARROWPROTO -I.
-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT
-DXFREE86_FT2 -DPROJECTROOT=/opt/XFree86-4.4charproc.c
In file included from charproc.c:123:
/usr/include/error.h:26: parse error
This is because gcc now includes /usr/include/error.h instead of error.h
from programs/xterm.
One should never put an explicit '-I/usr/include' or
'-I/usr/local/include' in CFLAGS because this can lead to all sorts of
strange behaviour.
Never /usr/local/include?? That's ridiculous. How are you deciding which
ones are allowed and which are not?
The point is (I'm refering to gcc here) that /usr/local/include and
/usr/include are searched by default but in this order:
explicitly given includes first
/usr/local/include
/usr/lib/gcc-lib/i486-linux/2.95.3/../../../../i486-linux/include
/usr/lib/gcc-lib/i486-linux/2.95.3/include
/usr/include
My gcc 2.95.3 on FreeBSD searches only /usr/include implicitly.
In this order you normally get what you expect. For example, if you have
a more recent version of some library installed in /usr/local than in
/usr. Putting '-I/usr/include' in CFLAGS changes this order and produces
unexpected results, especially if you don't do it yourself but some
'foo-config --clags'. Another example is the above xterm build error.
I think this is the real reason why newer gcc's simply ignore
'-I/usr/include'
Besides, most sane 'foo-config' scripts contain for that very reason
something like this:
- from freetype-config -
if test $echo_cflags = yes ; then
cflags=-I${prefix}/include/freetype2
if test ${prefix}/include != /usr/include ; then ==
echo -I${prefix}/include $cflags
else
echo $cflags
fi
fi
if test $echo_libs = yes ; then
libs=-lfreetype -lz
if test ${exec_prefix}/lib != /usr/lib ; then ==
echo -L${exec_prefix}/lib $libs
else
echo $libs
fi
fi
-
We already do that for the freetype library. I'm not sure why we
didn't for the includes -- probably to try to make sure that the
correct freetype headers get included. Anyway, I'm testing a patch
that does this for freetype includes and installs our ft2build.h in a
better place.
Would obviously solve the xterm build problem. As would removing
'-I/usr/include'.
Not if there happened to be an error.h in one of the other -I
paths used in its build.
If someone wants to try builds that currently rely on -I/usr/include and
make sure they work correctly when they are removed, please do, and send
reports of any problems.
Which systems do not search in /usr/include automatically?
That's not the point. What needs to be tested is that a header
elsewhere (under one of the other -I paths) doesn't get erroneously
included instead of the one under /usr/include.
As I said, those interested in making sure that this works correctly
should test it and post the results here.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC1
David Dawes [EMAIL PROTECTED] To: [EMAIL PROTECTED] .Orgcc: Sent by: Subject: Re: XFree86 4.4.0 RC1 [EMAIL PROTECTED] ree86.Org 10/12/03 12:51 Please respond to devel On Wed, Dec 10, 2003 at 11:53:02AM +1000, [EMAIL PROTECTED] wrote: I have experienced a number of build problems on Solaris 2.5.1 x86. Most of these I believe would be problems on any system that does not provide an implementation of snprintf. Below are patches that enable 4.4.0 RC1 to build on our system. Many of them are reversals of changes that were made since 4.3.0. I don't know what the reasons for these changes were, so the author(s) of these changes may want to review the patches to see if they are appropriate or if some other changes are needed to fix this. The jmp changes are ones that I also had to make for 4.3.0. I think the replacement code I just got from the 4.2.0 or 4.2.1 versions, so quite possibly will have some effect on other systems. The jmp changes need to be conditional. The version you have will break most other systems. Is sigjmp_buf in none of the system headers? It is in /usr/include/setjmp.h, but only #ifndef _JBLEN (this is then defined later in the header) and (not #if defined(__STDC__) or #if __STDC__ == 0 || defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE)). I have yet to determine the status and cause of these conditions. I notice that some of these are defined in various config/cf/*.cf files, but not in sun.cf or xfree86.cf. In case it makes a difference, the changes between my host.def and the supplied xfree86.def are also included here. Note also that I have disabled BuildGlxExt since I could not build with this for 4.3.0. I know of one other person who had the same problem with Solaris 8. I will retest with #define BuildGlxExt NO commented out in the next day and post the results to the list. I've done test builds on 2.6 - 8, and didn't need to disable anything. *** programs/Xserver/hw/xfree86/os-support/shared/libc_wrapper.c.orig Fri Nov 21 15:59:54 2003 --- programs/Xserver/hw/xfree86/os-support/shared/libc_wrapper.c Tue Dec 9 15:32:46 2003 *** *** 1878,1883 --- 1878,1887 + #ifdef NEED_SNPRINTF + #include snprintf.c + #endif + #ifdef HAVE_SYSV_IPC int snprintf.c should get built in Xserver/os for platforms that need it. Is that not working for some reason? --- The problem is that Xserver/os is not included on the link line for xf86cfg. The following patch fixes it by using the same method as already used for STRL and others. *** programs/Xserver/hw/xfree86/xf86cfg/Imakefile.orig Sun Nov 2 14:45:43 2003 --- programs/Xserver/hw/xfree86/xf86cfg/Imakefile Wed Dec 10 17:26:29 2003 *** *** 17,22 --- 17,27 STRLOBJS = strlcat.o strlcpy.o #endif + #if !HasSnprintf + SNPRINTFSRCS = snprintf.c + SNPRINTFOBJS = snprintf.o + #endif + SRCS =\ accessx.c\ card-cfg.c\ *** *** 37,43 stubs.c\ $(TEXTSRC)\ vidmode.c\ ! xf86config.c
Re: XFree86 4.4.0 RC1
Perhaps only some MMX instructions are supported. I had no problems building this in XFree86 4.2.x. I remember looking at the differences with HasMMXSupport, among other things, between 4.2.x and 4.3.0 when first trying to build 4.3.0. From memory I'm fairly sure that HasMMXSupport was set to YES in 4.2.x (I don't have those build trees or log files anymore). It's also strange that somebody else reported the same problem on Solaris 8. I don't need the GlxExt so it doesn't bother me much, but I may try to look at this further at some stage if I have a chance. Regards, Lindsay Haigh David Dawes [EMAIL PROTECTED]To: [EMAIL PROTECTED] .Org cc: Sent by: Subject: Re: XFree86 4.4.0 RC1 [EMAIL PROTECTED] ree86.Org 11/12/03 03:32 Please respond to devel On Wed, Dec 10, 2003 at 02:04:47PM +1000, [EMAIL PROTECTED] wrote: The assembler in 2.5.1 probably doesn't support the MMX instructions. The solution is to make sure HasMMXSupport is set to NO for versions older than 2.6 in sun.cf. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC1
On Fri, Dec 12, 2003 at 09:44:05AM +1000, [EMAIL PROTECTED] wrote: Perhaps only some MMX instructions are supported. I had no problems building this in XFree86 4.2.x. I remember looking at the differences with HasMMXSupport, among other things, between 4.2.x and 4.3.0 when first trying to build 4.3.0. From memory I'm fairly sure that HasMMXSupport was set to YES in 4.2.x (I don't have those build trees or log files anymore). It's also strange that somebody else reported the same problem on Solaris 8. We'd need to see details of those problems. However, I traced through to see what would actually be using the Mesa ASM code on Solaris. The only thing that does in the default build is libOSMesa, but it wasn't actually including it because the ASM code has relocations that Solaris doesn't like when building shared libraries. So, it looks like Mesa's ASM code should be disabled by default on SVR4-based X86 platforms. I'll commit a patch that does that. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC1
On Fri, Dec 12, 2003 at 09:32:18AM +1000, [EMAIL PROTECTED] wrote: It is in /usr/include/setjmp.h, but only #ifndef _JBLEN (this is then defined later in the header) and (not #if defined(__STDC__) or #if __STDC__ == 0 || defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE)). I have yet to determine the status and cause of these conditions. I notice that some of these are defined in various config/cf/*.cf files, but not in sun.cf or xfree86.cf. In later versions of Solaris, the condition is: #if __STDC__ == 0 || defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE) || \ defined(__EXTENSIONS__) and we define __EXTENSIONS__ for our builds. Something like: #define _POSIX_C_SOURCE #include setjmp.h #undef _POSIX_C_SOURCE should work though. --- The problem is that Xserver/os is not included on the link line for xf86cfg. The following patch fixes it by using the same method as already used for STRL and others. OK, I'll commit that. The includes seem ok. The problem is in the link: rm -f xdm LD_RUN_PATH=/usr/X11R6/lib gcc -o xdm -O2 -fno-strength-reduce -DNO_ASM -Wall -Wpointer-arith -ansi -pedantic -L../../exports/lib auth.o daemon.o server.o dpylist.o dm.o error.o file.o netaddr.o reset.o resource.o protodpy.o policy.osession.o socket.o streams.o util.o xdmcp.o mitauth.o genauth.o access.o choose.o prngc.o rpcauth.o-lXmu -lXt -lSM -lICE -lXext -lX11 -lXau-lXdmcp -lrpcsvc -ldl-lXinerama -lresolv -lsocket -lnsl Undefined first referenced symbol in file vsnprintf error.o ld: fatal: Symbol referencing errors. No output written to xdm collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `xdm' The files in exports/lib that vsnprintf is defined in are libXmu.so and libXmuu.so (plus the links libXmu.so.6.2 and libXmuu.so.1.0). The '-lXmu' comes after the error.o that references it and doesn't appear to be UNDEFed in any of the included system libraries, so I'm not sure what the problem is. I'm guessing it is a problem with my environment, and not a fault in the XFree86 build. Perhaps the Xmu lib is being picked up from /usr/openwin/lib instead. I'll keep looking and any suggestions are welcome. Xmu provides an equivalent for snprintf, but not for vsnprintf. I'll apply the patch you sent for including snprintf.c. You did not comment on the os-support and fonttosfnt Imakefile changes. Were they ok? They are each just part of another change. The former wasn't OK, and the latter was. Everything should now be fixed except the setjmp.h issue. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
