SDL install: Alpha success, Intel failure!

[Reinoud_Lamberts]

Hi,

First: the ezmlm thing apparently won’t let me grab the entire list
archive at once, and the idea of requesting all messages one by one
brings tears to my eyes… So I haven’t read anything posted here. If
this annoys you (as it annoys me), please let me know how to grab the
archive.

That said - SDL looks like a gift from heaven! Really nice, I plan to
have a fast voxel engine running on it soon.

Alpha-----
SDL(-0.6j) runs like a charm on Alpha, even though this isn’t
supported. I tested it on a Digital XL-300 (XLT) 21164 system with RH5
and Linux kernel 2.1.86. The only problems I encountered were:

• glibc autodetection failure: Configure.sh checks if GLIBC is
  defined, which it apparently isn’t, while glibc is there. Maybe this
  is because Alpha Linux always uses glibc. Note that this is with
  gcc2.7.2.3 (didn’t try it with egcs). (And note that failing the glibc
  check it tries to compile some x86 assembly on the Alpha.

• warnings: there are a few warnings, most likely related to 64-bit
  pointer/long problems. Included below (it all works so far, so I
  didn’t look at the details).

The tests and the warp example run fine. (I couldn’t run the audio
tests, having no sound card/driver installed on the Alpha). I couldn’t
compile the draw example (it couldn’t find things in includes).

Intel

SDL won’t run on my Intel box! This is a Pentium which runs RH4.0 (!)
with a 2.0.18 kernel. Maybe the problem is related to the old kernel or
old libs (it has libc 5.3.12).

When I try to run a SDL app, it produces something like:

… …
./graywin: can’t resolve symbol ‘memset’
./graywin: can’t resolve symbol ‘memset’
./graywin: can’t resolve symbol ‘__errno_location’
./graywin: can’t resolve symbol ‘_exit’
./graywin: can’t resolve symbol ‘___brk_addr’
./graywin: can’t resolve symbol ‘__environ’
Couldn’t initialize SDL: Failed loading libSDLx11.so: Unable to resolve symbol

So it seems unable to load the lib… It’s there allright. Maybe
this points to the problem:

ldd graywin
libdl.so.1 => /lib/libdl.so.1.7.14

On the Alpha ldd lists more useful stuff:

ldd graywin
libdl.so.2.1 => /lib/libdl.so.2.1 (0x0000020000002000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0000020000106000)
libc.so.6.1 => /lib/libc.so.6.1 (0x000002000021a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020001000000)

Anybody knows what went wrong here?

Later,

• Reinoud

---

Alpha make warnings

make
cd obj && make
make[1]: Entering directory /home/reinoud/down/SDL-0.6j/obj' cc -I../include -I../directx/include -I/usr/openwin/include -c load.c -o load.o load.c: In function SetError’:
load.c:81: warning: type mismatch in implicit declaration for built-in function strlen' for dir in x11; do \ (cd $dir && make); \ done make[2]: Entering directory /home/reinoud/down/SDL-0.6j/obj/x11’
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL.c -o SDL.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_RLEaccel.c -o SDL_RLEaccel.o
SDL_RLEaccel.c: In function SDL_RLEClip': SDL_RLEaccel.c:122: warning: type mismatch in implicit declaration for built-in function memcpy’
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_active.c -o SDL_active.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_audio.c -o SDL_audio.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_audiomem.c -o SDL_audiomem.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_bmp.c -o SDL_bmp.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_cursor.c -o SDL_cursor.o
SDL_cursor.c: In function SDL_DrawCursor': SDL_cursor.c:511: warning: type mismatch in implicit declaration for built-in function memcpy’
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_endian.c -o SDL_endian.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_error.c -o SDL_error.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_events.c -o SDL_events.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_keyboard.c -o SDL_keyboard.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_mixer.c -o SDL_mixer.o
SDL_mixer.c: In function SDL_QueueAudio': SDL_mixer.c:107: warning: type mismatch in implicit declaration for built-in function memcpy’
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_mouse.c -o SDL_mouse.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_pixels.c -o SDL_pixels.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_quit.c -o SDL_quit.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_surface.c -o SDL_surface.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_video.c -o SDL_video.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_wave.c -o SDL_wave.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_mutex.c -o SDL_mutex.o
SDL_mutex.c: In function SDL_CreateMutex': SDL_mutex.c:43: warning: cast to pointer from integer of different size cc -O2 -fomit-frame-pointer -I../../include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_sysaudio.c -o SDL_sysaudio.o cc -O2 -fomit-frame-pointer -I../../include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_thread.c -o SDL_thread.o SDL_thread.c: In function SDL_CreateThread’:
SDL_thread.c:88: warning: cast to pointer from integer of different size
SDL_thread.c:94: warning: cast to pointer from integer of different size
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_timer.c -o SDL_timer.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_eventloop.c -o SDL_eventloop.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_sysmouse.c -o SDL_sysmouse.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_sysvideo.c -o SDL_sysvideo.o
cc -O2 -fomit-frame-pointer -I…/…/include -DSDL_FUNCTION_DEFS -DXMT_UNSAFE -DSDL_USE_PTHREADS -D_REENTRANT -c SDL_syswm.c -o SDL_syswm.o
SDL_syswm.c: In function SDL_SYS_SetWMIcon': SDL_syswm.c:72: warning: type mismatch in implicit declaration for built-in function memcpy’
cc -shared -o libSDLx11.so.0.6 SDL.o SDL_RLEaccel.o SDL_active.o SDL_audio.o SDL_audiomem.o SDL_bmp.o SDL_cursor.o SDL_endian.o SDL_error.o SDL_events.o
SDL_keyboard.o SDL_mixer.o SDL_mouse.o SDL_pixels.o SDL_quit.o SDL_surface.o SDL_video.o SDL_wave.o SDL_mutex.o SDL_sysaudio.o SDL_thread.o SDL_timer.o
SDL_eventloop.o SDL_sysmouse.o SDL_sysvideo.o SDL_syswm.o -L/usr/X11R6/lib -lX11 -lXext
make[2]: Leaving directory /home/reinoud/down/SDL-0.6j/obj/x11' ar crv libSDL.a load.o a - load.o /usr/bin/ranlib libSDL.a make[1]: Leaving directory /home/reinoud/down/SDL-0.6j/obj’
obj/x11/libSDLx11.so.0.6 → lib/libSDLx11.so.0.6
lib/libSDLx11.so.0.6 ← lib/libSDLx11.so
obj/libSDL.a → lib/libSDL.a

---

[Michael_Samuel]

Hi,

First: the ezmlm thing apparently won’t let me grab the entire list
archive at once, and the idea of requesting all messages one by one
brings tears to my eyes… So I haven’t read anything posted here. If
this annoys you (as it annoys me), please let me know how to grab the
archive.

I’m trying to write a mailing list archive program, but I can’t get one
that’s secure enough…

Serves me right for learning about Unix security before programming

Anyway, there are a couple of ways you can grab the archive:

1. Ask me for the tarball (I’ll put it online soon, possibly via a
   cron job???)

2. Run a shell script to automaticly send out lots of requests. Ezmlm
   couldn’t care less about the message body, so just write a shell script
   using tcpclient that talks directly to mail.surfnetcity.com.au:25 (Being
   very careful to end lines with \r\n and not having any stray newlines) and
   send a message to each of the get addresses. You may wish to specify a
   different return address, unless you want it all in your main inbox.

The second option would be a good one for a quite Sunday

That said - SDL looks like a gift from heaven! Really nice, I plan to
have a fast voxel engine running on it soon.

Alpha

SDL(-0.6j) runs like a charm on Alpha, even though this isn’t
supported. I tested it on a Digital XL-300 (XLT) 21164 system with RH5
and Linux kernel 2.1.86. The only problems I encountered were:

• glibc autodetection failure: Configure.sh checks if GLIBC is
  defined, which it apparently isn’t, while glibc is there. Maybe this
  is because Alpha Linux always uses glibc. Note that this is with
  gcc2.7.2.3 (didn’t try it with egcs). (And note that failing the glibc
  check it tries to compile some x86 assembly on the Alpha.

Hehehe… similar to the PPC problem, but backwards (We had to disable
glibc support and disable the clone.S, basicly removing threads support)

• warnings: there are a few warnings, most likely related to 64-bit
  pointer/long problems. Included below (it all works so far, so I
  didn’t look at the details).

The tests and the warp example run fine. (I couldn’t run the audio
tests, having no sound card/driver installed on the Alpha). I couldn’t
compile the draw example (it couldn’t find things in includes).

This being said, did the audio tests just keep on running, or did they
detect the lack of sound?

I’m still trying to find the answer to my problem here, and I can’t find
anyboy else with a broken audio driver

Intel

SDL won’t run on my Intel box! This is a Pentium which runs RH4.0 (!)
with a 2.0.18 kernel. Maybe the problem is related to the old kernel or
old libs (it has libc 5.3.12).

When I try to run a SDL app, it produces something like:

… …
./graywin: can’t resolve symbol ‘memset’
./graywin: can’t resolve symbol ‘memset’
./graywin: can’t resolve symbol ‘__errno_location’
./graywin: can’t resolve symbol ‘_exit’
./graywin: can’t resolve symbol ‘___brk_addr’
./graywin: can’t resolve symbol ‘__environ’
Couldn’t initialize SDL: Failed loading libSDLx11.so: Unable to resolve symbol

So it seems unable to load the lib… It’s there allright. Maybe
this points to the problem:

ldd graywin
libdl.so.1 => /lib/libdl.so.1.7.14

Huh??? Where’s libc!?

Try doing a make clean and rebuilding it. Something really strange
there… (Do you have a libc shared lib??)

On the Alpha ldd lists more useful stuff:

ldd graywin
libdl.so.2.1 => /lib/libdl.so.2.1 (0x0000020000002000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0000020000106000)
libc.so.6.1 => /lib/libc.so.6.1 (0x000002000021a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0000020001000000)

Anybody knows what went wrong here?

Very strange. Can you do a ‘ldconfig -v | grep libc’ on the Intel box?

Michael Samuel,

Surf-Net City - Internet Cafe and Internet Service Providers
Phone: +61 3 9593-9977
E-Mail:
WWW: http://www.surfnetcity.com.au/~michael/On Sun, 17 May 1998, Reinoud Lamberts wrote:

[Reinoud_Lamberts]

Michael Samuel wrote:

1. Ask me for the tarball

Please, mail me a tarball ;-).

This being said, did the audio tests just keep on running, or did they
detect the lack of sound?

They detected it.

Huh??? Where’s libc!?

Try doing a make clean and rebuilding it.

Did a make spotless (make clean doesn’t do much), rebuilt - nothing
changes.

Very strange. Can you do a ‘ldconfig -v | grep libc’ on the Intel box?

Sure:

/sbin/ldconfig -v | grep libc
/sbin/ldconfig: can’t unlink /etc/ld.so.cache~ (Permission denied)
libcurses.so.0 => libcurses.so.0.1.2
libc.so.4 => libc.so.4.7.2
libcom_err.so.2 => libcom_err.so.2.0
libc.so.5 => libc.so.5.3.12

I don’t understand what’s going wrong. Is my libdl.so.1.7.14 too old?
This really is an old install. Of course, installing a newer Linux
dist will likely solve these problems, but then there may be others
running into the same problems…

Anyway, thanks,

• Reinoud

[slouken]

Huh??? Where’s libc!?

Try doing a make clean and rebuilding it.

Did a make spotless (make clean doesn’t do much), rebuilt - nothing
changes.

Do you have a way for me to log into the system and check it out?
It does look like libc is not being linked, which I can only think
would be caused by a misconfigured (or misdetected) compiler.

Also, try explicitly adding -lc to the link line.

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

[Reinoud_Lamberts]

Sam Lantinga wrote:

Do you have a way for me to log into the system and check it out?

That’s a bit messy, my ISP uses dynamic IP addresses. If you’re online
right now I could set things up for you.

That said, I should install something new. My system is ancient,
and scarred by countless hacks and changes.

Also, try explicitly adding -lc to the link line.

Will do. Thanks!

• Reinoud

[Reinoud_Lamberts]

Sam Lantinga wrote:

‘talk slouken at devolution.com’

Sorry, I have pretty bad CTS, talk-ing really kills my wrists…
I have to type slowly.

Also, try explicitly adding -lc to the link line.

Will do. Thanks!

Let me know if it works.

It doesn’t. I don’t understand, but then this particular system
hasn’t been used for development for quite a while.

Maybe we should let it rest. If you still want to have a look
on this system, mail me, and I’ll give you access. But your time
might be better spent fixing the little things for Alpha I mailed
about :-). That feels more constructive.

Thanks again,

• Reinoud

[Reinoud_Lamberts]

Sam Lantinga wrote:

Those are just include warnings. Not a problem.

Well, these 64-bit-isms are potentially dangerous:

SDL_mutex.c: In function `SDL_CreateMutex’:
SDL_mutex.c:43: warning: cast to pointer from integer of different size

SDL_thread.c: In function `SDL_CreateThread’:
SDL_thread.c:88: warning: cast to pointer from integer of different size
SDL_thread.c:94: warning: cast to pointer from integer of different size

I should have highlighted them in the first place…

Also, there is the glibc detection failure (resulting in an attempt
to use x86 ass. code :). If you fix these bits, SDL will compile
cleanly on Alpha, which is way cool!

See ya!

Yeah, who knows :). Thanks and happy hacking,

• Reinoud

[Michael_Samuel]

Michael Samuel wrote:

1. Ask me for the tarball

Please, mail me a tarball ;-).

Well, I’ve done better (kinda

Check out http://cliff.surfnetcity.com.au/archives/SDL/

I’m sure that njh and sam are very embarrased about 0/01.html and
0/02.html

grin

This currently gets updated once-every-when-I-remember, until I get a few
issues sorted out in the shell script. (Locking, and getting the subject
line as the title)

But, the prog that converts it to HTML is a hacked version of another
program I wrote, and should work fine.

This being said, did the audio tests just keep on running, or did they
detect the lack of sound?

They detected it.

Damnit! I can reproduce a problem on 2 very different machines, whose only
thing in common is Linux, and the clock speed (603ev/200 + P200MMX :-),
but nobody else has it!

Worse yet, it’s present in Maelstrom (nothing else, though), but nobody
else has reported it to Sam.

Huh??? Where’s libc!?

Try doing a make clean and rebuilding it.

Did a make spotless (make clean doesn’t do much), rebuilt - nothing
changes.

Didn’t think it would, but it was worth a try

Very strange. Can you do a ‘ldconfig -v | grep libc’ on the Intel box?

Sure:

/sbin/ldconfig -v | grep libc
/sbin/ldconfig: can’t unlink /etc/ld.so.cache~ (Permission denied)
libcurses.so.0 => libcurses.so.0.1.2
libc.so.4 => libc.so.4.7.2
libcom_err.so.2 => libcom_err.so.2.0
libc.so.5 => libc.so.5.3.12

I don’t understand what’s going wrong. Is my libdl.so.1.7.14 too old?
This really is an old install. Of course, installing a newer Linux
dist will likely solve these problems, but then there may be others
running into the same problems…

I have libdl.so.1.9.5 and libdl-2.0.7.so on my system. Is it a big deal
to upgrade your libdl?

Michael Samuel,

Surf-Net City - Internet Cafe and Internet Service Providers
Phone: +61 3 9593-9977
E-Mail:
WWW: http://www.surfnetcity.com.au/~michael/On Mon, 18 May 1998, Reinoud Lamberts wrote:

[Reinoud_Lamberts]

Michael Samuel wrote:

Check out http://cliff.surfnetcity.com.au/archives/SDL/

Okay, I’ll settle for that. Thanks!

I have libdl.so.1.9.5 and libdl-2.0.7.so on my system. Is it a big deal
to upgrade your libdl?

Well, no, but maybe it’s a better plan to install a complete fresh
dist sometime soon. In the mean time it works on the Alpha (which
has everything new and smokes the Pentiums anyway:), so…

• Reinoud

[Reinoud_Lamberts]

Sam Lantinga wrote:

SDL_thread.c: In function `SDL_CreateThread’:
SDL_thread.c:88: warning: cast to pointer from integer of different size
SDL_thread.c:94: warning: cast to pointer from integer of different size

This might be okay. Give me the new error line when I release SDL 0.6k

Will do.

I should have highlighted them in the first place…

I saw them.

Rrright :-).

It’s hard to detect glibc if the header files don’t define GLIBC

They do define alpha (see below), and all Alpha Linux machines
always are glibc ones, so…

This is almost a prerequisite, and means that your version of glibc
may be old

No way, not on the Alpha :-).

, or maybe they define a different symbol that I should be
aware of.

I think the alpha symbol says enough.

cat >foo.c <<EOF
#include <stdlib.h>
main() { exit(0); }
EOF
gcc -v -o foo foo.c
rm foo foo.c

Cool, I didn’t know it was that easy to see all that. Below is
the output for both gcc2 and egcs (intentionally wrapped):

gcc -v -o foo foo.c
Reading specs from /usr/lib/gcc-lib/alpha-redhat-linux/2.7.2.3/specs
gcc version 2.7.2.3
/usr/lib/gcc-lib/alpha-redhat-linux/2.7.2.3/cpp -lang-c -v -undef
-D__GNUC__=2 -D__GNUC_MINOR__=7 -D__alpha -D__alpha__ -D__linux__
-D__linux -D_LONGLONG -Dlinux -Dunix -D__ELF__ -D__alpha -D__alpha__
-D__linux__ -D__linux -D_LONGLONG -D__linux__ -D__unix__ -D__ELF__
-D__linux -D__unix -Asystem(linux) -Acpu(alpha) -Amachine(alpha)
-D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C foo.c /tmp/cca00258.i
GNU CPP version 2.7.2.3 (Alpha Linux/ELF)
#include “…” search starts here:
#include <…> search starts here:
/usr/local/include
/usr/alpha-redhat-linux/include
/usr/lib/gcc-lib/alpha-redhat-linux/2.7.2.3/include
/usr/include
End of search list.
/usr/lib/gcc-lib/alpha-redhat-linux/2.7.2.3/cc1 /tmp/cca00258.i
-quiet -dumpbase foo.c -version -o /tmp/cca00258.s
GNU C version 2.7.2.3 (Alpha Linux/ELF) compiled by GNU C version 2.7.2.3.
as -nocpp -o /tmp/cca002581.o /tmp/cca00258.s
ld -m elf64alpha -G 8 -O1 -dynamic-linker /lib/ld-linux.so.2 -o foo
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o
-L/usr/lib/gcc-lib/alpha-redhat-linux/2.7.2.3 /tmp/cca002581.o -lgcc
-lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o

gcc -v -o foo foo.c
Reading specs from
/usr/local/egcs/lib/gcc-lib/alphaev5-unknown-linux-gnu/egcs-2.90.23/specs
gcc version egcs-2.90.23 980102 (egcs-1.0.1 release)
/usr/local/egcs/lib/gcc-lib/alphaev5-unknown-linux-gnu/egcs-2.90.23/cpp
-lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=90 -D__alpha
-D__alpha__ -D__linux__ -D__linux -D_LONGLONG -Dlinux -Dunix -D__ELF__
-D__alpha -D__alpha__ -D__linux__ -D__linux -D_LONGLONG -D__linux__
-D__unix__ -D__ELF__ -D__linux -D__unix -Asystem(linux) -Acpu(alpha)
-Amachine(alpha) -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C foo.c
/tmp/cca00290.i
GNU CPP version egcs-2.90.23 980102 (egcs-1.0.1 release) (Alpha Linux/ELF)
#include “…” search starts here:
#include <…> search starts here:
/usr/local/include
/usr/local/egcs/alphaev5-unknown-linux-gnu/include
/usr/local/egcs/lib/gcc-lib/alphaev5-unknown-linux-gnu/egcs-2.90.23/include
/usr/include
End of search list.
/usr/local/egcs/lib/gcc-lib/alphaev5-unknown-linux-gnu/egcs-2.90.23/cc1
/tmp/cca00290.i -quiet -dumpbase foo.c -version -o /tmp/cca00290.s
GNU C version egcs-2.90.23 980102 (egcs-1.0.1 release)
(alphaev5-unknown-linux-gnu) compiled by GNU C version egcs-2.90.23
980102 (egcs-1.0.1 release).
as -nocpp -o /tmp/cca002901.o /tmp/cca00290.s
/usr/local/egcs/lib/gcc-lib/alphaev5-unknown-linux-gnu/egcs-2.90.23/ld
-m elf64alpha -G 8 -O1 -dynamic-linker /lib/ld-linux.so.2 -o foo
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o
-L/usr/local/egcs/lib/gcc-lib/alphaev5-unknown-linux-gnu/egcs-2.90.23
-L/usr/local/egcs/lib /tmp/cca002901.o -lgcc -lc -lgcc
/usr/lib/crtend.o /usr/lib/crtn.o

If you want any more info, let me know…

• Reinoud