• State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 22 subscribers
  • Views 7825 views
  • Users 0 members are here
Options
Related
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 ?

Andrew E. Kalman

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?

Parents
  • 0 in reply to Jon Ward

    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?

Reply
  • 0 in reply to Jon Ward

    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?

Children
  • 0 in reply to Andrew E. Kalman

    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,

  • 0 in reply to Andrew E. Kalman

    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,

  • 0 in reply to Andrew E. Kalman

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

  • 0 in reply to Andy Neil

    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

  • 0 in reply to Andy Neil

    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)?