[En-Nut-Discussion] Circular references in libraries
Henrik Maier
hmlists at focus-sw.com
Tue Oct 11 00:40:15 CEST 2005
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.
More information about the En-Nut-Discussion
mailing list