I have explored much, and have much to offer to those other users who wish to port the Net-SNMP toolkit to some now not supported operating system. The key for my work has been being able to compile using the target tools, like a special gcc called i386-uclibc-gcc. Of course, all I care is that Net-SNMP compiles to produce a daemon and a subagent so that my client is happy, and can control their embedded device.
I also have some complaints (yes, Dave, I often have some complaints) but, I think that they also offer some valuable feedback, and will make the Net-SNMP toolkit more useful, particularly in the user friendly sense. First, it is not at all clear what specifications one should make with regard to the ./configure parameters. Also, the content of the --help output is not always intelligible. For instance, while --help suggests that --with-openssl should be followed by a PATH, review of other postings to the user-group list suggest that --with-openssl ought be followed with *yes* or *no*. Why the apparent inconsistency? Many other examples of difficulty are present with regard to these specifications. --target, --host, --build are difficult to fathom, even when one reviews the content of config.sub, and the tendency of the ./configure script to ignore a specified compiler is quite annoying. The ./configure process seems to work only when the compiler, the host, build, and target, and the endianness are all specified. Why not work with assumed values for unspecified parameters, and use specified parameters? This behavior is, I suspect, the cause of my earlier observations, such as those posted in the last week. I also noticed that using --with-cflags will result in the use of exactly that which is given in the parameter. This seems a bit of an annoyance, for if I do not use this parameter, the CFLAGS value in the Makefile is *-g -O2 -Dnone*, and is *<my specification> -Dnone* when I do use the parameter. Why should the *-g -O2* part be lost simply because I want to add more information to the CFLAGS? Why, indeed, should I have to first consult the content of the Makefile, so that I can knowledgeably add those portions to CFLAGS which are excised by use of the parameter --with-cflags? So, there is a problem with documentation of the Net-SNMP toolkit, which we have all known for some time. My comments here should help to fill in some of the gaps. I still do not have all of the process completed, and could use some more comment (actually, any comments would help, since to date no replies have been received for any postings I have placed regarding the issue of porting to the Kenati embedded Linux environment). I am also a bit annoyed by the repetitive use of -I. and -I./.. and -Iinclude within the command line for compiler invocation when using make on the Makefiles. This seems pointless - one copy of each parameter should be sufficient. So, I ask, why does ./configure generate repetitively? The command line I use for ./configure is: ./configure \ --with-cc=/opt/kenati/i386/bin/i386-uclibc-gcc \ --with-endianness=little --build=i386 \ --target=i386 --host=i386-pc-none \ --with-mib-modules="agentx" --cache-file=/usr/netsnmp59/net-snmp-5.0.9/configout.txt \ --with-openssl=no --with-default-snmp-version=2 \ --with-cflags=-I/usr/include and this generates close to the Makefile that I expect to obtain. I also noticed that the ./configure --help output lists the command usage as ./configure [options] [host] So, why include, therefore, a parameter of --host? Seems to me that the usage expects host to be specified in all cases, and the typical usage of --parameters is that they are optional. This is a bit of a contradiction, no? Also, why not allow me to give several paths as part of the --includedir, so that they are all checked during compilations? This would be more consistent with my (and, probably, most users) expectations for the purpose of this parameter. I suggest that this concept makes more sense than modification via the --with-cflags parameter. With suitable commentary from the core development team, and those users who are more familiar with the porting process than I, I will prepare a draft outline of for future users who seek to port the Net-SNMP toolkit. I probably have much more to say about this experience but, I am running out of time for the day. A great deal of thanks is offered to those who have come before me, and for their postings to the users group list. It is a very useful tool, and more newbie users ought to go their for information on using Net-SNMP. Still, there is nothing wrong with a good set of well developed documentation, and this is what I can offer to the core development team. William R. Buckley President SoftNerd, A California Corporation Director Emeritus, International Core Wars Society [EMAIL PROTECTED] 415-756-6699 ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
