I have some code that is doing address arithmetic on a (far) pointer in a structure. When I try and link I get the following error(s):
*** ERROR L127: UNRESOLVED EXTERNAL SYMBOL SYMBOL: ?C?IILDOPTR MODULE: .\obj\pixel.obj (PIXEL) *** ERROR L128: REFERENCE MADE TO UNRESOLVED EXTERNAL SYMBOL: ?C?IILDOPTR MODULE: .\obj\pixel.obj (PIXEL)
?C?IILDOPTR can be found in
(the C51_SMALL_LIBRARY C51S.LIB) (the C51_COMPACT_LIBRARY C51C.LIB) (the C51_LARGE_LIBRARY C51L.LIB)
LIB51 LIST libray-file TO text-file PUBLICS
> Did you correctly set up the search path C51LIB ? I'm running it from the IDE, anything special I need to do? Aren't the libraries you mentioned "standard" and included in all builds with the IDE? While I didn't compile this in the old 16-bit mode, I didn't see the problem until I moved to the contiguous dallas mode, which uses the extended linker.
The developer specifies what library or libraries should be linked with the software. There are several choices of library (floating point, no floating point, etc.) that can be used and since the use of some features impacts code size and such, it was probably felt that this was better than just throwing in a global library which covers everything.
According to page 210 of the C51 User's Guide:
The Philips 80C51MX, Dallas 390 contiguous mode and variable code banking requires a different set of Cx51 run-time libraries. The Lx51 linker/locator automatically adds the correct library set to your project.
Here is the simple source code that fails when compiled with the extended linker for the ds80c390:
typedef struct { unsigned char far * addr; // unsigned char offset; } PixelAddressStruct; #define HIRES_PIX_ADDR PixelAddressStruct void myFunc(HIRES_PIX_ADDR *addr) { addr->addr++; } void main(void) { HIRES_PIX_ADDR addr; addr.addr = 0x00; // addr.offset = 0; myFunc(&addr); }
I don't use C51 but can't you produce an assembly listing from it. Then look at the assembly code to see where this function is used. Also look at the working model and see if this function is needed there. The function is probably some form of pointer utility. Then you can either try to change the code to avoid it's use or reproduce it in assembly language. Best luck
This is a bug with the compiler and will be fixed in a future release. The easiest workaround is to just save the address to a temp variable, manipulate it, and then set the value back. Not optimum code, but it works.