[tulip] Header Files and Compilation Instructions

[james hill]

Hey Dana,

Attached are various posts I have made on this board. Give me a few
minutes and I will write up something a little more detailed. I truly
thank thee for the post. And you are very right, this is not something
easy for us newbies to understand, of course it could be that I am just
idiot. I tend to not believe not but it is within the realm of
possibilities.

Your crack smokin' linux buddy

Jimmy



----- Original Message -----
From: "Dana Lacoste" <dana.lacoste@peregrine.com>
To: <tulip@scyld.com>
Sent: Friday, November 24, 2000 2:19 PM
Subject: [tulip] Header Files and Compilation Instructions


> OK, I don't subscribe to linux-kernel because i don't want
> to put up with this kind of flamewar.  That's why kernel traffic
> exists (for flamewars and people unfairly picking on Donald :)
>
> SO, something has to be resolved.  Although I like seeing SOME
> traffic on this list, too much of the same questions is too much :)
>
> Here is the situation, as I see it.  I'll try not to rant about
> the problems I have with compiling glibc or working with different
> kernels, i'll just stick to the main points :
>
> 1 - glibc requires linux kernel headers.  Because applications
>     are tightly coupled to glibc, for maximum stability's sake
>     _applications_ should be compiled against the same header
>     files that glibc uses.  For this reason (and this is what
>     came up on linux-kernel) systems that are expected to
>     compile applications should not use the symlink method of
>     linking the kernel header files, but should have a fixed
>     directory having the right files.
>
> 2 - kernel modules (DUH! :) and other kernel-specific tools aren't
>     really concerned with glibc, they're concerned with the kernel,
>     and they MUST be compiled against the header files from the kernel
>     they're going to be used with.  (Although I know in theory it's
>     not REQUIRED sometimes, it's just plain sensible :) so to compile
>     the tulip module (or any other kernel module for that matter)
>     you should make sure you're linked against the right headers.
>     (which should be as simple as making sure they're in
/usr/src/linux
>     [or that there's a symlink there to the right place] and doing
>     -I/usr/src/linux/include/linux or whatever in your CFLAGS env
variable)
>
> Is there any way we can document this on the scyld website?  maybe we
> can take this offline and I'll volunteer to write it out if people
send
> me all the data that needs to be addressed (I don't have or want
RH7.0,
> so i'd need input :)
>
> this is a problem that all of linux faces, not just redhat, but as far
> as i can tell, redhat goofed in a couple of ways with RH7.0 :
>
> - The default gcc installed is a development release, not accepted or
>   expected to be used as a general release.  Thus, 'kgcc' must be used
>   instead. This is perfectly normal practice for kernel developers,
>   however MOST 'real' hackers aren't having problems here, and this
isn't
>   documented in a lot of places.
>
> - The kernel headers installed by redhat are theoretically the same
that
>   they compiled glibc with (i'll assume they are :) but they don't
include
>   by default the kernel headers for the default kernel they install.
this
>   means that anyone who tries to compile a kernel module from source
will
>   run into a roadblock, and one that's NOT easy for a newbie to
understand.
>
> So does anyone have a total solution?  i.e. if i take a CLEAN,
unmodified
> RH7.0 install, what do I have to do to make sure I can compile the
scyld
> modules?  what packages do I have to make sure I have, what changes do
> i have to make, that kind of thing.
>
> I think that 90% of this can be solved by making sure that everyone
has done
> some basic research before they begin.  Things like "what's your
kernel
> version?"
> should never be answered with "6.2" or "5.1".  And, IMNSHO,
"2.2.16-22" is
> also
> a COMPLETELY invalid answer.
>
> maybe someone (i.e. a redhat user) should compile RPMs on a regular
basis that
> we can simply point people to?  Then the mailing list can go back to
dealing
> with
> the 8365th revision of the Linksys LNE100TX. :)
>
> (trying to get productive discussion going on instead of flamewars
between
> people who aren't having problems but can't decide on how best to help
those
> who are having problems :)
>
> ----
> Dana Lacoste
> Ottawa, Canada
>
>
> _______________________________________________
> tulip mailing list
> tulip@scyld.com
> http://www.scyld.com/mailman/listinfo/tulip