Am 28.01.2016 um 09:52 schrieb Le_Forgeron:

> Such error at link stage are usually due to:
>  * a failure to compile some code
>  * an ordering problem with multiple libraries on the linker command
> 
> Did you start with a clean environment ? Previously compiled files might
> not have been recompiled and might miss a deep change of mapping.

The error was first brought to my attention by Semaphore, one of the
automated build services I've set up for our GitHub repo. They do start
with as clean an environment as you can possibly imagine.

> About the ordering of libraries, when libA would need some part of libB,
> libA must appears before libB. But if libB needs also some code of libA,
> you got a problem of circular dependencies which can make it difficult
> to solve: the linker will extract only the needed symbol from libA due
> to the previous code (main or other *.o object) and get a list of needed
> symbols. then it close forever libA and search libB to extract the still
> needed symbols and might get more needed symbols too. rinse & repeat for
> the next library until the end of the list.

Are you sure that's what's happening? Because last time I checked, there
is no problem linking two libraries into one executable even if they
recursively call each other. And I don't think it can't get any more
interlocked than that.


No, it was an entirely different matter: The Unix syspovconfig.h failed
to explicitly pull in <stdint.h>, and typically ended up with the
(false) conclusion that uint32_t wasn't available, resulting in
POV_UINT32, and by extension POVMS_Type, to be defined as unsigned long
(chosen as the default because that's the smallest type guaranteed by
the C++ standard to hold a 32-bit unsigned integer). In other cases
however, <stdint.h> would happen to be included before syspovconfig.h,
which then ended up with the (proper) conclusion that uint32_t was well
available, resulting in POV_UINT32, and by extension POVMS_Type, to be
defined as that type.

Obviously this brought into existence two different sets of declarations
for virtually the entire POVMS module, but only one set of definitions.

The problem hadn't surfaced earlier because POVMS_Type explicitly
defaulted to unsigned int until now.

Post a reply to this message