DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN? - TCP-IP

This is a discussion on DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN? - TCP-IP ; Hi folks, My last post here was quite helpful so I'm hoping it'll be even better this time. I just wanted to know if the DNS Nameserver functions ( whose declarations are given in ) have to be user-defined. I ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

  1. DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    Hi folks,
    My last post here was quite helpful so I'm hoping it'll be even

    better this time. I just wanted to know if the DNS Nameserver functions

    ( whose declarations are given in ) have to be
    user-defined.


    I have some existing code which uses ns_initparse(), ns_sprintrr(),
    ns_parserr() and some other Nameserver functions.... But the code works

    fine for ns_parserr() without including the source file containing it's

    body while functions like ns_initparse() do not work without the source

    file containing their definition. I really need the answer urgently...
    so can somebody please clarify this point?


    Regards,


    Timmy Jose.


  2. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    In article <1139573844.065915.259500@g47g2000cwa.googlegroups. com>,
    "zoltan" wrote:

    > Hi folks,
    > My last post here was quite helpful so I'm hoping it'll be even
    >
    > better this time. I just wanted to know if the DNS Nameserver functions
    >
    > ( whose declarations are given in ) have to be
    > user-defined.
    >
    >
    > I have some existing code which uses ns_initparse(), ns_sprintrr(),
    > ns_parserr() and some other Nameserver functions.... But the code works
    >
    > fine for ns_parserr() without including the source file containing it's
    >
    > body while functions like ns_initparse() do not work without the source
    >
    > file containing their definition. I really need the answer urgently...
    > so can somebody please clarify this point?


    This is a general C question, not really specific to DNS. In C, if you
    don't provide a declaration for a function, a default prototype is
    created. If the function happens to be compatible with the default,
    then it will work properly without the declaration.

    So it's just an accident that some of the functions work. The
    compatibility may be implementation-dependent in some cases (for
    instance, if pointers and ints are the same size), so it could work on
    one type of system but fail on others.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Barry Margolin wrote:
    > In article <1139573844.065915.259500@g47g2000cwa.googlegroups. com>,
    > "zoltan" wrote:
    >
    > > Hi folks,
    > > My last post here was quite helpful so I'm hoping it'll be even
    > >
    > > better this time. I just wanted to know if the DNS Nameserver functions
    > >
    > > ( whose declarations are given in ) have to be
    > > user-defined.
    > >
    > >
    > > I have some existing code which uses ns_initparse(), ns_sprintrr(),
    > > ns_parserr() and some other Nameserver functions.... But the code works
    > >
    > > fine for ns_parserr() without including the source file containing it's
    > >
    > > body while functions like ns_initparse() do not work without the source
    > >
    > > file containing their definition. I really need the answer urgently...
    > > so can somebody please clarify this point?

    >
    > This is a general C question, not really specific to DNS. In C, if you
    > don't provide a declaration for a function, a default prototype is
    > created. If the function happens to be compatible with the default,
    > then it will work properly without the declaration.
    >
    > So it's just an accident that some of the functions work. The
    > compatibility may be implementation-dependent in some cases (for
    > instance, if pointers and ints are the same size), so it could work on
    > one type of system but fail on others.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***


    Well, I'd been careful enough to check that the other "non-working"
    functions too had the same number and type of parameters... but they
    didn't work.


  4. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    In article <1139589124.279779.4110@g44g2000cwa.googlegroups.co m>,
    "zoltan" wrote:

    > Barry Margolin wrote:
    > > In article <1139573844.065915.259500@g47g2000cwa.googlegroups. com>,
    > > "zoltan" wrote:
    > >
    > > > Hi folks,
    > > > My last post here was quite helpful so I'm hoping it'll be even
    > > >
    > > > better this time. I just wanted to know if the DNS Nameserver functions
    > > >
    > > > ( whose declarations are given in ) have to be
    > > > user-defined.
    > > >
    > > >
    > > > I have some existing code which uses ns_initparse(), ns_sprintrr(),
    > > > ns_parserr() and some other Nameserver functions.... But the code works
    > > >
    > > > fine for ns_parserr() without including the source file containing it's
    > > >
    > > > body while functions like ns_initparse() do not work without the source
    > > >
    > > > file containing their definition. I really need the answer urgently...
    > > > so can somebody please clarify this point?

    > >
    > > This is a general C question, not really specific to DNS. In C, if you
    > > don't provide a declaration for a function, a default prototype is
    > > created. If the function happens to be compatible with the default,
    > > then it will work properly without the declaration.

    >
    > Well, I'd been careful enough to check that the other "non-working"
    > functions too had the same number and type of parameters... but they
    > didn't work.


    Then could you provide more information about the ways in which these
    functions don't work? Do they return incorrect results, do they report
    errors, what?

    Have you checked whether the functions' calling sequences really match
    up with the default prototypes that will be generated? If not, the C
    specification allows any behavior, including sometimes working and
    sometimes not.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  5. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Barry Margolin wrote:
    > In article <1139589124.279779.4110@g44g2000cwa.googlegroups.co m>,
    > "zoltan" wrote:
    >
    > > Barry Margolin wrote:
    > > > In article <1139573844.065915.259500@g47g2000cwa.googlegroups. com>,
    > > > "zoltan" wrote:
    > > >
    > > > > Hi folks,
    > > > > My last post here was quite helpful so I'm hoping it'll be even
    > > > >
    > > > > better this time. I just wanted to know if the DNS Nameserver functions
    > > > >
    > > > > ( whose declarations are given in ) have to be
    > > > > user-defined.
    > > > >
    > > > >
    > > > > I have some existing code which uses ns_initparse(), ns_sprintrr(),
    > > > > ns_parserr() and some other Nameserver functions.... But the code works
    > > > >
    > > > > fine for ns_parserr() without including the source file containing it's
    > > > >
    > > > > body while functions like ns_initparse() do not work without the source
    > > > >
    > > > > file containing their definition. I really need the answer urgently...
    > > > > so can somebody please clarify this point?
    > > >
    > > > This is a general C question, not really specific to DNS. In C, if you
    > > > don't provide a declaration for a function, a default prototype is
    > > > created. If the function happens to be compatible with the default,
    > > > then it will work properly without the declaration.

    > >
    > > Well, I'd been careful enough to check that the other "non-working"
    > > functions too had the same number and type of parameters... but they
    > > didn't work.

    >
    > Then could you provide more information about the ways in which these
    > functions don't work? Do they return incorrect results, do they report
    > errors, what?
    >
    > Have you checked whether the functions' calling sequences really match
    > up with the default prototypes that will be generated? If not, the C
    > specification allows any behavior, including sometimes working and
    > sometimes not.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***


    Dear Barry,

    Here's a part of the process :


    [timmyj@ibis:/users/in1478c/GUIDEPROGS~]gcc -Wall -g myDns.c -lsocket
    -lnsl -lresolv
    myDns.c: In function `send_ptr_query':
    myDns.c:108: warning: initialization from incompatible pointer type
    myDns.c:108: warning: initialization from incompatible pointer type
    Undefined first referenced
    symbol in file
    __ns_name_uncompress /var/tmp//ccGTqvma.o
    ld: fatal: Symbol referencing errors. No output written to a.out
    collect2: ld returned 1 exit status
    [timmyj@ibis:/users/in1478c/GUIDEPROGS~]



    The function ns_name_uncompress is geiven as a prototype in

    but the file 'myDns.c' does not contain the definition. ( It is present
    in another source file called 'rr_name.c'...) But some other functions
    such as 'ns_parserr' whose prototypes are present in the same header
    file and whose bodies are not defined in the 'myDns.c' source file do
    not generate any error!!!


    The calling function is :

    if (ns_name_uncompress(
    ns_msg_base(handle),/* Start of the
    packet */
    ns_msg_end(handle), /* End of the
    packet */
    ns_rr_rdata(rr), /* Position in the
    packet*/
    hostname, /*Result*/
    255) /* Size of server
    name buffer */
    < 0)
    { /* Negative: error */
    printf(", ns_name_uncompress failed on %dth
    record\n",rrnum);
    continue;
    }
    printf(", Server name : %s\n", hostname);

    The types are as follows :

    // The code from the header file arpa/nameser.h
    typedef struct __ns_msg {
    const uchar_t *_msg, *_eom;
    uint16_t _id, _flags, _counts[ns_s_max];
    const uchar_t *_sections[ns_s_max];
    ns_sect _sect;
    int _rrnum;
    const uchar_t *_ptr;
    } ns_msg;

    /* Private data structure - do not use from outside library. */
    struct _ns_flagdata { int mask, shift; };
    extern struct _ns_flagdata _ns_flagdata[];

    /* Accessor macros - this is part of the public interface. */
    #define ns_msg_id(handle) ((handle)._id + 0)
    #define ns_msg_base(handle) ((handle)._msg + 0)
    #define ns_msg_end(handle) ((handle)._eom + 0)
    #define ns_msg_size(handle) ((handle)._eom - (handle)._msg)
    #define ns_msg_count(handle, section) ((handle)._counts[section] + 0)

    The prototype of the ns_name_uncompress function given in the
    header file is :

    int ns_name_uncompress(const uchar_t *, const uchar_t *,
    const uchar_t *, char *, size_t);

    As you can see, the types in the prototype and the invocation are the
    same!!!!
    Any ideas, please?!

    Regards,

    Timmy Jose.


  6. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    In article <1139807948.912273.238500@g44g2000cwa.googlegroups. com>,
    "zoltan" wrote:
    [excess quoting snipped]
    > Here's a part of the process :
    >
    >
    > [timmyj@ibis:/users/in1478c/GUIDEPROGS~]gcc -Wall -g myDns.c -lsocket
    > -lnsl -lresolv
    > myDns.c: In function `send_ptr_query':
    > myDns.c:108: warning: initialization from incompatible pointer type
    > myDns.c:108: warning: initialization from incompatible pointer type
    > Undefined first referenced
    > symbol in file
    > __ns_name_uncompress /var/tmp//ccGTqvma.o
    > ld: fatal: Symbol referencing errors. No output written to a.out
    > collect2: ld returned 1 exit status
    > [timmyj@ibis:/users/in1478c/GUIDEPROGS~]
    >
    > The function ns_name_uncompress is geiven as a prototype in
    >


    The warning messages are not referring to ns_name_uncompress, they're
    referring to something on line 108 of myDNS.c. Since you didn't include
    line numbers below, I can't tell what the problem is.

    > but the file 'myDns.c' does not contain the definition. ( It is present
    > in another source file called 'rr_name.c'...) But some other functions
    > such as 'ns_parserr' whose prototypes are present in the same header
    > file and whose bodies are not defined in the 'myDns.c' source file do
    > not generate any error!!!


    The reason for the undefined symbol error is because you didn't link in
    rr_name.o. You also didn't use the -c option when you compiled, so it's
    trying to generate an executable rather than just an object file, so it
    needs to link everything together.

    I think you really need to brush up on your Unix and C programming
    skills. You don't seem to understand the errors your compiler is
    generating, and they are not specific to DNS.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  7. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Barry Margolin wrote:
    > In article <1139807948.912273.238500@g44g2000cwa.googlegroups. com>,
    > "zoltan" wrote:
    > [excess quoting snipped]
    > > Here's a part of the process :
    > >
    > >
    > > [timmyj@ibis:/users/in1478c/GUIDEPROGS~]gcc -Wall -g myDns.c -lsocket
    > > -lnsl -lresolv
    > > myDns.c: In function `send_ptr_query':
    > > myDns.c:108: warning: initialization from incompatible pointer type
    > > myDns.c:108: warning: initialization from incompatible pointer type
    > > Undefined first referenced
    > > symbol in file
    > > __ns_name_uncompress /var/tmp//ccGTqvma.o
    > > ld: fatal: Symbol referencing errors. No output written to a.out
    > > collect2: ld returned 1 exit status
    > > [timmyj@ibis:/users/in1478c/GUIDEPROGS~]
    > >
    > > The function ns_name_uncompress is geiven as a prototype in
    > >

    >
    > The warning messages are not referring to ns_name_uncompress, they're
    > referring to something on line 108 of myDNS.c. Since you didn't include
    > line numbers below, I can't tell what the problem is.
    >
    > > but the file 'myDns.c' does not contain the definition. ( It is present
    > > in another source file called 'rr_name.c'...) But some other functions
    > > such as 'ns_parserr' whose prototypes are present in the same header
    > > file and whose bodies are not defined in the 'myDns.c' source file do
    > > not generate any error!!!

    >
    > The reason for the undefined symbol error is because you didn't link in
    > rr_name.o. You also didn't use the -c option when you compiled, so it's
    > trying to generate an executable rather than just an object file, so it
    > needs to link everything together.
    >
    > I think you really need to brush up on your Unix and C programming
    > skills. You don't seem to understand the errors your compiler is
    > generating, and they are not specific to DNS.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***


    Dear Barry,
    This is the height of incredulity!!! I had rather thought you would
    have given some idea about the problem rather than advise me to brush
    up my UNIX and C skills. Both are quite fine by the way.

    The warnings are inconsequential - they are jusy because of a macro
    that I have used.

    Of course, rr_name.o needs to be linked in... that's the definition of
    the problem itself! I had mentioned that the problem is that
    "rr_name.c" contains the definitions of "ns_name_uncompress" and some
    other functions... and these ARE required when compiling the program.
    However, there is another set of functions such as "ns_parserr" which
    are defined in yet another file called "rr_parse.c" which DOES NOT
    require to be included in the compilation line.

    My question is, since both "ns_name_uncompress" and "ns_parserr" are
    declared in , why does ns_parserr(...) work without a
    USER-DEFINED body while ns_name_uncompress(...) works WITH A
    USER_DEFINED body?


    BTW, here's the actual makefile which I use for the program.

    #sample makefile

    INC =

    SRCS = myDns.c rr_name.c
    OBJS = $(SRCS:%.c=%.o)
    ifeq ($(PLATFORM), linux)
    CC=linux-cc
    endif

    PROG = dns_test
    CC = gcc
    CFLAGS = -Wall -g
    C_LIBS = -lsocket -lnsl -lresolv

    LD_FLAGS =


    all: $(PROG)

    $(PROG): $(OBJS)
    $(CC) $(C_LIBS) $(LD_FLAGS) $(OBJS) -o $@

    ..c.o:
    $(CC) -c $(CFLAGS) $(INC) $<
    ..C.o:
    g++ -c $(CFLAGS) $(INC) $<
    clean:
    /bin/rm -rf $(OBJS) core $(PROG)


    So, as you can see, the compiling and linking are done quite fine. The
    previous screen shot was to simply demonstrate what happens when I
    compile ONLY the main source file, "myDns.c"!!! I hope you can have
    some original ideas now!

    Regards,

    Timmy Jose.
    ~
    ~
    ~
    ~
    ~
    ~


  8. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    Talk to Sun.

    % nm libresolv.so | grep ns_name_uncompress
    [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    % nm libresolv.so | grep ns_parserr
    [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    % uname -a
    SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    %

    I agree with Barry. You really do need to learn about what happens
    when you are linking a program. Unless you know what is happening
    you don't have a chance of diagnosing problems be it with your code or
    with what is supplied to you.

    Mark

  9. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Mark Andrews wrote:
    > Talk to Sun.
    >
    > % nm libresolv.so | grep ns_name_uncompress
    > [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    > % nm libresolv.so | grep ns_parserr
    > [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > % uname -a
    > SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    > %
    >
    > I agree with Barry. You really do need to learn about what happens
    > when you are linking a program. Unless you know what is happening
    > you don't have a chance of diagnosing problems be it with your code or
    > with what is supplied to you.
    >
    > Mark


    Hi,
    Thanks for those commands. The command shows the same output on my
    system too.... I don't think the problem is with knowledge about
    linking. The makefile given shows that I am including the relevant
    libraries and the source files as well. And I do understand the process
    of compilation and linking pretty deep. I have been working on such
    stuff in depth. That's why I sought this forum to see if there was any
    problem other than with the OS itself. The command outputs show the
    presence of the definitions in the relevant library, but they work
    selectively... well, maybe I should talk to the OS vendor.

    Output on my system :

    [timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_name_uncompress
    [146] | 137940| 84|FUNC |LOCL |0 |9
    |__ns_name_uncompress
    [timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_parserr
    [1569] | 139684| 664|FUNC |GLOB |0 |9 |__ns_parserr
    [timmyj@ibis:/usr/lib~]uname -a
    SunOS ibis 5.8 Generic_117350-16 sun4u sparc SUNW,Ultra-4


    Regards,

    Timmy Jose.


  10. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    In article <1139914688.627880.102120@g43g2000cwa.googlegroups. com>,
    zoltan wrote:
    >
    >Mark Andrews wrote:
    >> Talk to Sun.
    >>
    >> % nm libresolv.so | grep ns_name_uncompress
    >> [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    >> % nm libresolv.so | grep ns_parserr
    >> [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    >> % uname -a
    >> SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    >> %
    >>
    >> I agree with Barry. You really do need to learn about what happens
    >> when you are linking a program. Unless you know what is happening
    >> you don't have a chance of diagnosing problems be it with your code or
    >> with what is supplied to you.
    >>
    >> Mark

    >
    >Hi,
    > Thanks for those commands. The command shows the same output on my
    >system too.... I don't think the problem is with knowledge about
    >linking.


    Actually it is. Linking isn't just about specifying libraries
    on the command line. It's about knowing in what order and
    when the loader will link a symbol (object) into the resulting
    executable. You also need to know how shared and static
    libraries behave differently especially which mixing
    and matching them.

    While the two symbols are there they have different scopes.
    __ns_name_uncompress is only visible to functions with the
    library while __ns_parserr is visible to the application.

    In C you have static and global functions. When shared
    libraries are built you can make some of those global
    functions private to the library or, like when you build a
    dll under Windows, all the globals become private unless
    you specify them in the .def file. The aim is to reduce
    namespace pollution and to hide global function which are
    intended to be private to the library.

    > The makefile given shows that I am including the relevant
    >libraries


    In the wrong order, though that isn't the current problem.
    "-lresolv -lsocket -lnsl" is the correct link order.

    >and the source files as well. And I do understand the process
    >of compilation and linking pretty deep. I have been working on such
    >stuff in depth. That's why I sought this forum to see if there was any
    >problem other than with the OS itself. The command outputs show the
    >presence of the definitions in the relevant library, but they work
    >selectively... well, maybe I should talk to the OS vendor.
    >
    >Output on my system :
    >
    >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_name_uncompress
    >[146] | 137940| 84|FUNC |LOCL |0 |9
    >|__ns_name_uncompress
    >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_parserr
    >[1569] | 139684| 664|FUNC |GLOB |0 |9 |__ns_parserr
    >[timmyj@ibis:/usr/lib~]uname -a
    >SunOS ibis 5.8 Generic_117350-16 sun4u sparc SUNW,Ultra-4
    >
    >
    >Regards,
    >
    >Timmy Jose.
    >




  11. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Mark Andrews wrote:
    > In article <1139914688.627880.102120@g43g2000cwa.googlegroups. com>,
    > zoltan wrote:
    > >
    > >Mark Andrews wrote:
    > >> Talk to Sun.
    > >>
    > >> % nm libresolv.so | grep ns_name_uncompress
    > >> [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    > >> % nm libresolv.so | grep ns_parserr
    > >> [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > >> % uname -a
    > >> SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    > >> %
    > >>
    > >> I agree with Barry. You really do need to learn about what happens
    > >> when you are linking a program. Unless you know what is happening
    > >> you don't have a chance of diagnosing problems be it with your code or
    > >> with what is supplied to you.
    > >>
    > >> Mark

    > >
    > >Hi,
    > > Thanks for those commands. The command shows the same output on my
    > >system too.... I don't think the problem is with knowledge about
    > >linking.

    >
    > Actually it is. Linking isn't just about specifying libraries
    > on the command line. It's about knowing in what order and
    > when the loader will link a symbol (object) into the resulting
    > executable. You also need to know how shared and static
    > libraries behave differently especially which mixing
    > and matching them.
    >
    > While the two symbols are there they have different scopes.
    > __ns_name_uncompress is only visible to functions with the
    > library while __ns_parserr is visible to the application.
    >
    > In C you have static and global functions. When shared
    > libraries are built you can make some of those global
    > functions private to the library or, like when you build a
    > dll under Windows, all the globals become private unless
    > you specify them in the .def file. The aim is to reduce
    > namespace pollution and to hide global function which are
    > intended to be private to the library.
    >
    > > The makefile given shows that I am including the relevant
    > >libraries

    >
    > In the wrong order, though that isn't the current problem.
    > "-lresolv -lsocket -lnsl" is the correct link order.
    >
    > >and the source files as well. And I do understand the process
    > >of compilation and linking pretty deep. I have been working on such
    > >stuff in depth. That's why I sought this forum to see if there was any
    > >problem other than with the OS itself. The command outputs show the
    > >presence of the definitions in the relevant library, but they work
    > >selectively... well, maybe I should talk to the OS vendor.
    > >
    > >Output on my system :
    > >
    > >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_name_uncompress
    > >[146] | 137940| 84|FUNC |LOCL |0 |9
    > >|__ns_name_uncompress
    > >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_parserr
    > >[1569] | 139684| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > >[timmyj@ibis:/usr/lib~]uname -a
    > >SunOS ibis 5.8 Generic_117350-16 sun4u sparc SUNW,Ultra-4
    > >
    > >
    > >Regards,
    > >
    > >Timmy Jose.
    > >


    So what is the solution to this?
    Apart from writing the body explicitly?

    Regards,

    Timmy Jose.


  12. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Mark Andrews wrote:
    > Talk to Sun.
    >
    > % nm libresolv.so | grep ns_name_uncompress
    > [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    > % nm libresolv.so | grep ns_parserr
    > [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > % uname -a
    > SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    > %
    >
    > I agree with Barry. You really do need to learn about what happens
    > when you are linking a program. Unless you know what is happening
    > you don't have a chance of diagnosing problems be it with your code or
    > with what is supplied to you.
    >
    > Mark


    Ans as an aside, is there any way to use these local functions from the
    application? And to what uses can they be put to when they are local to
    the library itself?

    Regards,

    Timmy Jose.


  13. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    In article <1139987169.540274.274630@z14g2000cwz.googlegroups. com>,
    zoltan wrote:
    >
    >Mark Andrews wrote:
    >> In article <1139914688.627880.102120@g43g2000cwa.googlegroups. com>,
    >> zoltan wrote:
    >> >
    >> >Mark Andrews wrote:
    >> >> Talk to Sun.
    >> >>
    >> >> % nm libresolv.so | grep ns_name_uncompress
    >> >> [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    >> >> % nm libresolv.so | grep ns_parserr
    >> >> [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    >> >> % uname -a
    >> >> SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    >> >> %
    >> >>
    >> >> I agree with Barry. You really do need to learn about what happens
    >> >> when you are linking a program. Unless you know what is happening
    >> >> you don't have a chance of diagnosing problems be it with your code or
    >> >> with what is supplied to you.
    >> >>
    >> >> Mark
    >> >
    >> >Hi,
    >> > Thanks for those commands. The command shows the same output on my
    >> >system too.... I don't think the problem is with knowledge about
    >> >linking.

    >>
    >> Actually it is. Linking isn't just about specifying libraries
    >> on the command line. It's about knowing in what order and
    >> when the loader will link a symbol (object) into the resulting
    >> executable. You also need to know how shared and static
    >> libraries behave differently especially which mixing
    >> and matching them.
    >>
    >> While the two symbols are there they have different scopes.
    >> __ns_name_uncompress is only visible to functions with the
    >> library while __ns_parserr is visible to the application.
    >>
    >> In C you have static and global functions. When shared
    >> libraries are built you can make some of those global
    >> functions private to the library or, like when you build a
    >> dll under Windows, all the globals become private unless
    >> you specify them in the .def file. The aim is to reduce
    >> namespace pollution and to hide global function which are
    >> intended to be private to the library.
    >>
    >> > The makefile given shows that I am including the relevant
    >> >libraries

    >>
    >> In the wrong order, though that isn't the current problem.
    >> "-lresolv -lsocket -lnsl" is the correct link order.
    >>
    >> >and the source files as well. And I do understand the process
    >> >of compilation and linking pretty deep. I have been working on such
    >> >stuff in depth. That's why I sought this forum to see if there was any
    >> >problem other than with the OS itself. The command outputs show the
    >> >presence of the definitions in the relevant library, but they work
    >> >selectively... well, maybe I should talk to the OS vendor.
    >> >
    >> >Output on my system :
    >> >
    >> >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_name_uncompress
    >> >[146] | 137940| 84|FUNC |LOCL |0 |9
    >> >|__ns_name_uncompress
    >> >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_parserr
    >> >[1569] | 139684| 664|FUNC |GLOB |0 |9 |__ns_parserr
    >> >[timmyj@ibis:/usr/lib~]uname -a
    >> >SunOS ibis 5.8 Generic_117350-16 sun4u sparc SUNW,Ultra-4
    >> >
    >> >
    >> >Regards,
    >> >
    >> >Timmy Jose.
    >> >

    >
    >So what is the solution to this?
    >Apart from writing the body explicitly?
    >
    >Regards,
    >
    >Timmy Jose.


    Ask Sun for a RFE to make the other functions public. It
    looks like they have decided to keep the minimal api of
    libresolv using libbind source.

    Compile libbind yourself and link against it. It's part of
    BIND 8 / BIND 9.

    Mark

  14. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?

    In article <1139987509.480737.281280@g47g2000cwa.googlegroups. com>,
    "zoltan" wrote:

    > Mark Andrews wrote:
    > > Talk to Sun.
    > >
    > > % nm libresolv.so | grep ns_name_uncompress
    > > [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    > > % nm libresolv.so | grep ns_parserr
    > > [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > > % uname -a
    > > SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    > > %
    > >
    > > I agree with Barry. You really do need to learn about what happens
    > > when you are linking a program. Unless you know what is happening
    > > you don't have a chance of diagnosing problems be it with your code or
    > > with what is supplied to you.
    > >
    > > Mark

    >
    > Ans as an aside, is there any way to use these local functions from the
    > application? And to what uses can they be put to when they are local to
    > the library itself?


    They aren't intended to be used by others. They're internal,
    undocumented functions of the library, and could go away with the next
    release. That's why they're not exported.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  15. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Mark Andrews wrote:
    > In article <1139987169.540274.274630@z14g2000cwz.googlegroups. com>,
    > zoltan wrote:
    > >
    > >Mark Andrews wrote:
    > >> In article <1139914688.627880.102120@g43g2000cwa.googlegroups. com>,
    > >> zoltan wrote:
    > >> >
    > >> >Mark Andrews wrote:
    > >> >> Talk to Sun.
    > >> >>
    > >> >> % nm libresolv.so | grep ns_name_uncompress
    > >> >> [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    > >> >> % nm libresolv.so | grep ns_parserr
    > >> >> [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > >> >> % uname -a
    > >> >> SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    > >> >> %
    > >> >>
    > >> >> I agree with Barry. You really do need to learn about what happens
    > >> >> when you are linking a program. Unless you know what is happening
    > >> >> you don't have a chance of diagnosing problems be it with your code or
    > >> >> with what is supplied to you.
    > >> >>
    > >> >> Mark
    > >> >
    > >> >Hi,
    > >> > Thanks for those commands. The command shows the same output on my
    > >> >system too.... I don't think the problem is with knowledge about
    > >> >linking.
    > >>
    > >> Actually it is. Linking isn't just about specifying libraries
    > >> on the command line. It's about knowing in what order and
    > >> when the loader will link a symbol (object) into the resulting
    > >> executable. You also need to know how shared and static
    > >> libraries behave differently especially which mixing
    > >> and matching them.
    > >>
    > >> While the two symbols are there they have different scopes.
    > >> __ns_name_uncompress is only visible to functions with the
    > >> library while __ns_parserr is visible to the application.
    > >>
    > >> In C you have static and global functions. When shared
    > >> libraries are built you can make some of those global
    > >> functions private to the library or, like when you build a
    > >> dll under Windows, all the globals become private unless
    > >> you specify them in the .def file. The aim is to reduce
    > >> namespace pollution and to hide global function which are
    > >> intended to be private to the library.
    > >>
    > >> > The makefile given shows that I am including the relevant
    > >> >libraries
    > >>
    > >> In the wrong order, though that isn't the current problem.
    > >> "-lresolv -lsocket -lnsl" is the correct link order.
    > >>
    > >> >and the source files as well. And I do understand the process
    > >> >of compilation and linking pretty deep. I have been working on such
    > >> >stuff in depth. That's why I sought this forum to see if there was any
    > >> >problem other than with the OS itself. The command outputs show the
    > >> >presence of the definitions in the relevant library, but they work
    > >> >selectively... well, maybe I should talk to the OS vendor.
    > >> >
    > >> >Output on my system :
    > >> >
    > >> >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_name_uncompress
    > >> >[146] | 137940| 84|FUNC |LOCL |0 |9
    > >> >|__ns_name_uncompress
    > >> >[timmyj@ibis:/usr/lib~]nm libresolv.so|grep ns_parserr
    > >> >[1569] | 139684| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > >> >[timmyj@ibis:/usr/lib~]uname -a
    > >> >SunOS ibis 5.8 Generic_117350-16 sun4u sparc SUNW,Ultra-4
    > >> >
    > >> >
    > >> >Regards,
    > >> >
    > >> >Timmy Jose.
    > >> >

    > >
    > >So what is the solution to this?
    > >Apart from writing the body explicitly?
    > >
    > >Regards,
    > >
    > >Timmy Jose.

    >
    > Ask Sun for a RFE to make the other functions public. It
    > looks like they have decided to keep the minimal api of
    > libresolv using libbind source.
    >
    > Compile libbind yourself and link against it. It's part of
    > BIND 8 / BIND 9.
    >
    > Mark


    Thanks a lot for the pointer. I will try compiling libbind and then
    contact Sun in case it doesn't work out.

    Regards,

    Timmy Jose.


  16. Re: DNS NAMESERVER FUNCTIONS - USER-DEFINED or BUILT-IN?


    Barry Margolin wrote:
    > In article <1139987509.480737.281280@g47g2000cwa.googlegroups. com>,
    > "zoltan" wrote:
    >
    > > Mark Andrews wrote:
    > > > Talk to Sun.
    > > >
    > > > % nm libresolv.so | grep ns_name_uncompress
    > > > [155] | 157140| 84|FUNC |LOCL |0 |9 |__ns_name_uncompress
    > > > % nm libresolv.so | grep ns_parserr
    > > > [1735] | 160040| 664|FUNC |GLOB |0 |9 |__ns_parserr
    > > > % uname -a
    > > > SunOS sol.lab.isc.org 5.9 Generic_112233-11 sun4u sparc SUNW,Sun-Fire-V240
    > > > %
    > > >
    > > > I agree with Barry. You really do need to learn about what happens
    > > > when you are linking a program. Unless you know what is happening
    > > > you don't have a chance of diagnosing problems be it with your code or
    > > > with what is supplied to you.
    > > >
    > > > Mark

    > >
    > > Ans as an aside, is there any way to use these local functions from the
    > > application? And to what uses can they be put to when they are local to
    > > the library itself?

    >
    > They aren't intended to be used by others. They're internal,
    > undocumented functions of the library, and could go away with the next
    > release. That's why they're not exported.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***


    Thanks a lot for the comment.

    Regards,

    Timmy Jose.


+ Reply to Thread