On Mon, 21 May 2001, Brian Paul wrote:

>> >I tried building the trunk code (according to the guide) and have run
>> >into a raft of errors in the Mesa portion of the tree. Some sample error
>> >messages:
>> >
>> >gcc -E  common_x86_asm.S > common_x86_asm.s
>> >common_x86_asm.S:37:22: assyntax.h: No such file or directory
>> >common_x86_asm.S:38:33: common_x86_features.h: No such file or directory
>> >make[6]: *** [common_x86_asm.s] Error 1
>> >...
>> >gcc -E  x86_cliptest.S > x86_cliptest.s
>> >x86_cliptest.S:26:22: assyntax.h: No such file or directory
>> >x86_cliptest.S:27:23: clip_args.h: No such file or directory
>> >make[6]: *** [x86_cliptest.s] Error 1
>> >gcc -E  x86_vertex.S > x86_vertex.s
>> >x86_vertex.S:1:22: assyntax.h: No such file or directory
>> >make[6]: *** [x86_vertex.s] Error 1
>> >gcc -E  x86_xform_masked2.S > x86_xform_masked2.s
>> >x86_xform_masked2.S:26:22: assyntax.h: No such file or directory
>> >x86_xform_masked2.S:27:24: xform_args.h: No such file or directory
>> >
>> >It would appear that the header files are not being put in the
>> >appropriate locations. Is the build on the trunk known to be broken?
>
>
>I don't think the header files are the problem.  I just rebuilt
>lib/GL/ on my DRI trunk and it worked fine.  However, the commands
>used to build the assembly sourece files look different.  Here's
>how common_x86_asm.S is assembled into common_x86_asm.o on my system:
>
>rm -f common_x86_asm.i
>/lib/cpp -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE
>-D_BSD_SOURCE -D_SVID_SOURCE  -D_GNU_SOURCE   -D__ELF__ -DMALLOC_0_RETURNS_NULL 
>-DGLXEXT
>-DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA  -DUSE_X86_ASM
>-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_KATMAI_ASM -I../../../../../exports/include
>-I../../../../../include/extensions -I../../../../../extras/Mesa/src
>-I../../../../../extras/Mesa/src/X86   common_x86_asm.S | \
>grep -v '^\#' > common_x86_asm.i
>rm -f common_x86_asm.o
>as -o common_x86_asm.o common_x86_asm.i
>rm -f common_x86_asm.i
>
>It looks like your systems are doing:
>
>gcc -E  common_x86_asm.S > common_x86_asm.s

Yep, that caught me as strange too, so I added to my host.def:

#define PreProcessCmd           cpp


And the problem went away...


>The Imakefile rule 'ObjectFromAsmSource' is used to build the assembly source
>files.  This rule is defined in xc/config/cf/xf86.rules as:
>
>
>#ifndef ObjectFromAsmSource
>#define ObjectFromAsmSource(src,flags)                                 @@\
>                                                                       @@\
>src.o:  src.S                                                          @@\
>       AssembleObject(flags)                                           @@\
>                                                                       @@\
>src.i:  src.S                                                          @@\
>       CPPOnlyAsm(src,flags)                                           @@\
>                                                                       @@\
>depend:: src.S
>#endif
>
>Apparently the first rule is being used on your system while the second
>one is being used on mine.  I'd have to study this more to figure out
>what's going on.
>
>Could one of you (John or Mike) send me your xc/config/cf/host.def file?

I don't have it anymore...  It is dynamically generated at build
time from our RPM specfile.  Adding the PreProcessCmd in there
seems to fix it.  Kindof a hack IMHO though as the rest of the
tree builds fine without it.  If you'd like, I can try to
reproduce the situation again as I still have the older RPM
kicking around.


>> Yes, I am experiencing the exact same problem trying to build
>> 4.0.99.900 in rawhide.  No idea what is causing it.  The stupid
>> thing is that if you cd into that directory and execute each
>> failed "gcc -E  common_x86_asm.S > common_x86_asm.s" command by
>> hand, it WORKS. The header files ARE in the directory also, which
>> makes it all the weirder.  Since it is only x86 related, alpha
>> and ia64 builds proceed however to die at another spot related to
>> Xft.  A parse error just before FT_Library in xftfreetype.c
>>
>> Anyone else having either of these problems?
>
>Is this asm problem happening in xc/lib/GL/ or xc/programs/Xserver/GL/,
>or both places?

Just in xc/lib/GL/ for me at least..  I've got complete build
logs if you'd like to examine them just let me know, and I can
get you both the logs and the host.def for alpha/i386/ia64 on my
ftp dir, as well as the src.rpm if you'd like.

Fory anyone daring:
Our current 4.0.99.900-0.2.0 rpm is building now, and available
for the brave at ftp://people.redhat.com/mharris/testing

I must warn anyone downloading that package that it is an ALPHA
RPM release of ALPHA software (for alpha(no pun intended), i386,
ia64).  That means that it will most likely explode into a
million pieces, and will very likely hose your existing working X
setup, wipe out your machine, and generally cause world unrest.
Use at own risk.  Also, DRI will *NOT* work, so no need to tell
me - I know.

That said, please report any non-obvious bugs against rawhide in
bugzilla - emailed bug reports go to /dev/null.  "If it's not in
bugzilla, its not a bug."

Thanks,
TTYL

----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc.                    Ontario, Canada, P6C 5B3
http://www.redhat.com           Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS:      ftp://people.redhat.com/mharris/testing


_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to