Re: [avr-chat] order of modules to linker

[georg chambert]

Hello Erik, thanks for suggestions,

however, now I have discovered that there still is som problem;
I had thought that the linker would complain if it couldnt do its jobb, but 
evidently that is not the case

The obvious error in the .lst file for vector is gone, but when running, 
some functionality is lost.
What I have done is that I have merged a functionality into my main code, 
where each
of the two codes in their respective test-beds have worked fine.
One of the this were picking up stored information from internal EEPROM, 
which  was
working in the main code, But where the "vector confusion" in the first 
linkage, with library last,
gave strange references to the eeprom handling routines, on the vecor 
position, was present.
And which went away seemingly ok, when moving lib up, but evidently still 
not ok, since now
in the combined code the fetch from internal EEPROM fails.

The constructs of suspition is my use of "extern" directive, which I use in 
main file (not in void main module though)
to get the linker to pick up the two ISRs I use (one for uart RX, which 
works in the load module, and one for
timer/counter1, which I  think work, but cannot be sure actually, at least 
it doesnt crash) This counter and the ISR are
essential in the new feature added.

----- Original Message ----- 
From: "Erik Christiansen" <address@hidden>
To: <address@hidden>
Sent: Sunday, January 07, 2018 2:52 AM
Subject: Re: [avr-chat] order of modules to linker


> On 06.01.18 15:21, georg chambert wrote:
> > Now I got some back-of-the-head hunch, so I re-arranged so that the .a
> > was first in the link-list, and sure enough the vector_11 was now a
> > fine address to the ISR, and the load-module work (what I can see so
> > far)
> >
> > WHAT WAS THAT, is my question (I usuallly want to understand whats
> > happening, otherwise things tend to come back in some other shape and
> > bite u)
>
> Too true. But your example runs contrary to my experience, which is that
> it is necessary to place a library (.a) _after_ all the object files
> which need it, because the linker reads each file only once. Thus a .o
> file on the command line after a needed .a will fail to have its
> externals satisfied by the library which has already whizzed past, and
> is gone.
>
> Crux: Only the parts of a library which are required for unsatisfied
> externals are pulled in by the linker. So place the libraries last, with
> libraries needing other libraries preceding those which don't.
>
> If there are reciprocal or cyclical dependencies, then list them thus:
> "-( archives -)", and ld will search them repeatedly until no new
> undefined references  are created.
>
> Erik
>
> _______________________________________________
> AVR-chat mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/avr-chat