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)
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; }
unsigned char asdf = 0;
*** WARNING L25: DATA TYPES DIFFERENT SYMBOL: asdf MODULE: main.obj (MAIN)
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];
extern OStypeEcb OSecbArea[];
extern type ArrayName[];
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)?