This goes back to what I recommended about not moving files; 'usb.h' is
expecting to find a subdirectory 'linux', with two dependent include files,
one of which is "linux/mod_devicetable.h".

Include files frequently (almost always) refer to other include files. The
most generic ones are in '/usr/include' and '/usr/local/include'. From
there, they start getting OS, version, and product/project specific.
Version
3 of gcc has it's own subfolder under /usr/include, for example.

Find 'linux/mod_devictable.h' on your file system. Instead of moving it,
add
the directory to your compile statement. Example (<somewhere is the
directory that has the 'linux' subdirectory containing
'mod_devicetable.h'):

gcc iUSBDaqexample.c -I /usr/include -I /<somewhere -o example.out.

This will likely turn up more include file dependencies. Look at the build
error for the "missing file or include path", keep adding the referenced
file location to your include path. Eventually, it will all compile but not
link. Let me know when you get there ;/)


--Kenny A.
http://websites.expercraft.com/kennya/

OK Kenny I get it now. I think.  One xx.h calls another yy.h someplace else
and that
one calls another someplace else and so on and so on. How do you guys
get anything done? This is a nightmare :)

Does it always look in the previous directory?
Why don't they put them all in the same directory?

I redirected the output of locate:
locate usb.h  locate-usb.h.txt

Then I converted it to a pdf so I could send it to you.
Here is the 3 page pdf file attached.
How do you know what path to choose? usb.h is all over the place.

I took a guess. Then I ran:
gcc -I "root/usr/src/linux-headers-2.6.28-17/include/linux/usb.h"
iUSBDAQsample.c -o usbtest

The results are shown in the attached jpg.

Paul Lamar


Getting very warm now... your compile statement should be revised to:
... -I root/usr/src/linux-headers-2.6.28-17/include ...

Don't carry the path all the way into 'linux/usb.h'. Libs are usually
architected this way, all your include path statements should terminate at
the 'include' directory.

I admit this is pretty maddening, and there are a lot of ways it can break.
What it buys you is flexibility; by breaking OS/toolset version-specific and
hardware version-specific headers into different folders, I can recompile
for different targets / toolsets / OS's simply by changing my include path.
Say I have 'ARM' includes in one folder, and 'x86' in another, for example.
Since each target is likely to have it's own 'usb.h' header file, specific
to that architecture, they can't all coexist in the same place. Vendors do
get sloppy and neglect to pare obsolete headers, which adds to the mess.
Open-source developers are the worst offenders, as there's often high
turnover on projects and the maintainers can't be sure if a file is really
obsolete or not.

After you get the include path worked out, you're going to run the same
exercise with linking and the '-L' option. At that point you should consider
learning about makefiles, or using an IDE.

--Kenny A.
http://websites.expercraft.com/kennya/

OK Kenny after I fix the leak in the roof I'll try it :)

Thanks again.

Paul Lamar