[tulip] Header Files and Compilation Instructions

[Phil Barone]

I agree, lets focus on the productive. I am still in the middle of my build
so can relate any experiences I have with the list or offline. Let me know
how I can help.

> -----Original Message-----
> From: tulip-admin@scyld.com [mailto:tulip-admin@scyld.com]On Behalf Of
> Dana Lacoste
> Sent: Friday, November 24, 2000 2:19 PM
> To: tulip@scyld.com
> 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