l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2005 Sep 05 00:48

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Module build
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Module build



Richard Harke wrote:
On Sat September 3 2005 09:24, Rick Moen wrote:
[... explanations of history and justification particular kernel
header locations omitted ...]

(But then, too, why not compile your kernels somewhere more convenient,
like your home directory or /tmp?  And you can always have a symlink at
/usr/src/linux that points into there.)

Neither answer (this one and the one from Jeff) really answered what I
thought I asked. I realized that these are potentially different sets of
headers but the question was how to have a module build find the correct
ones.
Until you know which ones are the right ones, you cannot hope to specify it.
You didn't make clear that you already knew which to specify, and that your
question was in regard to mechanics.

For modules that are a part of the kernel tarball, this has already
been taken care of. The problem comes up when you have module
source which is not in the kernel source tree. Part of the answer is that
the gcc command line has -I <prefix>/include where <prefix> is the
location of the kernel source tree, /usr/src/linux in the traditional case.
This directory will be searched first and /usr/include will only be searched
if the header file wasn't found.
Oh? Searched by what mechanism? The compiler's header search sequence is defined by the options which it is given... and those options are usually specified in the Makefile... which is either hand-edited or generated by the "configure" script... which is in turn built by Automake and hand edited.

I was trying to build a version of rtlinux
and their instructions required putting the kernel source in /usr/src/linux
because they needed to build a lot of out-of-the-tree modules and
they needed to know where the includes would be located.
Until you mentioned rtlinux we didn't know which set of sources to consider either. At any step of meta-configuration, hand editing can come into play, and different sources handle it differently.

Looking at the RTLinux howto, I see that it says you must setup a symlink from /usr/src/linux to your kernel sources. Thus, RTLinux is perpetuating this poor practice... and you have to decide whether to go along with that or to fix your sources by hand. If it were me, I would do a quick grep through the configuration files to find where they have hardcoded that location, and edit it to reflect where you are compiling this kernel. In the long run, they need a "configure" script that collects this information for a particular compilation.

You _did_ ask what the right way to do it was... not what the way the RTLinux sources assume you will do it. Per the earlier responses, my recommendation is based on a long-overdue shift in general practice.

By the way, I just checked, all of the kernels I have in /usr/src
belong to me, not root.
Better than root, and within normal guidelines, but I am more comfortable developing in /home/<myhome>/src or somewhere near there. In general, I think development should not be a systemwide activity... it is the province of the developer, and as much of their testing and compilation should be conducted under their directory tree as possible.

--
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnewmil@dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---------------------------------------------------------------------------
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!