[Nut-upsdev] building a library for common/ [was: minor building issues (svn HEAD revision 427)]

[Charles Lepple]

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).

-- 
- Charles Lepple