#2329 configure generates buggy makefiles on Solaris 9

solaris
open
nobody
agent (1105)
5
2014-08-18
2012-01-19
No

When building 5.7.1 from source on Solaris 9,

1) The configure script generates Makefiles with missing line carryover "\", which results in "make" stops.
2) The configure script doesn't generate any valid MAN3 entries, which results in "make install" stop on a "for" loop running through "$MAN3"

Steps to reproduce on Sol 9:

As unprivileged user:
./configure --prefix=/some/custom/location

....
config.status: executing libtool commands
config.status: executing default commands

---------------------------------------------------------
Net-SNMP configuration summary:
---------------------------------------------------------

SNMP Versions Supported: 1 2c 3
Building for: solaris2
Net-SNMP Version: 5.7.1
Network transport support: Callback Unix Alias TCP UDP IPv4Base SocketBase TCPBase UDPIPv4Base UDPBase
SNMPv3 Security Modules: usm
Agent MIB code: default_modules => snmpv3mibs mibII ucd_snmp notification notification-log-mib target agent_mibs agentx disman/event disman/schedule utilities host
MYSQL Trap Logging: unavailable
Embedded Perl support: disabled
SNMP Perl modules: disabled
SNMP Python modules: disabled
Crypto support from: crypto
Authentication support: MD5 SHA1
Encryption support: DES
Local DNSSEC validation: disabled

---------------------------------------------------------

make
....
make[1]: Entering directory `/home/igubenko/net-snmp-5.7.1/agent'
Makefile:372: *** recipe commences before first target. Stop.
make[1]: Leaving directory `/home/igubenko/net-snmp-5.7.1/agent'
make: *** [subdirs] Error 1

sed '371,372!d' agent/Makefile
mibgroup/host/data_access/swrun_procfs_psinfo.lo
mibgroup/hardware/cpu/cpu.lo \

# Fix - add "\"

Subsequent make errors for that same Makefile all occur for "swrun_procfs_psinfo.o"

Also,

make[1]: Entering directory `/home/igubenko/net-snmp-5.7.1/agent'
Makefile:1046: *** recipe commences before first target. Stop.

sed '1045,1046!d' agent/Makefile
mibgroup/agentx/agentx_config.lo
mibgroup/agentx/protocol.lo \

make[1]: Entering directory `/home/igubenko/net-snmp-5.7.1/agent'
Makefile:1063: *** recipe commences before first target. Stop.

sed '1062,1063!d' agent/Makefile
mibgroup/agentx/agentx_config.ft
mibgroup/agentx/protocol.ft \

make[1]: Entering directory `/home/igubenko/net-snmp-5.7.1/agent'
Makefile:1080: *** recipe commences before first target. Stop.

sed '1079,1080!d' agent/Makefile
mibgroup/agentx/agentx_config.o
mibgroup/agentx/protocol.o \

make[2]: Entering directory `/home/igubenko/net-snmp-5.7.1/agent/mibgroup'
Makefile:267: *** recipe commences before first target. Stop.

sed '266,267!d' agent/mibgroup/Makefile
host/data_access/swrun_procfs_psinfo.o
hardware/cpu/cpu.o \

Subsequent make errors for that same Makefile all occur for swrun_procfs_psinfo.{o,c,ft}

-------
make install
.....

install: installed net-snmp-create-v3-user.1 in /u/igubenko/net-snmp/share/man/man1
/bin/bash: -c: line 1: syntax error near unexpected token `;'
/bin/bash: -c: line 1: `for i in ; do /bin/bash ../libtool --mode=install .././install-sh -c -m 644 ./$i /u/igubenko/net-snmp/share/man/man3 ; echo "install: installed $i in /u/igubenko/net-snmp/share/man/man3" ; done'
make[1]: *** [maninstall] Error 2
make[1]: Leaving directory `/home/igubenko/net-snmp-5.7.1/man'
make: *** [installsubdirs] Error 1

sed '/MAN3[^A-Za-z0-9_]\{1,\}/!d' man/Makefile
MAN3 =
MANALL = $(MAN1) $(MAN1G) $(MAN3) $(MAN3G) $(MAN5G) $(MAN8G) $(MANALIASES)
maninstall: maninstalldirs $(MAN1) $(MAN1G) $(MAN3) $(MAN5G) $(MAN8) $(MANALIASES)
@for i in $(MAN3) ; do $(INSTALL_DATA) $(srcdir)/$$i $(INSTALL_PREFIX)$(man3dir) ; echo "install: installed $$i in $(INSTALL_PREFIX)$(man3dir)" ; done
@for i in $(MAN3G) $(MAN3) $(MANALIASES); do rm -f $(INSTALL_PREFIX)$(man3dir)/$$i ; echo "removed $$i from $(INSTALL_PREFIX)$(man3dir)" ; done

Since MAN3 is not assigned anything, the "@for i in $(MAN3) ; do" fails.

Discussion

  • Dave Shield

    Dave Shield - 2012-03-28

    The issue with MAN3 has been addressed in the current development code (5.6.x and above) and this fix will be included in future releases.

    Can you specify the details about exactly which line(s) in the Makefile are broken wrt missing backslashes. Thanks

     
  • Carsten Grzemba

    Carsten Grzemba - 2012-04-24

    The backslashes are already missing in the files in the mk directory.
    This is probably cause by the Solaris9 environment like shell and/or sed

     
  • Yann Rouillard

    Yann Rouillard - 2012-07-21

    I am able to reproduce this problem (missing backslash) under the same environment (Solaris 9).

    The problem is that modules are duplicated in the the file "mk/mib_module_list_code.mk" during the configure phase.
    So we have:
    # contents below built automatically by configure; do not edit by hand
    mib_module_list_code= \ ucd-snmp/lmSensors \ ucd-snmp/diskio \ mibII/mta_sendmail \ util_funcs/header_simple_table \ snmpv3/snmpMPDStats_5_5 \ [...]
    snmp-notification-mib/snmpNotifyFilterTable/snmpNotifyFilterTable_interface \ snmp-notification-mib/snmpNotifyFilterTable/snmpNotifyFilterTable_data_access \ host/data_access/swrun \ host/data_access/swrun_procfs_psinfo \ [...]
    snmp-notification-mib/snmpNotifyFilterTable/snmpNotifyFilterTable_interface \ snmp-notification-mib/snmpNotifyFilterTable/snmpNotifyFilterTable_data_access \ host/data_access/swrun \ host/data_access/swrun_procfs_psinfo \

    Later in configure, the following code tries to remove the final antislash:

    20713 for i in module_list_o module_list_c module_list_lo module_list_ft mib_module_list_o mib_module_list_c mib_module_list_lo mib_module_list_ft mibgroup_list_o mibgroup_list_lo mibgroup_list _ft agent_module_list_o agent_module_list_c agent_module_list_lo agent_module_list_ft agentgroup_list_o agentgroup_list_lo agentgroup_list_ft ; do
    20714 # hpux make (at least) doesn't like a trailing \ on the last
    20715 # line even when the next line contains nothing but
    20716 # whitespace.
    20717 lasttoken=`awk '{lasttoken=$1}END{print lasttoken}' mk/$i.mk`
    20718 $SED "s#$lasttoken \\\\#$lasttoken#" < mk/$i.mk > mk/$i.mk.tmp
    20719 mv mk/$i.mk.tmp mk/$i.mk
    20720
    20721 # add a closing comment
    20722 echo "" >> mk/$i.mk
    20723 echo "# end configure generated code" >> mk/$i.mk
    20724 done

    The problem is that it finds host/data_access/swrun_procfs_psinfo as the last line and then it removes the final antislash for this last line... but also for the previous duplicated line.
    So we end up with antislash missing in the middle of the file.

    What I don't understand yet is the reason why the module lines are duplicated, I suppose it shouldn't happen but it's difficult to follow the configure code and to understand where is the exact test that should prevent modules to be added twice.

     
  • Yann Rouillard

    Yann Rouillard - 2012-07-21

    Ok, I found the source of the problem.

    During the configure, the script tries to find a good grep binary:
    "checking for grep that handles long lines and -e..."

    Infortunately, the configure test is not that great because it doesn't really test if it supports long lines but only the "-e" option.
    Under Solaris it selects "/usr/xpg4/bin/grep".

    The problem is /usr/xpg4/bin/grep in limited in line length.
    According to the man page:
    "The results are unspecified if input files contain lines
    longer than LINE_MAX bytes or contain binary data. LINE_MAX
    is defined in /usr/include/limits.h."

    This limits is 2048 under Solaris 9 (and Solaris 10 also it seems).

    Now to test if a module has already been included the configure script do a test like this:
    "elif echo " $module_list " | $GREP " $i " > /dev/null; then"

    The problem is that line lenght gets longer that 2048 bytes at sometime, then /usr/xpg4/bin/grep doesn't work anymore, then modules are included twice, then we have the Makefile bug...

    I will try a simple fix:
    GREP="ggrep" configure --prefix=...

    but I suppose the real fix would be to fix the grep check in configure.

     
  • Thomas Anders

    Thomas Anders - 2012-07-21

    We use standard autoconf AC_PROG_GREP and AC_PROG_EGREP checks to find the best grep, so it should perhaps be fixed there. Or is exceeding LINE_MAX considered a use case that's too special?

     
  • Yann Rouillard

    Yann Rouillard - 2012-07-22

    Hmm, according to the manual, you should not count on $GREP being able to support long line in fact: http://www.gnu.org/software/autoconf/manual/autoconf.html#grep

    It says that on AIX at least the default grep silently truncates long lines.

    I opened a but on this subject on the autoconf bugtracker: https://savannah.gnu.org/support/index.php?108092

    but maybe it would be best to add an explicit check on long lines support for grep in the netsnmp configure.ac file.

    BTW, using gnu grep fixed the problem under Solaris 9.
    On Solaris 10, even if the man page still says the same thing about xpg4/bin/grep support for lines longer than 2048 bytes, in fact it works and this bug doesn't show up in Solaris 10.

    Yann

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks