[richard offer]
> Or userland libraries/applications that need to bypass libc and make
> direct kernel calls because libc hasn't yet implemented those new
> kernel calls.
Nah, it's still error-prone because it's too hard to guarantee that the
user compiling your program has up-to-date kernel
In article <91gr99$bs81o$[EMAIL PROTECTED]> you write:
>
>[Dana Lacoste]
>> Essentially, whatever solution is implemented MUST ensure :
>>
>> 1 - glibc will work properly (the headers in /usr/include/* don't
>> change in an incompatible manner)
>>
>> 2 - programs that need to compile
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
>
> Can we get a #3 going? I think it could really help both the cross-compile
> people and those who just want to make sure their modules are compiling in
> the 'correct' environment. It also allows for things like 'kgcc vs. gcc'
On Sun, 17 Dec 2000, Peter Samuelson wrote:
>
> [[EMAIL PROTECTED]]
> > One last question: WHY is the kernel's top-level Makefile handling
> > this symlink?
>
> Where do you think it should be handled? 'make modules_install' seems
> like the most logical place, to me.
I think making the
[Dana Lacoste]
> - I write an external/third party kernel module
> - For various reasons, I must have this kernel module installed to boot
> (i can't compile without my module running)
In that case "compile script for dummies" will probably fail anyway.
If you need it to boot, you probably
On 18 Dec 00 at 10:51, Dana Lacoste wrote:
> Potential answers that have come up so far :
> 1 - /lib/modules/* directories that involve `uname -r`
> This won't work because i might not be compiling for the `uname -r` kernel
> 2 - /lib/modules//build/include/ :
> we could recommend that
"Peter Samuelson" <[EMAIL PROTECTED]> wrote :
> [Dana Lacoste]
> > 2 - programs that need to compile against the current kernel MUST
> > be able to do so in a quasi-predictable manner.
> (2) is bogus. NO program needs to compile against the current kernel
> headers. The only things that
"Peter Samuelson" [EMAIL PROTECTED] wrote :
[Dana Lacoste]
2 - programs that need to compile against the current kernel MUST
be able to do so in a quasi-predictable manner.
(2) is bogus. NO program needs to compile against the current kernel
headers. The only things that need to
On 18 Dec 00 at 10:51, Dana Lacoste wrote:
Potential answers that have come up so far :
1 - /lib/modules/* directories that involve `uname -r`
This won't work because i might not be compiling for the `uname -r` kernel
2 - /lib/modules/version/build/include/ :
we could recommend that
[Dana Lacoste]
- I write an external/third party kernel module
- For various reasons, I must have this kernel module installed to boot
(i can't compile without my module running)
In that case "compile script for dummies" will probably fail anyway.
If you need it to boot, you probably need
On Sun, 17 Dec 2000, Peter Samuelson wrote:
[[EMAIL PROTECTED]]
One last question: WHY is the kernel's top-level Makefile handling
this symlink?
Where do you think it should be handled? 'make modules_install' seems
like the most logical place, to me.
I think making the symlink
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
Can we get a #3 going? I think it could really help both the cross-compile
people and those who just want to make sure their modules are compiling in
the 'correct' environment. It also allows for things like 'kgcc vs. gcc' to
In article 91gr99$bs81o$[EMAIL PROTECTED] you write:
[Dana Lacoste]
Essentially, whatever solution is implemented MUST ensure :
1 - glibc will work properly (the headers in /usr/include/* don't
change in an incompatible manner)
2 - programs that need to compile against the current
[richard offer]
Or userland libraries/applications that need to bypass libc and make
direct kernel calls because libc hasn't yet implemented those new
kernel calls.
Nah, it's still error-prone because it's too hard to guarantee that the
user compiling your program has up-to-date kernel
[[EMAIL PROTECTED]]
> One last question: WHY is the kernel's top-level Makefile handling
> this symlink?
Where do you think it should be handled? 'make modules_install' seems
like the most logical place, to me.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Sun, 17 Dec 2000, Peter Samuelson wrote:
>
> [[EMAIL PROTECTED] <[EMAIL PROTECTED]>]
> > I have not moved or deleted a tree. I do not HAVE a kernel tree in
> > the first place. Therefore, nothing for the symlink to point to when
> > I install the kernel.
>
> If this is not the machine you
On Sun, 17 Dec 2000, Peter Samuelson wrote:
[[EMAIL PROTECTED] [EMAIL PROTECTED]]
I have not moved or deleted a tree. I do not HAVE a kernel tree in
the first place. Therefore, nothing for the symlink to point to when
I install the kernel.
If this is not the machine you compile
[[EMAIL PROTECTED]]
One last question: WHY is the kernel's top-level Makefile handling
this symlink?
Where do you think it should be handled? 'make modules_install' seems
like the most logical place, to me.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
[[EMAIL PROTECTED] <[EMAIL PROTECTED]>]
> I have not moved or deleted a tree. I do not HAVE a kernel tree in
> the first place. Therefore, nothing for the symlink to point to when
> I install the kernel.
If this is not the machine you compile your kernels on, why are you
compiling your external
On Sat, 16 Dec 2000, Peter Samuelson wrote:
>
> [[EMAIL PROTECTED]]
> > Do you have an alternative reccomendation? I've shown where the
> > symlink method WILL fail. You disagree that having the configured
> > headers copied is a workable idea. What else is there?
>
> 4.5 more megabytes, per
[Peter Samuelson]
> > make -C /lib/modules/`uname -r`/build modules SUBDIRS=$(pwd)
[Miquel van Smoorenburg]
> Excellent. Is there any way to put his in a Makefile?
I don't know why not. Here's what I would start with:
PWD := $(shell pwd)
KERNEL := /lib/modules/$(shell uname -r)/build
[Joe deBlaquiere]
> Last I recall you have to at least have newlib around to get through
> the build process of gcc. libgcc doesn't affect the kernel but you
> can't do 'make install' without building it.
Hmmm. I do not recall needing newlib or anything like it, last time I
built a
In article <[EMAIL PROTECTED]>,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>[Miquel van Smoorenburg]
>> In fact, the 2.2.18 kernel already puts a 'build' symlink in
>> /lib/modules/`uname -r` that points to the kernel source,
>> which should be sufficient to solve this problem.. almost.
>>
>>
Lets try another scenario (from user point of view)
Ship kernel sources split in kernel-headers-2.2.18(tar.bz2,rpm,deb) and
kernel-source-2.2.18, and a binary kernel-2.2.18
One user not doing kernel compiles, but with various installed
kernels to try has:
/usr/include/kernel-2.2.18
Last I recall you have to at least have newlib around to get through the
build process of gcc. libgcc doesn't affect the kernel but you can't do
'make install' without building it.
BTW : The Linux newlib stuff should go a long way toward solving some of
these problems (at least for x86 these
[[EMAIL PROTECTED]]
> Do you have an alternative reccomendation? I've shown where the
> symlink method WILL fail. You disagree that having the configured
> headers copied is a workable idea. What else is there?
4.5 more megabytes, per kernel, on my root filesystem. (That's *after*
pruning the
[Miquel van Smoorenburg]
> In fact, the 2.2.18 kernel already puts a 'build' symlink in
> /lib/modules/`uname -r` that points to the kernel source,
> which should be sufficient to solve this problem.. almost.
>
> It doesn't tell you the specific flags used to compile the kernel,
> such as -m486
[Joe deBlaquiere]
> might be a good newbie filter... but actually the best thing about it
> is that the compiler people of the work might make generating a
> proper cross-toolchain less difficult by one or two magnitudes...
*WHAT*? How much less difficult could it possibly get? This is the
[Dana Lacoste]
> Essentially, whatever solution is implemented MUST ensure :
>
> 1 - glibc will work properly (the headers in /usr/include/* don't
> change in an incompatible manner)
>
> 2 - programs that need to compile against the current kernel MUST
> be able to do so in a
On 16 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >On 15 Dec 2000, Miquel van Smoorenburg wrote:
> >
> >> I think /lib/modules/`uname -r`/ should contain a script that
> >> reproduces the CFLAGS used to compile the kernel.
> >
>
On Sat, 16 Dec 2000, Keith Owens wrote:
> On Fri, 15 Dec 2000 19:37:49 -0800 (PST),
> [EMAIL PROTECTED] wrote:
> >Do you have an alternative reccomendation? I've shown where the symlink
> >method WILL fail. You disagree that having the configured headers copied
> >is a workable idea. What
[EMAIL PROTECTED] (Alan Cox) writes:
> > >Which works because in a normal compile environment they have /usr/include
> > >in their include path and /usr/include/linux points to the directory
> > >under /usr/src/linux/include.
> >
> > No, that a redhat-ism.
>
> Umm, its a most people except
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>On 15 Dec 2000, Miquel van Smoorenburg wrote:
>
>> I think /lib/modules/`uname -r`/ should contain a script that
>> reproduces the CFLAGS used to compile the kernel.
>
>However it happens, the necessary information THAT I KNOW OF is:
On Fri, 15 Dec 2000, richard offer wrote:
>
> * $ from [EMAIL PROTECTED] at "15-Dec: 8:22pm" | sed "1,$s/^/* /"
> *
> *
> * Once again, I'd like to suggest Debian's kernel package system as a good
> * working example of this sort of administrative-level kernel management. I
> * brought this
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
On 15 Dec 2000, Miquel van Smoorenburg wrote:
I think /lib/modules/`uname -r`/ should contain a script that
reproduces the CFLAGS used to compile the kernel.
However it happens, the necessary information THAT I KNOW OF is:
0) The kernel
[EMAIL PROTECTED] (Alan Cox) writes:
Which works because in a normal compile environment they have /usr/include
in their include path and /usr/include/linux points to the directory
under /usr/src/linux/include.
No, that a redhat-ism.
Umm, its a most people except Debianism. People
On Sat, 16 Dec 2000, Keith Owens wrote:
On Fri, 15 Dec 2000 19:37:49 -0800 (PST),
[EMAIL PROTECTED] wrote:
Do you have an alternative reccomendation? I've shown where the symlink
method WILL fail. You disagree that having the configured headers copied
is a workable idea. What else is
On 16 Dec 2000, Miquel van Smoorenburg wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
On 15 Dec 2000, Miquel van Smoorenburg wrote:
I think /lib/modules/`uname -r`/ should contain a script that
reproduces the CFLAGS used to compile the kernel.
However it happens,
[Dana Lacoste]
Essentially, whatever solution is implemented MUST ensure :
1 - glibc will work properly (the headers in /usr/include/* don't
change in an incompatible manner)
2 - programs that need to compile against the current kernel MUST
be able to do so in a
[Joe deBlaquiere]
might be a good newbie filter... but actually the best thing about it
is that the compiler people of the work might make generating a
proper cross-toolchain less difficult by one or two magnitudes...
*WHAT*? How much less difficult could it possibly get? This is the
[Miquel van Smoorenburg]
In fact, the 2.2.18 kernel already puts a 'build' symlink in
/lib/modules/`uname -r` that points to the kernel source,
which should be sufficient to solve this problem.. almost.
It doesn't tell you the specific flags used to compile the kernel,
such as -m486
[[EMAIL PROTECTED]]
Do you have an alternative reccomendation? I've shown where the
symlink method WILL fail. You disagree that having the configured
headers copied is a workable idea. What else is there?
4.5 more megabytes, per kernel, on my root filesystem. (That's *after*
pruning the
In article [EMAIL PROTECTED],
Peter Samuelson [EMAIL PROTECTED] wrote:
[Miquel van Smoorenburg]
In fact, the 2.2.18 kernel already puts a 'build' symlink in
/lib/modules/`uname -r` that points to the kernel source,
which should be sufficient to solve this problem.. almost.
It doesn't tell
[Joe deBlaquiere]
Last I recall you have to at least have newlib around to get through
the build process of gcc. libgcc doesn't affect the kernel but you
can't do 'make install' without building it.
Hmmm. I do not recall needing newlib or anything like it, last time I
built a
[Peter Samuelson]
make -C /lib/modules/`uname -r`/build modules SUBDIRS=$(pwd)
[Miquel van Smoorenburg]
Excellent. Is there any way to put his in a Makefile?
I don't know why not. Here's what I would start with:
PWD := $(shell pwd)
KERNEL := /lib/modules/$(shell uname -r)/build
On Sat, 16 Dec 2000, Peter Samuelson wrote:
[[EMAIL PROTECTED]]
Do you have an alternative reccomendation? I've shown where the
symlink method WILL fail. You disagree that having the configured
headers copied is a workable idea. What else is there?
4.5 more megabytes, per kernel,
[[EMAIL PROTECTED] [EMAIL PROTECTED]]
I have not moved or deleted a tree. I do not HAVE a kernel tree in
the first place. Therefore, nothing for the symlink to point to when
I install the kernel.
If this is not the machine you compile your kernels on, why are you
compiling your external
On Fri, 15 Dec 2000, richard offer wrote:
* $ from [EMAIL PROTECTED] at "15-Dec: 8:22pm" | sed "1,$s/^/* /"
*
*
* Once again, I'd like to suggest Debian's kernel package system as a good
* working example of this sort of administrative-level kernel management. I
* brought this up on
On Fri, 15 Dec 2000 19:37:49 -0800 (PST),
[EMAIL PROTECTED] wrote:
>Do you have an alternative reccomendation? I've shown where the symlink
>method WILL fail. You disagree that having the configured headers copied
>is a workable idea. What else is there?
Use the pcmcia-cs method. Ask where the
On Fri, 15 Dec 2000, richard offer wrote:
> In article <91e0vj$b6alr$[EMAIL PROTECTED]> you write:
> >In article <[EMAIL PROTECTED]>,
> >LA Walsh <[EMAIL PROTECTED]> wrote:
> >>It was at that
> >>point, the externally compiled module "barfed", because like many modules,
> >>it expected, like
On Fri, 15 Dec 2000, J . A . Magallon wrote:
>
> On 2000/12/15 Werner Almesberger wrote:
> > LA Walsh wrote:
> >
> > Exception: opaque types; there one would have to go via a __ identifier,
> > i.e.
> >
> > /foo.h defines struct __foo ...;
> > /bar.h includes /foo.h
> >and
On 15 Dec 2000, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> wrote:
> >It was at that
> >point, the externally compiled module "barfed", because like many modules,
> >it expected, like many externally compiled modules, that it could simply
>
On Fri, 15 Dec 2000, Ingo Oeser wrote:
> On Fri, Dec 15, 2000 at 09:31:57AM -0800, [EMAIL PROTECTED] wrote:
> > > Maybe you did not notice, but for months we have
> > > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > > and which should be used for compiling
In article <91e0vj$b6alr$[EMAIL PROTECTED]> you write:
>In article <[EMAIL PROTECTED]>,
>LA Walsh <[EMAIL PROTECTED]> wrote:
>>It was at that
>>point, the externally compiled module "barfed", because like many modules,
>>it expected, like many externally compiled modules, that it could simply
Joe deBlaquiere wrote:
> but actually the best thing about it is
> that the compiler people of the work might make generating a proper
> cross-toolchain less difficult by one or two magnitudes...
You have a point here ... particularly gcc-glibc interdependencies are
a little irritating (not
J . A . Magallon wrote:
> Easier: public kernel interfaces only work through pointers.
Requires more elaborate wrappers or a new layer of wrapper functions
around system calls, if you want to make this completely general.
Also, doesn't provide FOOSIZE to "public" space.
> Too
On Fri, 15 Dec 2000, Dana Lacoste wrote:
> We really need a documented way to deal with this! It's getting silly
> the number of questions that people ask!
Please, that would be helpful - I'm still using a heavily mutated
slackware 3.1 that's been hacked up to the same level (if not beyond) as
Werner Almesberger wrote:
> Joe deBlaquiere wrote:
>
>> My solution to this has always been to make a cross compiler environment
>
>
> ;-))) I think lots of people would really enjoy to have "build a
> cross-gcc" added to the prerequisites for installing some driver
> module ;-)
>
> I
On 2000/12/15 Werner Almesberger wrote:
> LA Walsh wrote:
>
> Exception: opaque types; there one would have to go via a __ identifier,
> i.e.
>
> /foo.h defines struct __foo ...;
> /bar.h includes /foo.h
>and uses #define FOOSIZE sizeof(struct __foo)
> /foo.h either typedef
Matt D. Robinson wrote:
> I personally think the definition of an environment variable to point to
> a header file location is the right way to go.
I see two disadvantages of this, compared to a script:
- need to hard-code a default (unless we assume the variables are always
set)
- the way
> From: Werner Almesberger [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 15, 2000 1:21 PM
> I don't think restructuring the headers in this way would cause
> a long period of instability. The main problem seems to be to
> decide what is officially private and what isn't.
---
If
Joe deBlaquiere wrote:
> My solution to this has always been to make a cross compiler environment
;-))) I think lots of people would really enjoy to have "build a
cross-gcc" added to the prerequisites for installing some driver
module ;-)
I know, it's not *that* bad. But it still adds quite a
In article <[EMAIL PROTECTED]>,
LA Walsh <[EMAIL PROTECTED]> wrote:
>It was at that
>point, the externally compiled module "barfed", because like many modules,
>it expected, like many externally compiled modules, that it could simply
>access all of it's needed files through /usr/include/linux
My solution to this has always been to make a cross compiler environment
(even if it is the same processor family). Thusly i386-linux-gcc knows
that the target system's include files are in:
/usr/local/-tools/i386-linux/include (/linux, /asm)
The other advantage to this is that I can switch
Werner Almesberger wrote:
>
> Alexander Viro wrote:
> > In the situation above they should have -I/include
> > in CFLAGS. Always had to. No links, no pain in ass, no interference with
> > userland compiles.
>
> As long as there's a standard location for "",
> this is fine. In most cases, the
> From: Werner Almesberger [mailto:[EMAIL PROTECTED]]
>
> I think there are three possible directions wrt visibility of kernel
> headers:
>
> - non at all - anything that needs kernel headers needs to provide them
>itself
> - kernel-specific extentions only; libc is self-contained, but
On Fri, Dec 15, 2000 at 09:31:57AM -0800, [EMAIL PROTECTED] wrote:
> > Maybe you did not notice, but for months we have
> > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > and which should be used for compiling out-of-tree kernel modules
> > (i.e. latest vmware uses
[EMAIL PROTECTED] wrote:
> Just out of curiosity, what would happen with redirection if your source
> tree for 'the currently running kernel' version happens to be configured
> for a different 'the currently running kernel', perhaps a machine of a
> foreign arch that you are cross-compiling for?
On Fri, 15 Dec 2000, Petr Vandrovec wrote:
> On 15 Dec 00 at 10:23, Dana Lacoste wrote:
> > > On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
> >
> > > It's the version that's in cvs, I just did an cvs update. It's
> > > been in it for ages. If it's wrong, someone
On Fri, 15 Dec 2000, Werner Almesberger wrote:
> Alexander Viro wrote:
> > In the situation above they should have -I/include
> > in CFLAGS. Always had to. No links, no pain in ass, no interference with
> > userland compiles.
>
> As long as there's a standard location for "",
> this is fine.
Dana Lacoste wrote:
>
> > Maybe you did not notice, but for months we have
> > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > and which should be used for compiling out-of-tree kernel modules
> > (i.e. latest vmware uses this).
>
> What about the case where I'm
On 15 Dec 00 at 11:00, Dana Lacoste wrote:
> > Maybe you did not notice, but for months we have
> > /lib/modules/`uname -r`/build/include, which points to kernel headers,
> > and which should be used for compiling out-of-tree kernel modules
> > (i.e. latest vmware uses this).
>
> What about the
> Maybe you did not notice, but for months we have
> /lib/modules/`uname -r`/build/include, which points to kernel headers,
> and which should be used for compiling out-of-tree kernel modules
> (i.e. latest vmware uses this).
What about the case where I'm compiling for a kernel that I'm
not
On 15 Dec 00 at 10:23, Dana Lacoste wrote:
> > On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
>
> > It's the version that's in cvs, I just did an cvs update. It's
> > been in it for ages. If it's wrong, someone *please* correct it.
>
> I think this is the important
> On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
> It's the version that's in cvs, I just did an cvs update. It's
> been in it for ages. If it's wrong, someone *please* correct it.
I think this is the important part.
This subject has come up quite a few times in the
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> LA Walsh <[EMAIL PROTECTED]> wrote:
> >Which works because in a normal compile environment they have /usr/include
> >in their include path and /usr/include/linux points to the directory
>
Alexander Viro wrote:
> In the situation above they should have -I/include
> in CFLAGS. Always had to. No links, no pain in ass, no interference with
> userland compiles.
As long as there's a standard location for "",
this is fine. In most cases, the tree one expects to find is "roughly
the
"LA Walsh" <[EMAIL PROTECTED]> writes:
> I've seen this setup on RH, SuSE and Mandrake systems. I thought
> this was somehow normal practice?
it's done for us till the 7.2 but next version we gonna to switch to a
different headers directory like Debian/RH does...
--
MandrakeSoft Inc
"LA Walsh" [EMAIL PROTECTED] writes:
I've seen this setup on RH, SuSE and Mandrake systems. I thought
this was somehow normal practice?
it's done for us till the 7.2 but next version we gonna to switch to a
different headers directory like Debian/RH does...
--
MandrakeSoft Inc
Alexander Viro wrote:
In the situation above they should have -Iwherever_the_tree_lives/include
in CFLAGS. Always had to. No links, no pain in ass, no interference with
userland compiles.
As long as there's a standard location for "wherever_the_tree_lives",
this is fine. In most cases, the
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
In article [EMAIL PROTECTED],
LA Walsh [EMAIL PROTECTED] wrote:
Which works because in a normal compile environment they have /usr/include
in their include path and /usr/include/linux points to the directory
under
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
It's the version that's in cvs, I just did an cvs update. It's
been in it for ages. If it's wrong, someone *please* correct it.
I think this is the important part.
This subject has come up quite a few times in the past
On 15 Dec 00 at 10:23, Dana Lacoste wrote:
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
It's the version that's in cvs, I just did an cvs update. It's
been in it for ages. If it's wrong, someone *please* correct it.
I think this is the important part.
This
Maybe you did not notice, but for months we have
/lib/modules/`uname -r`/build/include, which points to kernel headers,
and which should be used for compiling out-of-tree kernel modules
(i.e. latest vmware uses this).
What about the case where I'm compiling for a kernel that I'm
not running
On 15 Dec 00 at 11:00, Dana Lacoste wrote:
Maybe you did not notice, but for months we have
/lib/modules/`uname -r`/build/include, which points to kernel headers,
and which should be used for compiling out-of-tree kernel modules
(i.e. latest vmware uses this).
What about the case where
Dana Lacoste wrote:
Maybe you did not notice, but for months we have
/lib/modules/`uname -r`/build/include, which points to kernel headers,
and which should be used for compiling out-of-tree kernel modules
(i.e. latest vmware uses this).
What about the case where I'm compiling for a
On Fri, 15 Dec 2000, Werner Almesberger wrote:
Alexander Viro wrote:
In the situation above they should have -Iwherever_the_tree_lives/include
in CFLAGS. Always had to. No links, no pain in ass, no interference with
userland compiles.
As long as there's a standard location for
On Fri, 15 Dec 2000, Petr Vandrovec wrote:
On 15 Dec 00 at 10:23, Dana Lacoste wrote:
On Fri, Dec 15, 2000 at 12:14:04AM +, Miquel van Smoorenburg wrote:
It's the version that's in cvs, I just did an cvs update. It's
been in it for ages. If it's wrong, someone *please*
[EMAIL PROTECTED] wrote:
Just out of curiosity, what would happen with redirection if your source
tree for 'the currently running kernel' version happens to be configured
for a different 'the currently running kernel', perhaps a machine of a
foreign arch that you are cross-compiling for?
Two
On Fri, Dec 15, 2000 at 09:31:57AM -0800, [EMAIL PROTECTED] wrote:
Maybe you did not notice, but for months we have
/lib/modules/`uname -r`/build/include, which points to kernel headers,
and which should be used for compiling out-of-tree kernel modules
(i.e. latest vmware uses this).
From: Werner Almesberger [mailto:[EMAIL PROTECTED]]
I think there are three possible directions wrt visibility of kernel
headers:
- non at all - anything that needs kernel headers needs to provide them
itself
- kernel-specific extentions only; libc is self-contained, but user
Werner Almesberger wrote:
Alexander Viro wrote:
In the situation above they should have -Iwherever_the_tree_lives/include
in CFLAGS. Always had to. No links, no pain in ass, no interference with
userland compiles.
As long as there's a standard location for "wherever_the_tree_lives",
My solution to this has always been to make a cross compiler environment
(even if it is the same processor family). Thusly i386-linux-gcc knows
that the target system's include files are in:
/usr/local/project-tools/i386-linux/include (/linux, /asm)
The other advantage to this is that I can
In article [EMAIL PROTECTED],
LA Walsh [EMAIL PROTECTED] wrote:
It was at that
point, the externally compiled module "barfed", because like many modules,
it expected, like many externally compiled modules, that it could simply
access all of it's needed files through /usr/include/linux which it
Joe deBlaquiere wrote:
My solution to this has always been to make a cross compiler environment
;-))) I think lots of people would really enjoy to have "build a
cross-gcc" added to the prerequisites for installing some driver
module ;-)
I know, it's not *that* bad. But it still adds quite a
Matt D. Robinson wrote:
I personally think the definition of an environment variable to point to
a header file location is the right way to go.
I see two disadvantages of this, compared to a script:
- need to hard-code a default (unless we assume the variables are always
set)
- the way
From: Werner Almesberger [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 1:21 PM
I don't think restructuring the headers in this way would cause
a long period of instability. The main problem seems to be to
decide what is officially private and what isn't.
---
If someone
On 2000/12/15 Werner Almesberger wrote:
LA Walsh wrote:
Exception: opaque types; there one would have to go via a __ identifier,
i.e.
public/foo.h defines struct __foo ...;
public/bar.h includes public/foo.h
and uses #define FOOSIZE sizeof(struct __foo)
private/foo.h
Werner Almesberger wrote:
Joe deBlaquiere wrote:
My solution to this has always been to make a cross compiler environment
;-))) I think lots of people would really enjoy to have "build a
cross-gcc" added to the prerequisites for installing some driver
module ;-)
I know, it's not
On Fri, 15 Dec 2000, Dana Lacoste wrote:
We really need a documented way to deal with this! It's getting silly
the number of questions that people ask!
Please, that would be helpful - I'm still using a heavily mutated
slackware 3.1 that's been hacked up to the same level (if not beyond) as
1 - 100 of 128 matches
Mail list logo
