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

[Arjen de Korte]

Charles Lepple wrote:

> NUT developers,
> 
> I'm looking for a low-tech solution for this linker error:
> 
>> gcc -I../include -O -Wall -Wsign-compare -g -Dsolaris2
>> -I/software/openssl-0.9.7_runtime/include -I.
>> -I/software/netsnmp-5.3/include -o snmp-ups snmp-ups.o main.o dstate.o \
>>         ../common/state.o ../common/upsconf.o ../common/parseconf.o \
>>         ../common/common.o ../common/setenv.o ../common/inet_aton.o
>> -lnsl -lsocket    -L/software/openssl-0.9.7_runtime/lib
>> -R/software/openssl-0.9.7_runtime/lib:/software/libz-1.1.4_runtime/lib
>> -L/software/netsnmp-5.3/lib -lnetsnmp -lgen -lcrypto -lkstat -lelf -lm
>> -lnsl -lsocket -ladm
>> ld: fatal: symbol `setenv' is multiply-defined:
>>         (file ../common/setenv.o type=FUNC; file
>> /software/netsnmp-5.3/lib/libnetsnmp.a(system.o) type=FUNC);
>> ld: fatal: File processing errors. No output written to snmp-ups
> 
> 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.

> 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.
> 
> This library would be internal to NUT, and would not be installed the
> way that libupsclient.a is.
> 
> Thoughts?
>