This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

?C?IILDOPTR UNRESOLVED EXTERNAL

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)

This would appear to be a compiler library routine. (I.E. not in my code). If I remove the address arithmetic line, things link fine. The code compiles, links, and works fine on 4 other platforms.

Do I need to add a different library to link against? I'm using a new project for the DS80C390 in 22bit contiguous mode in v6.22.

I'll extract a code example if needed, but I was hoping someone would recognize the link error...

  • ?C?IILDOPTR can be found in

    (the C51_SMALL_LIBRARY C51S.LIB)
    (the C51_COMPACT_LIBRARY C51C.LIB)
    (the C51_LARGE_LIBRARY C51L.LIB)
    

    Did you correctly set up the search path C51LIB ?

    (Maybe my Libraries are out of date.
    So try this at the DOS-Prompt:
    LIB51  LIST libray-file TO text-file PUBLICS
    where libray-file is the library to investigate
    and text-file is the file to receive info about the lib.
    So you can verify/falsify what I've said above.)

    Norbert


  • > 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.
    

    While the link no longer failed if I added C51L.lib to my project, the program started doing very bizarre things, even in the emulator.

  • 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);
    }
    
    

    This compiles and links fine in the "large" memory model, but fails in the contiguous modes with the unresolved externals.

  • 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.