Compilation of oricono_cs v.12b in RH's 2.4.18-5

[Richard Michael]

Hi Everyone,

I have a Toshiba Satellite 3000, with what seems to be an orinoco(_cs)
compatible wireless card (manfid 0x0156, 0x0002);  Toshiba can't tell me
exactly which chipset it is, but indicated that it's probably a Lucent's
Silver.

(Satellite 3000 PS300C-03ZET to be exact, maybe someone out there can
tell _me_?)

I've been trying to get this card going.  I've switched from the kernel
PCMCIA yenta_socket services to Hinds' standalone i82365 module (I read
the kernel i82365 only supports ISA-PCMCIA bridges, and I would guess
that I have either a PCI-PCMCIA or a PCI-Cardbus bridge, hence the use
of the standalone).

I've tried building the newest orinoco package 12b.  It compiles fine,
but the _cs module has an unresolved symbol.  Now, I'm not a total
newbie to module building/symbol resolution, but here's a problem that
I don't know how to fix.

/lib/modules/2.4.18-5/pcmcia/orinoco_cs.o: unresolved symbol 
register_pccard_driver_R583d4ed2

/lib/modules/2.4.18-5/pcmcia/orinoco_cs.o: unresolved symbol
unregister_pccard_driver_Rdb348cd2

I think this is a very particular problem, related to the linker and the
kernel versions or glibc or something like that?  I'm guessing that it's
something like this because I can find those symbols define in the
pcmcia_cs ds.h file, but without the alphanumeric suffices.

Admittedly, I've compiled and added RH's 2.4.18-5 kernel from 7.3 to this
system, using the glibc-2.2.4 from 7.2.  Though, after the change in
kernel headers, I rebuilt glibc and then tried rebuilding orinoco.
Still no go.

Can someone who knows more about module building than I do enlighten me
about the alphanumeric suffix on the end of the symbol name?

Eventually, I'm trying to talk to an SMC Barricade v1.41 with WEP 
(hopefully 128bit, but maybe the silver chipset only does 64bit or some 
lesser value?), unless someone heads me off and tells me now that it won't
work. :)

Maybe this is really a pcmcia-cs issue.. if so, sorry for the noise!

Much thanks,
Richard