On Fri, Feb 12, 2010 at 5:35 PM, Tim Rice <[email protected]> wrote: > Attached as cofig.log.gz and compile.log.gz
I saw a few warnings: > "/opt/src/utils/nut-2.4.1-r2339/drivers/apcsmart.c", line 34: warning: too > many struct/union initializers > "/opt/src/utils/nut-2.4.1-r2339/drivers/apcsmart.c", line 44: warning: too > many struct/union initializers > "/opt/src/utils/nut-2.4.1-r2339/drivers/bcmxcp.c", line 135: warning: too > many struct/union initializers > "/opt/src/utils/nut-2.4.1-r2339/drivers/bcmxcp_ser.c", line 17: warning: too > many struct/union initializers > "/opt/src/utils/nut-2.4.1-r2339/drivers/belkin.c", line 39: warning: too many > struct/union initializers [...] Hopefully the preceding lines compiled properly - we use those structures all over the place. > "/opt/src/utils/nut-2.4.1-r2339/drivers/apcsmart.c", line 127: warning: > statement not reached Is there a way to flag a statement as "not reached" with the Sun C compiler? We have a comment to that effect in the code there. > Some Solaris 10 build notes: > The Solaris 10 (U8) SUNWsmcmd package is broken so > /usr/sfw/bin/net-snmp-config is symlinked to net-snmp-config-64 > instead of net-snmp-config-32. So configure will find the SNMP bits > but the build will fail. I am not familiar with Solaris' 32/64 bit support. Is there some other place in the code that we are specifying 32-bit code? Should we check some system variable and look for net-snmp-config-32 before net-snmp-config? > If the symlink gets fixed there is still > the issue of net-snmp-config spitting out "-R../lib" that the linker > doesn't like. This post configure perl script does the trick. > perl -pi -e "s|-R../lib |-R/usr/sfw/lib |g;" \ > `find . -name Makefile -print` I suspect that we would want to handle this earlier in the configuration process, probably around when those options are retrieved. Is there a chance that someone would see "-R../lib" with the absolute path ending up as something other than /usr/sfw/lib? (I am trying to find out how reasonable it would be to hardcode that fix.) -- - Charles Lepple _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
