Undefined reference AGAIN

[Dinosaur]

Hi All

Modified my Battery charger application by adding a simple Sub.
It is a single .bas file 650 lines long with includes noted at the top:

Code: Select all

#include once "includes/pigpio.bi"
#include once "includes/declares.bi"
#include once "includes/myTypes.bi"
#include once "file.bi"
#inclib "pigpio"

Declared the sub in declares.bi

Code: Select all

Declare sub ChargeCycle()

The sub is called from the main loop after 6 or more similar subs.

Code: Select all

            For Xq = 1 to 4
                A2D.Cell = Xq 
                ClearAccum                                  '' Nominate the Cell we are operating on
                ReadaCell                                   '' Read this Cell 250 times & Accumulate values.
                Times.mSec  = (Timer - Times.CalTime) * 1000 
                SampleSort
                Calc_Results                                '' Convert Counts to TrueV(n) and CellV(n)
                Limits_Check                                '' Classify each Cell according to it's values
            Next
            Battery_State                                   '' Classify Total Battery charge state .
            IOControl
            ChargeCycle                                     '' Allow Limited charge Time after 99 %
            WriteFlags                                      '' Use all of the above to Switch O/P's

Compiled on my Debian Desktop and all good.

Copy the basic files to my Rpi which uses St_W fbc version 1:20:0.
Compile from Geany or on cli results in:

ld: LiPo4.o: in function 'Taskscan'
LiPo4.c (.text+0x780):undefined reference to 'ChargeCycle'

Comment the line out and it all compiles and links.

Noted many posts on 'undefined reference' but they mainly have to do with Constructor / Destructor.
Have never used either in the last 20 years of using FB.
Tried shifting the routine before the error line to no avail.

Anyone have any idea why this is happening ?

Regards

EDIT: Compared .c files from Desktop to Rpi and the only differences are to do with 64 or 32 bit.

[shadow008]

Are you expecting that sub to be defined in a library?
If so, which library and are you certain it's the same between Debian desktop and your raspi os?
If not, you need to define the function ChargeCycle. All you said you've done is declare it in your defines (which means something else in programming by the way. declare <> define).

Either the library you're using is not actually the same between os's or you haven't implemented the function.

[Dinosaur]

Hi All

Are you expecting that sub to be defined in a library?

No, it is just a sub and not even a Function.
All that should be required is to Declare the Sub and then call the sub, which is what I am doing.

Just to prove that I made another sub and called it Test1 and declared it.
Then commented out my ChargeCycle call and it compiled and linked correctly.
So thinking there is a name clash , I changed the name of the culprit sub, BUT the same error.

If I copy the contents of the culprit sub to the new Test1 sub it all compiles correctly. ???

Then I changed the Test1 sub name to ChargeCycle and it compiled correctly ?????

Does that mean that the previous name had control characters hidden in the name ?
BIG fingers touching two keys, maybe.
I guarantee that I spelled it correctly each time as that is usually the first thing I check.

So in hindsight, deleting the name and re-writing it would have solved it.

Regards

[caseih]

Can't really tell much from the code you posted. Where is ChargeCycle defined? Is it in the same file?

[shadow008]

Hi All

Are you expecting that sub to be defined in a library?

No, it is just a sub and not even a Function.
All that should be required is to Declare the Sub and then call the sub, which is what I am doing.

That's incorrect. Declaring a sub is not enough, it must also be defined somewhere. Whether that's in a library or in your source code, a simple "declare sub" is insufficient. And if you're only using one source file, you don't even need to declare it, defining is enough.

To clarify:

Declaring a sub:

Code: Select all

declare sub ChargeCycle()

At this point the compiler knows the name of the sub.

Defining a sub:

Code: Select all

sub ChargeCycle()
    ...code
end sub

At this point the compiler and linker have a function entry that it can call/inline/remove/whatever to match up with a declaration. What you got was a linker error saying you have the declaration, but not the definition. If this sub is not in a library like you said, you need to write the code for the sub.

I am aware that define and declare mean very similar things in English, synonyms in some cases, but not in programming.

Hope this helps.

[Dinosaur]

Hi All

OK, so I did not relate writing a sub with the term "Defining a sub"
In other words writing the subroutine should be called Defining the sub.

But if my reckoning is correct, then you are right, the sub was not defined, because the name at the Define point was corrupted.

Regards

[shadow008]

OK, so I did not relate writing a sub with the term "Defining a sub"
In other words writing the subroutine should be called Defining the sub.

Yep, "writing a sub" and "defining a sub" basically mean the same thing.

Also, despite being well established terms in programming, there's a particular ambiguity that annoys me (and it goes way back in the C preprocessor)

Code: Select all

#define thing
#if defined(thing)
#endif

If the terminology was consistent, that would be #if declared(...), as it's checking if a token was declared, not if it's defined...

But if my reckoning is correct, then you are right, the sub was not defined, because the name at the Define point was corrupted.

Not corrupted, it just didn't exist. Like a null dereference. The linker looked up in it's symbol map and didn't find the name.

[caseih]

I should have used better, clearer language. I should have asked, "where was the sub actually implemented?"

If I read @Dinosaur's posts correctly, he did have the implementation for the sub in the same file, but the linker was still not able to find it. Correct? When he cut and pasted the sub implementation to a new part of the file, and retyped the "sub ChargeCycle()" bit, everything was good. I cannot explain why the original implementation was not found by the linker. And without seeing his code, I do not know why.