I am trying to port Net-SNMP into the Kenati Linux environment. Kenati is an embedded environment, and so the toolset is being used within a host RH9 Linux distribution. As part of my effort, I am following the process outlined for ./configure, a process that is reported by Bob Ray (in his Aug 14, 2003 posting) to perform well. For my experience, the process is not working at all. The command line given to the ./configure tool is:
./configure --with-cc=/opt/kenati/i386/bin/i386-uclibc-gcc --includedir=/usr/include --includedir=/usr --with-mib-modules="agentx" This yields Makefiles which make reference to the gcc compiler, with lines as CC =gcc Now, upon renaming the gcc compiler to gccgcc, and then running the above ./configure command, the output includes these lines: loading cache ./config.cache using default enterprise.net-snmp using default enterprise sysOID NET-SNMP-MIB::netSnmpAgentOIDs... using default notifications NET-SNMP-MIB::netSnmpNotifications checking if I need to feed myself to ksh... no checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. So, gcc is not found, as one might expect but, that is not really the point, is it?! In fact, I want the i386-uclibc-gcc compiler to be used, not the gcc compiler. As I understand the documentation, the above ./configure command line is as it ought be in order for the compiler selection to be changed. Now, I probably can alter the name of the i386-uclibc-gcc compiler to now be gcc, especially since I have already renamed gcc to be gccgcc but, again, this is not really the point, is it?! So, my questions: 1. What is going wrong here? (This is the most general question I could express, and its answer will likely yield a solution to my problem but, my other questions ought be answered as well, since they provide better quality criticism to the whole process.) 2. What is the point of providing the ./configure tool if it does not yield altered Makefiles? (Remember, the CC=gcc line ought to read CC=i386-uclibc-gcc after execution of the ./configure command line given above.) 3. More detail on the problem comes with knowledge that upon running the ./configure command line, the INSTALL instructions direct that make is then to be executed. Thereafter, umask 022, and make install are to be executed. If it turns out that the correction to my noticed problem is that I should follow all four operations (./configure, make, umask 022, make install), in order for the Makefiles to then list the proper compiler in the CC lines, what is the first make operation for? After all, the sequence would lead to compilation of all source files of the agent twice, once with gcc, and once with i386-uclibc-gcc. 4. Is not ./configure the preferred mechanism for altering the Makefiles, as opposed to changing the name of tool executables (like gcc), and as opposed to direct alteration of the Makefiles? Finally, and before anybody complains that I have not mentioned this, I am running as root. The problem has therefore nothing to do with a lack of privilege. Indeed, and while this is bound to make some system admins cringe, I always run as root. I am smart enough to avoid doing stupid things with my computers, always keep proper backups, etc., such that reliance upon a user account for protection from myself is not needed. 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