Linux-Development-Sys Digest #18, Volume #8 Thu, 13 Jul 00 03:13:13 EDT
Contents:
linker problem? ("Peter Huang")
Re: Microsoft's new ".NET" (Tim Roberts)
Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC (MWRon)
Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC
([EMAIL PROTECTED])
Re: Why Does Linux Arp All The Time? (David Highley)
Re: are PCI drivers char drivers? (Zoran Cutura)
Re: Why Does Linux Arp All The Time? (Kaz Kylheku)
Re: linker problem? (Zoran Cutura)
----------------------------------------------------------------------------
From: "Peter Huang" <[EMAIL PROTECTED]>
Subject: linker problem?
Date: Wed, 12 Jul 2000 18:28:39 -0700
Hi
I'm trying to build a device driver module on Kernel version 2.2.14-5.0 and
I am running into some problems that appears to be linker related.
these lines appeared
/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
/tmp/cc3T2jO9.o: In function `init_module':
/tmp/cc3T2jO9.o(.text+0x11): undefined reference to `register_chrdev'
/tmp/cc3T2jO9.o(.text+0x23): undefined reference to `printk'
/tmp/cc3T2jO9.o(.text+0x36): undefined reference to `printk'
/tmp/cc3T2jO9.o(.text+0x3e): undefined reference to `pcibios_present'
/tmp/cc3T2jO9.o(.text+0x5d): undefined reference to `pci_find_device'
/tmp/cc3T2jO9.o(.text+0x91): undefined reference to `printk'
/tmp/cc3T2jO9.o: In function `testpci_detect_pci':
/tmp/cc3T2jO9.o(.text+0xb3): undefined reference to `pcibios_present'
/tmp/cc3T2jO9.o(.text+0xdf): undefined reference to `pci_find_device'
/tmp/cc3T2jO9.o(.text+0x109): undefined reference to `printk'
when I tried to build with this makefile
LINUX_DIR=/usr/src/linux
CC=gcc
OPT= -D__KERNEL__ -DMODULE -O3 -I$(LINUX_DIR)/include
CFLAGS=$(OPT) -Wall -Werror
TARGETS=testpci
all:: $(TARGETS)
testpci: testpci.c
$(CC) $(CFLAGS) -o testpci testpci.c
........
It appears that the linker can't find any kernel functions and even tried to
look for the main()
function. Can any one give me some suggestion on what might be wrong? On the
testpci.c file itself, I included most of
the header files such as <linux/pci.h> <linux/module.h> etc....
thanks
Peter
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: Microsoft's new ".NET"
Date: Wed, 12 Jul 2000 20:14:34 -0700
[EMAIL PROTECTED] wrote:
>
>Hmmm... Well, Microsoft's Plug and Play bios would work alot better on
>something out of the dark ages.
Microsoft wrote the specification, but they don't write BIOSes. There's
plenty of blame to go around.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: [EMAIL PROTECTED] (MWRon)
Crossposted-To: comp.os.linux.powerpc
Subject: Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC
Date: Wed, 12 Jul 2000 23:35:38 -0400
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Is this an assumption that all apps have to be done in Java? What about
>those who code in C?
Sorry I thought that was understood, C/C++ is supported but Java will be
new for this release.
>I was also going to ask why there is no support for Slackware?
We only have so many people so we can't validate on everything. For now
we can only deal with problems on a limited amount of distros. It should
work on all of them but we just can't handle all of them logistically.
Possibly as we get into later beta versions it will open up to more
distros.
As for serious people, I'm afraid that again we don't have the resources
for dabbling in Linux, we can't be teaching people how to use Linux.
Ron
--
Metrowerks acquires HiWare AG to be European headquarters
http://www.metrowerks.com/news/hiware/
Metrowerks, a Motorola Company - Ron Liechty
"Software Starts Here" - [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.powerpc
Subject: Re: [ANN] Beta testing of CW for Linux on Intel and PowerPC
Date: Thu, 13 Jul 2000 05:27:55 GMT
In comp.os.linux.development.system bill davidsen <[EMAIL PROTECTED]> wrote:
| | Even more to the point, "these are the only supported versions of
| | linux". Like, get real. Give me the source openly and I'll compile it
| | *myself* on a Debian GNULinux/PPC setup and check that it works - which
| | effectively does some 'work' *for* the company. Fail to cater for /all/ my
| | tastes in platform, both now and in the future, by introducing arbitrary
| | restrictions for no good reason, and I'll not even look at it.
|
| I don't think there's a restriction there, simply a list of supported
| distributions. If you want to run it on Slackware (I do!) or some other
| distribution the only restriction is that they don't promise that it
| will work.
|
| That's not a restriction, it's common sense. Back when we had SLS and
| Slackware as the only two significant distributions you could test on
| all of them. Not true any more. Don't read "not supported" for "can't
| work."
But why should they limit themselves to several distributions while
leaving out a couple of the major and important ones?
Distribution dependency could be as much of a difficulty as the kind
of OS dependency we have to deal with now. Granted a common kernel
helps a lot, but I think commercial software developers in general
are still poor at making things truly portable. Making something that
works on Redhat also work on Slackware is a far cry easier than making
it work on Windows 2000, and Slackware is still a major distribution
with lots of users, so why not?
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: David Highley <[EMAIL PROTECTED]>
Subject: Re: Why Does Linux Arp All The Time?
Date: Wed, 12 Jul 2000 23:10:50 -0700
This is a multi-part message in MIME format.
==============4FBF6E4D4DA3D6CBCA60DB43
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Kaz Kylheku wrote:
> On Tue, 11 Jul 2000 20:20:14 -0700, David Highley
> <[EMAIL PROTECTED]> wrote:
> >oak.highley-recommended.com -> (broadcast) ARP C Who is 10.2.2.3, hemlock.highl
> >ey-recommended.com ?
> >hemlock.highley-recommended.com -> oak.highley-recommended.com ARP R 10.2.2.3, h
> >emlock.highley-recommended.com is 8:0:20:b9:24:c9
> >sequoia.highley-recommended.com -> * ARP C Who is 10.2.2.3, hemlock.h
> >ighley-recommended.com ?
>
> It would help to see some time stamps here.
>
I was attempting to keep the size of the posting down, but here are the times.
>
> --
> #exclude <windows.h>
--
Regards,
David Highley
Highley Recommended, Inc.
2927 SW 339th Street
Federal Way, WA 98023-7732
Phone: (206) 669-0081
FAX: (253) 838-8509
Email: [EMAIL PROTECTED]
WEB: http://www.highley-recommended.com
==============4FBF6E4D4DA3D6CBCA60DB43
Content-Type: text/plain; charset=us-ascii;
name="junk2"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="junk2"
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 23:03:37.20
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:b9:24:c9, Sun
ETHER: Source = 0:e0:98:9:2c:d3,
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 1 (ARP Request)
ARP: Sender's hardware address = 0:e0:98:9:2c:d3
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP: Target hardware address = ?
ARP: Target protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 2 arrived at 23:03:37.20
ETHER: Packet size = 42 bytes
ETHER: Destination = 0:e0:98:9:2c:d3,
ETHER: Source = 8:0:20:b9:24:c9, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 2 (ARP Reply)
ARP: Sender's hardware address = 8:0:20:b9:24:c9
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP: Target hardware address = 0:e0:98:9:2c:d3
ARP: Target protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 3 arrived at 23:04:37.26
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:b9:24:c9, Sun
ETHER: Source = 0:e0:98:9:2c:d3,
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 1 (ARP Request)
ARP: Sender's hardware address = 0:e0:98:9:2c:d3
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP: Target hardware address = ?
ARP: Target protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 4 arrived at 23:04:37.26
ETHER: Packet size = 42 bytes
ETHER: Destination = 0:e0:98:9:2c:d3,
ETHER: Source = 8:0:20:b9:24:c9, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 2 (ARP Reply)
ARP: Sender's hardware address = 8:0:20:b9:24:c9
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP: Target hardware address = 0:e0:98:9:2c:d3
ARP: Target protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 5 arrived at 23:05:18.44
ETHER: Packet size = 42 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source = 8:0:20:b9:24:c9, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 1 (ARP Request)
ARP: Sender's hardware address = 8:0:20:b9:24:c9
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP: Target hardware address = ?
ARP: Target protocol address = 10.2.2.1, oak.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 6 arrived at 23:05:18.44
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:b9:24:c9, Sun
ETHER: Source = 0:0:c5:60:7b:b0,
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 2 (ARP Reply)
ARP: Sender's hardware address = 0:0:c5:60:7b:b0
ARP: Sender's protocol address = 10.2.2.1, oak.highley-recommended.com
ARP: Target hardware address = 8:0:20:b9:24:c9
ARP: Target protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 7 arrived at 23:05:27.31
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:b9:24:c9, Sun
ETHER: Source = 0:e0:98:9:2c:d3,
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 1 (ARP Request)
ARP: Sender's hardware address = 0:e0:98:9:2c:d3
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP: Target hardware address = ?
ARP: Target protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 8 arrived at 23:05:27.31
ETHER: Packet size = 42 bytes
ETHER: Destination = 0:e0:98:9:2c:d3,
ETHER: Source = 8:0:20:b9:24:c9, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 2 (ARP Reply)
ARP: Sender's hardware address = 8:0:20:b9:24:c9
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP: Target hardware address = 0:e0:98:9:2c:d3
ARP: Target protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 9 arrived at 23:06:37.38
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:b9:24:c9, Sun
ETHER: Source = 0:e0:98:9:2c:d3,
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 1 (ARP Request)
ARP: Sender's hardware address = 0:e0:98:9:2c:d3
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP: Target hardware address = ?
ARP: Target protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP:
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 10 arrived at 23:06:37.38
ETHER: Packet size = 42 bytes
ETHER: Destination = 0:e0:98:9:2c:d3,
ETHER: Source = 8:0:20:b9:24:c9, Sun
ETHER: Ethertype = 0806 (ARP)
ETHER:
ARP: ----- ARP/RARP Frame -----
ARP:
ARP: Hardware type = 1
ARP: Protocol type = 0800 (IP)
ARP: Length of hardware address = 6 bytes
ARP: Length of protocol address = 4 bytes
ARP: Opcode 2 (ARP Reply)
ARP: Sender's hardware address = 8:0:20:b9:24:c9
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ARP: Target hardware address = 0:e0:98:9:2c:d3
ARP: Target protocol address = 10.2.2.8, sequoia.highley-recommended.com
ARP:
==============4FBF6E4D4DA3D6CBCA60DB43==
------------------------------
From: Zoran Cutura <[EMAIL PROTECTED]>
Subject: Re: are PCI drivers char drivers?
Date: Thu, 13 Jul 2000 08:54:57 +0200
Grant Edwards wrote:
>
> In article <[EMAIL PROTECTED]>, Zoran Cutura wrote:
>
> >> A PCI driver which drives a PCI modem card is a char device. A
> >> PCI driver which drives a network card is a network device. A
> >> PCI driver that would offer a disk drive to the system (e.g. a
> >> software/hardware PCI RAID device) would be a block device. A
> >> SCSI PCI board is a SCSI ha.
>
> >you shouldn't mix up things like this. Character drivers and
> >block drivers have their special meanings in the kernel. A SCSI
> >or Network driver has only a meaning of functionality.
>
> Wrong. SCSI and network drivers are neither char nor block
> drivers. They are network and SCSI drivers.
>
> Network devices (e.g. eth0, eth1) are created "on the fly" as
> needed and don't live in /dev like normal char and block
> devices. The interface to a network devices/drivers is also
> not the same as for a "normal" block or char driver.
>
> >A SCSI driver will usually be a character driver, which means
> >that data is written/read character wise buit a filesystem
> >will be a block device where write/read will be performed in
> >blocks of a certain size.
>
> You have correctly differentiated char and block devices. Block
> devices (e.g. disks) transfer data in fixed sized blocks. Char
> devices (e.g. serial ports, printer ports, etc.) model a device
> as a stream of bytes.
>
> However, the part about a SCSI driver being a char devices
> isn't correct. A SCSI driver (for a PCI board, which is what
> we're talking about) is a different animal that is neither a
> char nor block device. It's a low-level layer that sits
> underneath the "generic" SCSI layer, which in turn sits
> undernead both char device drivers (e.g. st) and block device
> drivers (e.g. sd).
>
> --
> Grant Edwards grante Yow! I will establish
> at the first SHOPPING MALL in
> visi.com NUTLEY, New Jersey...
Perhaps I didn't use the right words? (English is not my native
language)
Usually we distinguish between character drivers and block drivers
because these use different interface functions from kernel
to user space. However a SCSI-driver with the low level control
functions will most likly not be used directly from
userspace but thru a filesystem or a generic SCSI-device
where one of these is a block device but the other is a character
device. So when one talks about character devices or block
devices one is only talking about the interface of the driver
to the user space.
>From what you've explained I understand your term SCSI-driver
beeing the functionality needed to control the SCSI-bus and
connected devices, where we need to bare in mind, that certainly
this differs for all devices and most likly does not have a
interface to user space.
Z
--
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days. Eric S. Raymond
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Why Does Linux Arp All The Time?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 13 Jul 2000 06:49:32 GMT
On Wed, 12 Jul 2000 23:10:50 -0700, David Highley
<[EMAIL PROTECTED]> wrote:
>This is a multi-part message in MIME format.
>--------------4FBF6E4D4DA3D6CBCA60DB43
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Kaz Kylheku wrote:
>
>> On Tue, 11 Jul 2000 20:20:14 -0700, David Highley
>> <[EMAIL PROTECTED]> wrote:
>> >oak.highley-recommended.com -> (broadcast) ARP C Who is 10.2.2.3, hemlock.highl
>> >ey-recommended.com ?
>> >hemlock.highley-recommended.com -> oak.highley-recommended.com ARP R 10.2.2.3, h
>> >emlock.highley-recommended.com is 8:0:20:b9:24:c9
>> >sequoia.highley-recommended.com -> * ARP C Who is 10.2.2.3, hemlock.h
>> >ighley-recommended.com ?
>>
>> It would help to see some time stamps here.
>>
>
>I was attempting to keep the size of the posting down, but here are the times.
>From the times it appears that the packets are *minutes* apart. That is
hardly ``arping all the time''.
The two closest reply times are 5:18.44 and 5:27.31. But they are
from different hosts, oak and hemlock.
Note that the conversations with the hemlock are about a minute apart, at
least. The 4:37 and 5:27 exchanges with hemlock are the closest, a mere 50
seconds apart.
Here I was thinking that your arps are for some reason flooding the wire every
few milliseconds. ;)
Here is the timing information, trimmed down.
ETHER: Packet 1 arrived at 23:03:37.20
ARP: Opcode 1 (ARP Request)
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ETHER: Packet 2 arrived at 23:03:37.20
ARP: Opcode 2 (ARP Reply)
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ETHER: Packet 3 arrived at 23:04:37.26
ARP: Opcode 1 (ARP Request)
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ETHER: Packet 4 arrived at 23:04:37.26
ARP: Opcode 2 (ARP Reply)
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ETHER: Packet 5 arrived at 23:05:18.44
ARP: Opcode 1 (ARP Request)
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ETHER: Packet 6 arrived at 23:05:18.44
ARP: Opcode 2 (ARP Reply)
ARP: Sender's protocol address = 10.2.2.1, oak.highley-recommended.com
ETHER: Packet 7 arrived at 23:05:27.31
ARP: Opcode 1 (ARP Request)
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ETHER: Packet 8 arrived at 23:05:27.31
ARP: Opcode 2 (ARP Reply)
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
ETHER: Packet 9 arrived at 23:06:37.38
ARP: Opcode 1 (ARP Request)
ARP: Sender's protocol address = 10.2.2.8, sequoia.highley-recommended.com
ETHER: Packet 10 arrived at 23:06:37.38
ARP: Opcode 2 (ARP Reply)
ARP: Sender's protocol address = 10.2.2.3, hemlock.highley-recommended.com
--
#exclude <windows.h>
------------------------------
From: Zoran Cutura <[EMAIL PROTECTED]>
Subject: Re: linker problem?
Date: Thu, 13 Jul 2000 08:59:42 +0200
Peter Huang wrote:
>
> Hi
>
> I'm trying to build a device driver module on Kernel version 2.2.14-5.0 and
> I am running into some problems that appears to be linker related.
>
> these lines appeared
>
> /usr/lib/crt1.o: In function `_start':
>
> /usr/lib/crt1.o(.text+0x18): undefined reference to `main'
>
> /tmp/cc3T2jO9.o: In function `init_module':
>
> /tmp/cc3T2jO9.o(.text+0x11): undefined reference to `register_chrdev'
>
> /tmp/cc3T2jO9.o(.text+0x23): undefined reference to `printk'
>
> /tmp/cc3T2jO9.o(.text+0x36): undefined reference to `printk'
>
> /tmp/cc3T2jO9.o(.text+0x3e): undefined reference to `pcibios_present'
>
> /tmp/cc3T2jO9.o(.text+0x5d): undefined reference to `pci_find_device'
>
> /tmp/cc3T2jO9.o(.text+0x91): undefined reference to `printk'
>
> /tmp/cc3T2jO9.o: In function `testpci_detect_pci':
>
> /tmp/cc3T2jO9.o(.text+0xb3): undefined reference to `pcibios_present'
>
> /tmp/cc3T2jO9.o(.text+0xdf): undefined reference to `pci_find_device'
>
> /tmp/cc3T2jO9.o(.text+0x109): undefined reference to `printk'
>
> when I tried to build with this makefile
>
> LINUX_DIR=/usr/src/linux
>
> CC=gcc
>
> OPT= -D__KERNEL__ -DMODULE -O3 -I$(LINUX_DIR)/include
>
> CFLAGS=$(OPT) -Wall -Werror
>
> TARGETS=testpci
>
> all:: $(TARGETS)
>
> testpci: testpci.c
>
> $(CC) $(CFLAGS) -o testpci testpci.c
>
> ........
>
> It appears that the linker can't find any kernel functions and even tried to
> look for the main()
> function. Can any one give me some suggestion on what might be wrong? On the
> testpci.c file itself, I included most of
> the header files such as <linux/pci.h> <linux/module.h> etc....
>
> thanks
>
> Peter
seams like you're missing the '-c' option to gcc since
linking will be done at load time.
Z
--
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days. Eric S. Raymond
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
