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

Lx51 "Data Type Different" Warnings ?

Hello.

I have a project that links to a library I created using the C51 toolset.

If I build it using BL51, everything's cool. If I build it with Lx51, I get warnings like this:

*** WARNING L25: DATA TYPES DIFFERENT
    SYMBOL:  _FnName
    MODULE:  .\main.obj (MAIN)
though the application appears to work just fine in the simulator.

If I build the project with source files only (i.e. I compile the modules that are normally in the library, and I don't link to the library) then everything works under BL51 and Lx51.

So, what can I do to enable me to build projects using Lx51 and my libraries, and avoid these "Data Type Different" Warnings?

  • The first thing to do is, of course, to read the manual for the full description of that error:
    "The definition of the specified symbol in the specified module is not identical with the public definition of that symbol. The module which contains the public symbol can be determined with the IXREF listing."

    Maybe you've defined the symbol as an int, but you have an extern declaration with a different type?
    Or maybe you don't have the extern declaration at all, so 'C' has just assumed int?

  • Hi Andrew.

    Well, the fact that it works perfectly with BL51 and in a full source-code build certainly suggests that there are no declaration errors. Remember, all I did was change the linker from BL51 to Lx51. And BL51 has never complained ...

    Should Lx51 be able to link libraries built with C51?

  • Let me expand on "Should Lx51 be able to link libraries built with C51?"

    Should Lx51 be able to link libraries built with C51 with any memory model (small, large, compact) and any memory qualifier (data, idata, xdata)?

    My gut feeling is that there is something about the memory type qualifiers used when the library was generated that is somehow (slightly) incompatible with Lx51. But that's just a guess at this point.

  • Here's another idea.

    Do I need to enable OMF2 output with C51 when building libraries for applications that use Lx51?

    Or should Lx51 be happy with libraries built with C51 without OMF2 output enabled?

    Thanks,

  • "all I did was change the linker from BL51 to Lx51."

    It is actually quite common to find that a change of tool will show up subtle errors (or potential errors) which previously went unreported!

  • The BL51 linker did not compare the actual data types for symbols between modules (it is not possible to include this information in the OMF51 file).

    The LX51 linker uses the OMF2 object module format which does include type information. So, the LX51 linker compares these details.

    For example:

    main.c

    extern int asdf;
    
    void main (void)
    {
    asdf = 1;
    }


    asdf.c

    unsigned char asdf = 0;

    When you compile and link with BL51 you receive mo linker errors. When you compile and link with LX51, you receive the following:

    *** WARNING L25: DATA TYPES DIFFERENT
        SYMBOL:  asdf
        MODULE:  main.obj (MAIN)

    There are 2 items to point out here.

    1. When you use BL51 it is vitally important that you prototype and extern all functions and variables and that you include them even in the file where the functions and variables are declared. This way, the compiler will warn you of possible differing types.

    2. If you do not do #1 and you subsequently start to link using LX51, you will get warning L25 and/or warning L26 complaining about mismatched types.

    Hopefully this helps.

    Jon

  • Why does the error message list only one module?
    It would be a lot more helpful if it named both the defining & referring modules, and which type each was using.

    Surely it must have all this info to be able to detect the problem?

  • Why does the error message list only one module?
    It would be a lot more helpful if it named both the defining & referring modules, and which type each was using.


    The problem with that is that there may be a lot of places that the variable is used and listing each occurance would create a huge list.

    Maybe engineering can figure out a good way to display it anyway, so I'll fwd it to them.

    You may use the source browser to locate the declaration and the uses of the variable in question. That's probably the best way to fix the problem.

    Jon

  • Thanks for the info, Jon. I will investigate as to whether I've missed something in terms of external declarations, etc ...

    In the meantime, I've stumbled across a different problem -- perhaps you can lend some insight. I've modified our library-building makefiles to add the OMF2 directive at the very end of the command line that invokes C51. The idea being that we can offer libraries compatible with the C51+Lx51 build environment. So a typical build looks like:

    1) Compile each module using C51 v6.20c with OMF2 command line option (plus many others, of course), and
    2) Create a library with LIB51 v4.20.

    No errors are reported, and the object files / modules look fine, but _every_ library is only 1K in length -- obviously wrong. Any ideas?

  • OK, I think I solved this particular problem -- looks like LIBX51.EXE is required to build libraries for C51+OMF2 directive or CX51.

    This wasn't entirely clear from the manual, but in hindsight I guess it makes sense.

    P.S. There's a typo on page 17 of the Cx51 Manual -- 2nd-to-last line should read "... C51 compiler that is designed for the new Philips ..."

    Regards,

  • "The problem with that is that there may be a lot of places that the variable is used and listing"

    But the message only refers to one particular instance (one module?) - so the Linker should be able to give the details for the particular instance on which it's reporting?

    "each occurance would create a huge list."
    As I've noted many times, a single mistake often leads to a whole raft of messages, so that shouldn't be an undue worry.

    "Maybe engineering can figure out a good way to display it"
    As I've noted before, "big" compilers (eg, Borland, Microsoft) often give better diagnostics than the "small" cross-compilers.
    I'm sure that Borland does give you all the info in its equivalent message.

    "You may use the source browser"

    But if the Link fails, you can't use the Source Browser - because the browse info is only available from a successful build!

  • OK, I have solved the original problem.

    Certain compilers (which shall remain nameless, but are not Keil competitors because they serve a different target market) require that external array references include the size of the array in them (!), e.g.:

    extern OStypeEcb OSecbArea[5];
    instead of the more common (and more desireable, to be sure)
    extern OStypeEcb OSecbArea[];
    which is the way Keil C51 works.

    Anyway, this declaration was causing problems, because the libraries had been compiled for a particular size array (e.g. 5), yet the local module (in source code) that actually defined the array and therefore overrode what was in the library was set to a different size (e.g. 1) in order to minimize RAM requirements. Once the numbers matched, then all problems disappeared.

    So, the lesson is to always use the more general form of the external declaration
    extern type ArrayName[];
    and you'll avoid all of these problems.

    Regards,

  • Does this compiler do array bounds checking?
    I s'pose that might be a reason for it to want the size

  • If my compiler did array bounds checking, I would shoot it!

    I use negative array indexing all the time for useful kinds of stuff.

    Jon

  • Andrew asked "Does this compiler do array bounds checking?"

    Probably. Our arrays in question are arrays of struct, and all access is through pointers.

    Does the ANSI C standard say anything about this issue (how to declare extern arrays)?