Notice: This posting has been resent, owing to the apparent failure of its earlier posting to be serviced by the SourceForge email system. Thanks for your patience.
William R. Buckley > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, August 16, 2004 8:10 PM > To: NetSNMPUsers > Subject: Porting Net-SNMP to embedded Linux environment. > > > 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