Subject: RE: XFree86 on alpha.
To: Simon Burge <simonb@wasabisystems.com>
From: Andrew van der Stock <ajv@greebo.net>
List: port-alpha
Date: 01/15/2001 14:03:15
This is a multi-part message in MIME format.

------=_NextPart_000_0002_01C07EFB.E7966C60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Check the enclosed e-mail from Stuart Anderson. I haven't had the time to
test it yet, but it seems reasonable.

the best bet is for BUSmemcpy.S to be named differently beyond just the
suffix; ie
BUSmemcpy-x86.S and so on.

Andrew

-----Original Message-----
From: port-alpha-owner@netbsd.org [mailto:port-alpha-owner@netbsd.org]On
Behalf Of Simon Burge
Sent: Monday, 15 January 2001 09:15
To: Dave Huang
Cc: port-alpha@netbsd.org
Subject: Re: XFree86 on alpha.


Dave Huang wrote:

> I forgot to keep a log, but "make World" seemed to work. However, when I
> did a "make install", it decided it needed to make all in
> xsrc/xfree/xc/programs/Xserver/hw/xfree86/os-support/misc and that died
> with:
>
> making all in programs/Xserver/hw/xfree86/os-support/misc...
> gcc   -c -traditional-cpp BUSmemcpy.S
> BUSmemcpy.S:40: assyntax.h: No such file or directory
>
> Make is trying to build BUSmemcpy.o from the .S file instead of the .c
> file. Same problem with IODelay.o and SlowBcopy.o. I moved the .S files
> out of the way, and it seemed to be happy with that.

Ahh, yes.  Dang, forgot to mention that.  I'm not sure how best to
handle this - whether a .c.o suffix rule will help, or something more
fancy.  Any make(1) experts want to take a crack at this?

> So anyways, I got
> everything built and installed, and did an "X -configure", which crashed
> and produced the following log file:

I hadn't tried "X -configure", but at least you only appear to get a
core dump - I just tried this and it locked up my pc164 :-(  I'll start
looking into this.  What model Alpha do you have?

All I can suggest right now is to make an XF86Config file (after
rebuilding the Xserver - see below) with the right "Device" section
and try running the Xserver directly.  I'll send mine to the list
in a different message that you can use as a template.

> As it says, I have a Trident 9660 video card, which isn't in the list of
> video drivers... is Trident not supported yet?

There's certainly a mention of "tgui9660" in some files under
xsrc/xfree/xc/programs/Xserver/hw/xfree86/drivers/trident, so you
should be right there.  Ahh, it doesn't appear to be listed in
xfree86.cf - could you try adding "trident" to the list around
line 438 of .../xsrc/xfree/xc/config/cf/xfree86.cf - you'll have
to re-run a lot of the build.  If you're impatient, then maybe
you could get away with something like:

	cd .../xsrc/xfree/xc
	make -f xmakefile   -n Makefiles
	cd programs/Xserver
	make includes
	make depend
	make

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD CDs, Support and Service:    http://www.wasabisystems.com/

------=_NextPart_000_0002_01C07EFB.E7966C60
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

Reply-To: <devel@XFree86.Org>
From: "Stuart Anderson" <anderson@metrolink.com>
Sender: <owner-devel@XFree86.Org>
To: <devel@XFree86.Org>
Subject: Re: Build problem on NetBSD/alpha
Date: Fri, 12 Jan 2001 01:35:30 +1100
Message-ID: <Pine.BSF.4.21.0101110931040.39789-100000@trantor.sc.metrolink.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20010111141417.50257.qmail@eeoth.pair.com>
Importance: Normal

I saw this on NetBSD/arm also, so it's probably not Alpha specific.
I think I determined that the default rules that are built into make tried
too hard to assemble the .S file. I found this laying around in that tree
so, but it is obviously a workaround, rather than a solution.


Index: NetBSD.cf
===================================================================
RCS file: /home/x-cvs/xc/config/cf/NetBSD.cf,v
retrieving revision 3.87
diff -r3.87 NetBSD.cf
514a515,520
>
> #ifdef Arm32Architecture
> #define NormalAsmObjectRule()
@@\
> .S.o:
@@\
>       echo override
> #endif

It's been a while since I touched this, but I may have ended up building
those couple of .o file by hand in addition to this workaround.

On Thu, 11 Jan 2001 ajv@eeoth.pair.com wrote:

> Hi there,
>
> this is the last build problem before I have a compiling X server
> on the alpha care of some patches via a friend.
>
> In programs/Xserver/hw/xfree86/os-support/misc, the .S files
> are trying to build on the Alpha, even though the XSRC explicitly
> mentions BUSmemcpy.c and friends.
>
> >From the generated Makefile:
>
> XSRCS = BUSmemcpy.c IODelay.c SlowBcopy.c
> XOBJS = BUSmemcpy.o IODelay.o SlowBcopy.o
>
> If I rename the .S files, the misc directory "make" works, in fact
> the Xserver tree builds without error (but with plenty of warnings)
>
> The imake is the 4.0.2 imake (I'm using 4.0.2 as the basis of
> my merge), the make is the NetBSD-1.5 make.
>
> Andrew
>


                                Stuart

Stuart R. Anderson                               anderson@metrolink.com

Metro Link Incorporated                          South Carolina Office
5807 North Andrews Way                           129 Secret Cove Drive
Fort Lauderdale, Florida 33309                   Lexington, SC 29072
voice: 954.660.2500                              voice: 803.951.3630
fax:   954.938.1982                              SkyTel: 800.405.3401
http://www.metrolink.com/                        XFree86 Core Team


------=_NextPart_000_0002_01C07EFB.E7966C60--