#1 Any support for older Linux Kernels?

v0.2.2
closed-fixed
Compilation (4)
5
2005-07-13
2004-11-14
LossAngeles
No

I'm trying to get past this pest. Is there any work
around for older 2.0 series kernels? MSG_WAITALL isn't
supported in the 2.0 series from what I can tell.
Thx,
-Greg

tiki:/usr/local/sid-milter-0.2.2/obj.Linux.2.0.37.i686/libar#
cc -O2 -I. -I../../include -D_REENTRANT -DXP_MT -c
ar.c -o ar.o
ar.c: In function `ar_dispatcher':
ar.c:614: `MSG_WAITALL' undeclared (first use this
function)
ar.c:614: (Each undeclared identifier is reported only once
ar.c:614: for each function it appears in.)
tiki:/usr/local/sid-milter-0.2.2/obj.Linux.2.0.37.i686/libar#

Discussion

    • assigned_to: nobody --> sm-msk
     
  • Logged In: YES
    user_id=1048957

    I don't appear to be able to find anyone running a machine
    that old, so you'll have to help me out here. Can you send
    me the man page for recvfrom()?

     
  • LossAngeles
    LossAngeles
    2004-11-18

    Logged In: YES
    user_id=1158788

    Here you go. If you need anything let me know.
    Thx,
    -Greg

    RECV(2) Linux Programmer's Manual
    RECV(2)

    NAME
    recv, recvfrom, recvmsg - receive a message from a socket

    SYNOPSIS
    #include <sys/types.h>
    #include <sys/socket.h>

    int recv(int s, void *buf, int len, unsigned int flags);

    int recvfrom(int s, void *buf, int len, unsigned int
    flags struct sockaddr *from, socklen_t *fromlen);

    int recvmsg(int s, struct msghdr *msg, unsigned int
    flags);

    DESCRIPTION
    The recvfrom and recvmsg are used to receive messages
    from a socket, and may be used to receive data on a socket
    whether or not it is connection-oriented.

    If from is non-nil, and the socket is not
    connection-oriented, the source address of the message is
    filled in.
    Fromlen is a value-result parameter, initialized to
    the size of the buffer associated with from, and modified on
    return to indicate the actual size of the address
    stored there.

    The recv call is normally used only on a connected
    socket (see connect(2)) and is identical to recvfrom with a
    nil from parameter. As it is redundant, it may not
    be supported in future releases.

    All three routines return the length of the message
    on successful completion. If a message is too long to fit
    in the supplied buffer, excess bytes may be discarded
    depending on the type of socket the message is received
    from (see socket(2)).

    If no messages are available at the socket, the
    receive call waits for a message to arrive, unless the socket is
    nonblocking (see fcntl(2)) in which case the value -1
    is returned and the external variable errno set to EWOULD-
    BLOCK. The receive calls normally return any data
    available, up to the requested amount, rather than waiting
    for receipt of the full amount requested; this
    behavior is affected by the socket-level options SO_RCVLOWAT
    and
    SO_RCVTIMEO described in getsockopt(2).

    The select(2) call may be used to determine when more
    data arrive.

    The flags argument to a recv call is formed by or'ing
    one or more of the values:

    MSG_OOB process out-of-band data

    MSG_PEEK
    peek at incoming message
    line 1

    MSG_WAITALL
    wait for full request or error

    The MSG_OOB flag requests receipt of
    out-of-band data that would not be received in the normal data
    stream. Some protocols place expedited data
    at the head of the normal data queue, and thus this flag
    cannot be used with such protocols. The
    MSG_PEEK flag causes the receive operation to return data from
    the beginning of the receive queue without
    removing that data from the queue. Thus, a subsequent
    receive call will return the same data.
    The MSG_WAITALL flag requests that the operation block until
    the full request is satisfied. However, the
    call may still return less data than requested if a signal

    BSD Man Page 24 July 1993
    1

    RECV(2) Linux Programmer's Manual
    RECV(2)

    is caught, an error or disconnect occurs,
    or the next data to be received is of a different type than
    that returned.

    The recvmsg call uses a msghdr structure to
    minimize the number of directly supplied parameters. This
    structure has the following form, as defined
    in sys/socket.h:

    struct msghdr {
    caddr_t msg_name; /* optional address */
    u_int msg_namelen; /* size of
    address */
    struct iovec *msg_iov; /*
    scatter/gather array */
    u_int msg_iovlen; /* # elements
    in msg_iov */
    caddr_t msg_control; /* ancillary
    data, see below */
    u_int msg_controllen; /* ancillary
    data buffer len */
    int msg_flags; /* flags on received
    message */
    };

    Here msg_name and msg_namelen specify the
    destination address if the socket is unconnected; msg_name
    may be
    given as a null pointer if no names are desired or
    required. Msg_iov and msg_iovlen describe scatter gather
    locations, as discussed in readv(2). Msg_control,
    which has length msg_controllen, points to a buffer for other
    protocol control related messages or other
    miscellaneous ancillary data. The messages are of the form:

    struct cmsghdr {
    u_int cmsg_len; /* data byte count,
    including hdr */
    int cmsg_level; /* originating
    protocol */
    int cmsg_type; /* protocol-specific
    type */
    /* followed by
    u_char cmsg_data[]; */
    };

    As an example, one could use this to learn of changes
    in the data-stream in XNS/SPP, or in ISO, to obtain user-
    connection-request data by requesting a recvmsg with
    no data buffer provided immediately after an accept call.

    Open file descriptors are now passed as
    ancillary data for AF_UNIX domain sockets, with cmsg_level
    set to
    SOL_SOCKET and cmsg_type set to SCM_RIGHTS.

    The msg_flags field is set on return according to the
    message received. MSG_EOR indicates end-of-record; the
    data returned completed a record (generally used with
    sockets of type SOCK_SEQPACKET). MSG_TRUNC indicates that
    the trailing portion of a datagram was discarded
    because the datagram was larger than the buffer supplied.
    MSG_CTRUNC indicates that some control data were
    discarded due to lack of space in the buffer for ancillary
    data. MSG_OOB is returned to indicate that expedited
    or out-of-band data were received.

    RETURN VALUES
    These calls return the number of bytes received, or
    -1 if an error occurred.

    ERRORS
    EBADF The argument s is an invalid descriptor.

    ENOTCONN
    The socket is associated with a
    connection-oriented protocol and has not been connected (see
    connect(2)
    and accept(2)).

    ENOTSOCK
    The argument s does not refer to a socket.

    BSD Man Page 24 July 1993
    2

    RECV(2) Linux Programmer's Manual
    RECV(2)

    EWOULDBLOCK
    The socket is marked non-blocking, and the
    receive operation would block, or a receive timeout had been
    set, and the timeout expired before data were
    received.

    EINTR The receive was interrupted by delivery of a
    signal before any data were available.

    EFAULT The receive buffer pointer(s) point outside
    the process's address space.

    CONFORMING TO
    4.4BSD (these function calls first appeared in 4.2BSD).

    NOTE
    The sixth argument of recvfrom is in reality an `int
    *' (and this is what BSD 4.* and libc4 and libc5 have).
    Some POSIX confusion resulted in the present
    socklen_t. The draft standard has not been adopted yet, but
    glibc2
    already follows it and also has `socklen_t *'. See
    also accept(2).

    SEE ALSO
    fcntl(2), read(2), select(2), getsockopt(2), socket(2)

    BSD Man Page 24 July 1993
    3

     
  • Logged In: YES
    user_id=1048957

    Well your man page seems to disagree with your system. It
    shows support for MSG_WAITALL, but then fails to compile
    when I try to use it. It shows <sys/types.h> and
    <sys/socket.h> are all I need to make this work, and ar.c is
    including both of those already.

    Try this, and tell me if anything comes up:

    % fgrep MSG_WAITALL /usr/include/* /usr/include/*/*

     
  • LossAngeles
    LossAngeles
    2004-11-19

    Logged In: YES
    user_id=1158788

    Here is the output of the fgrep command. Re: Man pages, that
    is very odd. The only thing I can think of is that when I
    installed Slackware 4.0, it had 2 packages, one with the 2.2
    series kernel and one with the older but more stable at the
    time 2.0 series. I opted for the 2.0 for legacy app
    compatibility issues.

    tiki:/usr# fgrep MSG_WAITALL /usr/include/* /usr/include/*/*
    fgrep: /usr/include/arpa: Is a directory
    fgrep: /usr/include/asm: Is a directory
    fgrep: /usr/include/bsd: Is a directory
    fgrep: /usr/include/et: Is a directory
    fgrep: /usr/include/ext2fs: Is a directory
    fgrep: /usr/include/g++: Is a directory
    fgrep: /usr/include/gnu: Is a directory
    fgrep: /usr/include/i386: Is a directory
    fgrep: /usr/include/linux: Is a directory
    fgrep: /usr/include/m68k: Is a directory
    fgrep: /usr/include/ncurses: Is a directory
    fgrep: /usr/include/net: Is a directory
    fgrep: /usr/include/netatalk: Is a directory
    fgrep: /usr/include/netinet: Is a directory
    fgrep: /usr/include/oldcurses: Is a directory
    fgrep: /usr/include/protocols: Is a directory
    fgrep: /usr/include/pthread: Is a directory
    fgrep: /usr/include/rpc: Is a directory
    fgrep: /usr/include/rpcsvc: Is a directory
    fgrep: /usr/include/rpm: Is a directory
    fgrep: /usr/include/scsi: Is a directory
    fgrep: /usr/include/shadow: Is a directory
    fgrep: /usr/include/ss: Is a directory
    fgrep: /usr/include/sys: Is a directory
    fgrep: /usr/include/uuid: Is a directory
    fgrep: /usr/include/bsd/sys: Is a directory
    fgrep: /usr/include/g++/std: Is a directory
    fgrep: /usr/include/linux/modules: Is a directory
    fgrep: /usr/include/pthread/mit: Is a directory
    tiki:/usr#

     
  • LossAngeles
    LossAngeles
    2004-11-19

    Logged In: YES
    user_id=1158788

    I found this thread on google.com. MSG_WAITALL is definately
    not defined on my system (as per the fgrep output). I'll see
    what else I can find :-).
    -Greg

    http://www.ussg.iu.edu/hypermail/linux/kernel/9808.1/1366.html

     
  • LossAngeles
    LossAngeles
    2004-11-19

    Logged In: YES
    user_id=1158788

    I did some research and though the 2.0 man page says it
    supports that flag, the kernel doesn't. The MySQL dev team
    fixed this issue but I couldn't find the details on it. I'll
    keep looking )
    -Greg

     
  • LossAngeles
    LossAngeles
    2004-11-19

    Logged In: YES
    user_id=1158788

    It looks like the fix for this is to remove the flag for
    these older 2.0 kernel / glib 2.0 systems.

     
  • Logged In: YES
    user_id=1048957

    libar modified to not use MSG_WAITALL unless it's defined.
    This will be fixed in the next release. In the interim,
    there's a patch attached.

     
  • Patch to ar.c

     
    Attachments
    • status: open --> closed
     
  • Logged In: YES
    user_id=1048957

    v0.2.3 released.

     
    • status: closed --> closed-fixed