I SOLVED MY PROBLEM!
apparently using the dn.h file from the kernel sources is a bad
thing? not sure but
every time i tried to compile the code, the check_kernel.sh script would take
the dn.h file from the kernel sources and try to compile but there are
some discrepancies with
the file i have in my sources (recently updated too) and the one that
comes with the dnprogs source.
I stopped the code from using the kernel sources, AKA Steve's dn.h
by commenting out the if statement in the check_kernel.sh file, and
then the default dn.h can be used, and the programs finish compiling.
I'm not sure if this was a good idea or not, but for me it helped me
compile the new version and now i'm able to use it so....
ALSO!
FOR GENTOO USERS
I have created a ebuild for dnprogs 2.39
right now its on my local machine as a local overlay but i'd like to
get it out to the public and put it either in the portage tree itself
or an overlay for testing purposes until it can be let in the portage
tree.
but i've tested the ebuild out, and it compiles fine and seems to
install fine.. I'm still working it out so that it doesn't overwrite
any config files that already exist.
It has 2 use flags...
1st USE flag: scottspatch
This patch is right now just for me!, it comments out the
code as stated above so that the correct dn.h file can be use and the
programs finish compiling. If you have problems emerging the package
and the errors are similar to the ones i posted on this list then add
the USE flag scottspatch and try to emerge again.
2nd USE flag: uselocaldir
This patch is for the Makefile.common file. With no patch, when
DISTDIR variable is used, then all the programs default to being
installed usually in /usr/bin or /usr/sbin which isn't the default
when you install manually with make install.. which installs in
/usr/local/bin and /usr/local/sbin.
by adding the USE flag uselocaldir before emerging the package you
can tell the executable programs to be installed in /usr/local/bin and
/usr/loca/sbin as if you were doing a make install manually.
Also the package is masked by the keywords ~arch, for whatever your
architecture is, i.e. ~x86 for the x86 architecture.
I'm still trying to find a way to get this ebuild out so that its
available to everyone.. I'll keep you guys posted.. if anyone has any
questions or comments, email me.
Thanks
Scott Lorberbaum
For anyone else using GENTOO:
On 7/5/07, Scott Lorberbaum <uga...@gm...> wrote:
> changing the dn.h in /usr/include/netdnet didn't help and I played with it
> a bit and with the check_kernel.sh script
> I was able to get it to compile further by not using the dn.h file from the
> kernel headers in
> /usr/src/linux/.
>
> The message below seems to be because there isn't a header file describing
> the type
> __le16, this type is defined in linux/types.h ..if added to the dnet_htoa.c
> file then the types in
> linux/types.h and sys/types.h conflict. Which types.h file is supposed to
> be used..i assume the sys/types.h file
> then why is the compile having trouble and why would it be asking for types
> that are defined in another file.
>
> I don't know very much more about the kernel or this source code but i'm
> trying...anyone else know how to resolve this issue?
> Thanks.
>
>
>
> On Jul 5, 2007, at 3:43 AM, Patrick Caulfield wrote:
>
> Scott Lorberbaum wrote:
> i seem to be unable to compile a new version of dnprogs 39, or even
> recompile 37 of which i had previously compiled on the same machine
> before.
>
> I have recently updated many packages that were a little old as well
> as i am in the middle of upgrading to kernel 2.6.20.
>
> Even running with the new kernel i can't compile?
>
> Here's the output of the compiling.. anything else needed let me
> know..thanks
> make
> Using dn.h from Steve's kernel
> make[1]: Entering directory
> `/home/scott/decnet_programs/dnprogs-2.39/include'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory
> `/home/scott/decnet_programs/dnprogs-2.39/include'
> make[1]: Entering directory
> `/home/scott/decnet_programs/dnprogs-2.39/libdnet'
> gcc -pipe -fsigned-char -Wstrict-prototypes -Wall -Wno-unused
> -Wno-uninitialized -I../libdap -I../include -DVERSION=\"2.39\"
> -D_XOPEN_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -D_SVID_SOURCE
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSHADOW_PWD
> -DDNETUSE_DEVPTS -g -DSYSCONF_PREFIX=\"\" -c -o dnet_htoa.o
> dnet_htoa.c
> In file included from dnet_htoa.c:24:
> ../include/netdnet/dn.h:74: error: expected specifier-qualifier-list
> before '__le16'
> ../include/netdnet/dn.h:80: error: expected specifier-qualifier-list
> before '__u16'
> ../include/netdnet/dn.h:96: error: expected specifier-qualifier-list
> before '__le16'
> ../include/netdnet/dn.h:104: error: expected specifier-qualifier-list
> before '__u8'
> ../include/netdnet/dn.h:116: error: expected specifier-qualifier-list
> before '__le16'
> ../include/netdnet/dn.h:124: error: expected specifier-qualifier-list
> before '__u8'
> ../include/netdnet/dn.h:136: error: expected specifier-qualifier-list
> before '__le16'
> dnet_htoa.c: In function 'dnet_htoa':
> dnet_htoa.c:35: error: 'struct dn_naddr' has no member named 'a_addr'
> dnet_htoa.c:36: error: 'struct dn_naddr' has no member named 'a_addr'
> dnet_htoa.c:36: error: 'struct dn_naddr' has no member named 'a_addr'
> make[1]: *** [dnet_htoa.o] Error 1
> make[1]: Leaving directory
> `/home/scott/decnet_programs/dnprogs-2.39/libdnet'
> make: *** [all] Error 2
>
>
>
> It looks like you're using the dn.h file straight from the kernel sources
> rather
> than from the dnprogs package.
>
> --
>
> patrick
>
> Scott Lorberbaum
> uga...@gm...
> System/Network Admin
> IT Manager
>
>
>
>
--
Scott Lorberbaum
System/Network Administrator
Computer/Network Consultant
Software Engineer
|