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

Reply via email to