Ignore this.  My include directory was confused and contained header files
from an old kernel.  ad_open.c compiles now.

However, I'm having another problem in getiface.c:
gcc  -p -DSENDFILE_FLAVOR_LINUX   -DHAVE_IFNAMEINDEX -O2
-fomit-frame-pointer -fsigned-char -Wunused -Wuninitialized
-I../../include -c getiface.c
getiface.c: In function `getnameindex':
getiface.c:83: warning: assignment makes pointer from integer without a
cast
getiface.c:84: dereferencing pointer to incomplete type
getiface.c:86: dereferencing pointer to incomplete type
getiface.c:88: increment of pointer to unknown structure
getiface.c:88: arithmetic on pointer to an incomplete type
getiface.c: At top level:
getiface.c:39: warning: `getifconf' defined but not used


Any ideas?  Thanks.



On Fri, 31 Dec 1999, Andrew McNabb wrote:

> I'm trying out pre37 on my Linux 2.2.3 system and I can't get it to
> compile.  In include/atalk/adouble.h, it mentions the syscall
> __NR_sendfile, which isn't in my asm/unistd.h.  Here's gcc's complaint:
> 
> gcc  -p -DSENDFILE_FLAVOR_LINUX   -DHAVE_IFNAMEINDEX -O2
> -fomit-frame-pointer -fsigned-char -Wunused -Wuninitialized
> -I../../include -c ad_open.c
> ../../include/atalk/adouble.h: In function `sendfile':
> In file included from ad_open.c:38:
> ../../include/atalk/adouble.h:50: `__NR_sendfile' undeclared (first use
> this function)
> ../../include/atalk/adouble.h:50: (Each undeclared identifier is reported
> only once
> ../../include/atalk/adouble.h:50: for each function it appears in.)
> 
> 
> 
> 
> On Thu, 30 Dec 1999, a sun wrote:
> 
> > 
> > hi all,
> > 
> > here's something on the eve of the year before some arbitrarily
> > specified millenium. it has a few more things ticked off from the
> > list:
> > 
> >        1) password changing via dhx. the client-side is a little
> >           buggy, so i don't check a few things that i should.
> >        
> >            2) a workaround for a problem with large quantum sizes in
> >               os 9. you can now report whatever quantum size you wish
> >               to the client. netatalk doesn't care, but the appleshare
> >               client doesn't seem to like large values. read
> >               config/afpd.conf. 
> > 
> >            3) sundry os x bits. i still haven't fixed
> >               everything. however, netatalk is now using the same
> >               values as apple's appletalk router.
> > 
> >            4) more interface detection code. for those systems that
> >               support if_nameindex, you can now specify
> >               -DHAVE_IFNAMEINDEX. that should include glibc 2.1 +
> >               linux 2.2, solaris 8 (nee 2.8), and i think some of the
> >               newer bsd's.
> > 
> >           afpd will now use the ip address of the first valid
> >           interface that it can find if your dns is screwed up and
> >           you don't have the hostname in /etc/hosts.
> > 
> >           QUESTION: does SIOCGIFCONF just not work with ddp on
> >           solaris, or does it just not work in general? if it
> >           doesn't work with ddp, does it report an error when
> >           used, or does it report something random?
> > 
> >            5) afpd will no longer report an error if it can't set the
> >               desktop directory's ownership/permissions.
> > 
> > the site:
> >     ftp.cobaltnet.com:/pub/users/asun/testing/pre-asun2.1.4-37.tar.gz
> > 
> > this is almost a release candidate. i'll take another look at what's
> > needed for os x, but that's about all i'll do. unless a kerberos uam
> > spec with details of what gets passed back and forth with the
> > appropriate bit sizes and what not miraculously appears in my inbox,
> > the kerberos uam won't work. you'll just have to use pam. for those
> > interested in writing their own uams, let me know if the interface
> > makes sense to you. read include/atalk/uam.h for the exported
> > interface and the modules in etc/uams for actual
> > implementations. 
> > 
> > also, i would like reports for the various bsd's on the necessary
> > flags to get the runtime library linking to work correctly. here's
> > what i need: os rev, architecture, and flags. i think the elf-based
> > systems are all the same, but i'm not sure. 
> > 
> > 
> > 
> > 
> > -- and now for more on the future --
> > 
> > please let me know what's desired for the asun2.3.x series. here's the
> > list of things that i would like to see done:
> >      1) db support. actually, quite a bit of this is already done. i
> >         just have to go through and finish it and integrate it with
> >         afpd.
> > 
> >      2) incorporation of the papd/pap patches. note: for printer
> >         authentication, i would like to see use of the same uams as
> >         afpd uses. if you look in etc/uams, you'll see that i already
> >         have stubs for printer authentication support.
> > 
> >      3) permission/ownership overhaul. i already have some patches for
> >         client-based administration, so i'll probably base some of
> >         this off that. basically, this will add the ability to specify
> >     an administrative user/group.
> > 
> >      4) afp client support so that you can have an ftp-style
> >         interface to an afp server.
> > 
> >      5) SLP support so that we can do nbp-style registration via
> >         tcp/ip. if someone's willing to work on an opensource SLP
> >         library (there's already an rfc with c language bindings), i'd
> >         appreciate it.
> > 
> >      6) autoconf support. i have some patches for this already. this
> >         should make building afp/tcp much easier on random unix-style
> >         oses as well as avoiding headaches with runtime dynamic
> >         linkage that the bsd's seem to foster.
> > 
> > -a           
> > [EMAIL PROTECTED]
> > 
> 
> ----------------------------------------------
>                 Andrew McNabb
>              Argus Systems Group
>           [EMAIL PROTECTED]
> ----------------------------------------------
> 
> 

----------------------------------------------
                Andrew McNabb
             Argus Systems Group
          [EMAIL PROTECTED]
----------------------------------------------

Reply via email to