[Nut-upsdev] building a library for common/ [was: minor building

[Peter Selinger]

I think this should be relatively easy to do with autoconf. To quote
from "info autoconf":

Generic Function Checks
-----------------------

   These macros are used to find functions not covered by the
"particular" test macros.  If the functions might be in libraries
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
other than the default C library, first call `AC_CHECK_LIB' for those
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
libraries.  If you need to check the behavior of a function as well as
^^^^^^^^^^
find out whether it is present, you have to write your own test for it
(*note Writing Tests::).

 - Macro: AC_CHECK_FUNC (FUNCTION, [ACTION-IF-FOUND],
          [ACTION-IF-NOT-FOUND])
     If C function FUNCTION is available, run shell commands
     ACTION-IF-FOUND, otherwise ACTION-IF-NOT-FOUND.  If you just want
     to define a symbol if the function is available, consider using
     `AC_CHECK_FUNCS' instead.  This macro checks for functions with C
     linkage even when `AC_LANG(C++)' has been called, since C is more
     standardized than C++.  (*note Language Choice::, for more
     information about selecting the language for checks.)

Shouldn't this suffice to write the correct test? Currently, there is
no AC_CHECK_LIB for net-snmp in our configure.in. -- Peter


Charles Lepple wrote:
> 
> On 5/20/06, Arjen de Korte <nut+devel at de-korte.org> wrote:
> > Charles Lepple wrote:
> [...]
> > > Does anyone have any objections to sticking all of the files in
> > > common/ into a static library, and then just linking that after any
> > > external libraries like net-snmp?
> >
> > The only objection I see, is that the same thing might happen to other
> > functions that have the same name, but different functionality might
> > suffer same treatment. Not that I know of an example at the moment, but
> > this is certainly something we should consider since it will be very
> > hard to debug cases where this causes problems. The 'beauty' of the
> > solution we have now is that in case of conflicts, an error pops up.
> > This won't be the case if we make common/ into a library.
> 
> Hmm, I hadn't thought of that.
> 
> However, we could reduce the scope of the library to just include the
> functions that are not NUT-specific. (Bear in mind that most modern C
> libraries have setenv and snprintf.)
> 
> That way, if the external library compiles without errors on more
> recent versions of Solaris, Linux and *BSD, we can be fairly certain
> that the functions with overlapping names are just compatibility
> shims.
> 
> > > Basically, this avoids having another hairy autoconf test, since the
> > > linker will not search the NUT common library (which would contain
> > > setenv() on systems that require it) unless setenv was not found
> > > earlier in the list of libraries.
> 
> Maybe I am just overlooking a simple autoconf test here. Basically, we
> want to see if the setenv function exists, and right now, the test
> doesn't seem to consider whether it might be included in net-snmp.
> 
> Should we fold the net-snmp CFLAGS/LDFLAGS into the main flag
> variables? Then, the setenv test will notice that net-snmp is
> providing setenv (on platforms where the C library doesn't already).
> 
> --=20
> - Charles Lepple
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>