[En-Nut-Discussion] Circular references in libraries

[Henrik Maier]

Bernard Fouché wrote:
> Henrik Maier wrote:
> 
>> The current approach of separating Nut/OS into separate libraries 
>> leads to unavoidable circular references between the different libraries.
>>
>> Often several libraries have to be listed twice or more in order to 
>> resolve the circular references. I find it always a kind of a gamble 
>> to find the best order to list libraries.
>>
>> To avoid this wouldn't it be better to create a monolithic library for 
>> Nut/OS, e.g. libnutall.a ?

I am using avr-gcc 3.4.3. ld is not very capable in resolving circular 
references (unless you use the --start-group /--end-group feature).

> ... So the order is important only when you 
> have two or more definitions for the same function in different 
> librairies: the linker will use the first it encounters....

This is actually not quite correct. The order matters once you have 
interdependencies. Assume the order -lfirst -lsecond. If libfirst 
references a symbol in libsecond, the linker will fail with undefined 
reference because he has not seen the symbols in libsecond when 
processing libfirst. Now change the order to -lsecond -lfirst. Bad luck 
again as libsecond is referencing a symbol in libfirst. So you end up 
with a list like: -lfirst -lsecond -lfirst.

Let's look at the library order in the app directory's makefiles. Most 
samples list at least one library twice because of the circular 
references. In addition almost every Makefile uses a different order 
which works well for this app but once you modify the code, a different 
order might be necessary. You need to apply try and error methodology to 
find a suitable order. Not very nice for my opinion and hard to explain 
to a novice user.

Hence the suggestion to create one library for Nut/OS with everything 
(e.g. libnutall).

Henrik

 From ld's man pages:
"Normally, an archive is searched only once in the order that it is 
specified on the command line. If a symbol in that archive is needed to 
resolve an undefined symbol referred to by an object in an archive that 
appears later on the command line, the linker would not be able to 
resolve that reference.