Fw: [tulip] Header Files and Compilation Instructions ( sorry forgot the attachements)

james hill dragonking7@mediaone.net
Fri, 24 Nov 2000 15:15:40 -0500


This is a multi-part message in MIME format.

------=_NextPart_000_0034_01C05629.68425780
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit


I forgot the attachments, I an idiot for sure now


----- Original Message -----
From: "james hill" <dragonking7@mediaone.net>
To: "Dana Lacoste" <dana.lacoste@peregrine.com>; <tulip@scyld.com>
Sent: Friday, November 24, 2000 3:12 PM
Subject: Re: [tulip] Header Files and Compilation Instructions


> 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
>

------=_NextPart_000_0034_01C05629.68425780
Content-Type: text/plain;
	name="post3.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="post3.txt"

I have kernel 2.2.16-22smp install currently. I have installed the
***source*** rpm. I am using RH7.0

> For example, if you have a RedHat 2.2 kernel-source RPM installed,
> (please note ****source****), then since that puts it in
/usr/src/linux
> (against the advice of certain respected people), the switch:

if I use the command 'rpm -ivh kernel-2.2.16-22.src.rpm' this only
places stuff at two locations:

a bunch files goes to /usr/src/redhat/SOURCES and spec files goes to
/usr/src/redhat/SPECS not to /usr/src/linux  There is no directory path
my system such as that either real or symbolic. I tried running the
compiler right the rpm command and it did not work. And after much
fumbling about I came across this article:

http://www.scyld.com/pipermail/tulip/2000-October/002685.html

In the end I have had no luck with ANY "solution" that has been posted
on the this board. Everybody keeps saying this crap about "oh you need
to use this compiler or that compiler" and "use -I/usr/src/linux" or
"-I/usr/src/linux/include"  tag. None of this has worked. I have already
posted what it took to get them to compile. I am not sure I did that
correct.

http://www.tux.org/hypermail/linux-tulip/this-month/0100.html

I have, however, finally gotten those .c files to compile. the only
problem I have now is pci-scan.o has bunch of unresolved symbols and
tulip cannot initialize ie it is reporting device busy. I know my BIOS
is reporting the IRQ to be 10 but linux thinks it's IRQ16 and I don't
know of any way of mapping it. I also have PNP in my BIOS turned-off.
Just so no one is guessing I have a Linksys EtherFast LNE100TX NIC. I
have ran out of Ideas. Any card I go out to buy I will have to compile
the drivers for and I will more then likely run into the same problems.
I guess I could go to another distribution but I may find myself in the
same boat I'm in now. Welcome to World of Linux =3D)


Your crack smokin' linux buddy

Jimmy

------=_NextPart_000_0034_01C05629.68425780
Content-Type: text/plain;
	name="post2.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="post2.txt"

>Special instructions for Red Hat 7.0
>Red Hat 7.0 has a flawed configuration with their default install. It =
>uses the header files from an unreleased 2.3.99 kernel, rather than =
>installing the header files from the kernel that is actually running. =
>While this likely seemed like a good idea to someone, it makes it =
>impossible to automatically build kernel modules.=20

>A second problem is that 7.0 provides an experiment version of gcc that =
>was not intended for public release. The stable version of gcc needed =
to >correctly compile the kernel has been renamed to kgcc.=20

>The work-around is to substitute kgcc for gcc and to add =
>-I/usr/src/linux/include on the compile command line when compiling by =
>hand. The Makefile in the tar file and RPM automatically include this =
>compile flag, however they cannot automatically use 'kgcc'.=20

>To repeat: this is a flaw that was introduced with Red Hat 7.0. It is a =
>Red Hat configuration problem, not a driver=20

 this is from url:
http://www.scyld.com/network/updates.html#redhat7.0


This does not work. Everybody keeps saying it but it does not work. =
RH7.0 default source location after 'rpm -ivh'  for the kernel is =
/usr/src/redhat/SOURCES but then you have to run the SPEC file which =
under /usr/src/redhat/SPECS  to get all the header files even then you =
have to make modifications to it to get it to work right. NO sym link is =
created. So  -I/usr/src/include/linux should be =
-I/usr/src/redhat/BUILD/linux/include   and I still get problems when =
compiling  the .c files because it does not like my modversions.h  The =
only way I have been able to get these drivers to compile is by creating =
an empty modversions.h file.  Now that I have them compiled I getting =
unresolved symbols when I try to install.

Maybe I am smoking crack but I have not been successful at getting these =
drivers at all.=20

=20

I have been reading these boards religiously for two weeks now I even =
went back read aug, sept, oct, this month's posts nothing has worked.  =
Anybody know of another NIC something a NIC -----> USB that has linux =
drivers or better yet a NIC that is already supported.

Your crack smokin' linux buddy

Jimmy


------=_NextPart_000_0034_01C05629.68425780
Content-Type: text/plain;
	name="post1.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="post1.txt"

Conventions
Single quotes represents commands to typed, added or shell output =
messages. Output messages are attached.

I have gone through some of the "fixes" listed on this site. None have
worked thus far.  I still get=20

'no member in function tbusy' or other complaints.

I followed  Reiner Wihelms procedure:     ( I am not meaning to pick on =
you.
Your post has helped me out tremendously)

http://www.scyld.com/pipermail/tulip/2000-October/002685.html

>I finally found on one of the CD roms of the Redhat 7 distribution a
>kernel source rpm (kernel-2.2.16-22.src.rpm) and just went ahead and
>installed it and then started the building process. This takes a long =
time
(and when I
>did it , ended with an error termination). What matters is however
>that before it begins to build the kernel it installs all the proper
include
>files somewhere under /usr/src/redhat/BUILD/linux .... All I needed =
were
>those include files anyway.  Using the actual include files for the =
kernel
> 2.2.16-22 then made all the difference. All I had to do is alter the
>Makefile in the netdrivers distribution.=20

This procedure has gotten me on what I believe to be the right track. It
does, however, fall short of being complete. I had to make some
modifications in  '/usr/src/redhat/SPECS/kernel-2.2.spec' (  I will be
talking to RH about this, they seem to have foresight like a rearview
mirror. ). While Mr. Wihelms says he got the include files before the
command  'rpm -bc /usr/src/redhat/SPECS/kernel-2.2.spec' erred out; I =
did
not.  I loaded the spec file into 'pico' and added a new define tag:=20

'%define sources /usr/src/redhat/SOURCES/'=20

This is specific to RH7. I then made the appropriate changes to the =
'patch'
and 'source' declarations. I also turned on patch 151 ( UDMA66 support )
Someone  please warn me before I use this new kernel in support of my =
BP6
mobo. This allows the build process to flow until completion. I will =
happy
to email any body who wants the modified 'spec' file. This file, like I =
said
earlier, is specific to RH 7.

>rpm -ivh  netdriver-2.0-3.src.rpm   generates a file netdriver.tgz =
under
>/usr/src/redhat/SOURCES and a file netdriver.spec under
/usr/src/redhat/SPECS. To get to=20
>the Makefile one can extract the .tgz file using tar zxvf  =
netdriver.tgz.
In the Makefile
>the symbols INCLUDE and PCMCIA  must be redefined so they point into =
the
proper include file
>directories. (See point B above).=20

>After that all that is needed is to compile the netdrivers using the =
file
make
>in the /usr/src/redhat/BUILD/netdriver directory.

This is not very clear at all and does not work. Since, I am Linux =
newbie, I
would like to see things  stated more explicitly.  Here's why this does =
not
work and I am making assumptions. OK starting after you've done the =
command
'rpm -ivh netdriver-2.0-3.src.rpm' this works fine and is correct as =
listed
above. However, the only way you get =
'/usr/src/redhat/BUILD/netdriver-2.0' (
as far as I can tell ) is by running the next command 'rpm  -bc
/usr/src/redhat/SPECS/netdrivers-2.0.spec' of course this is not stated
explicitly. If you run this command it does work because it extracts the
netdriver.tgz as it runs using the Makefile in it's current embedded =
state.
This Makefile points to wrong the locations. I've tried to use just the
command 'make Makefile' from the .tgz file with the appropriate
modifications. I am still getting compiler complaints. I am using 'kgcc' =
and
not 'gcc'=20

I have even tried using the directions provided by Linksys and Mr. =
Becker now that I have
correct include files. I've even tried to compile 'tulip.c' seperately =
and I am having no luck. I
have tried the i386.rpm file ( moved the 'o' files to correct location
) then tried 'insmod /path/driver.o' ( I try to install pci-scan.c first =
)and '/sbin/depmod -a' and I get 'unresolved symbol' message complaints.

I have a dual-processor system. Do I need to let the compiler know this =
or
is it already assume since my current kernel "2.2.16-22smp"? If so how =
do I
do that?

Please CC me any responses
=20
Jimmy
=20


------=_NextPart_000_0034_01C05629.68425780--