dSPACE compiler linker error -- fscanf undefined

Question

I'm dealing with a somewhat intractable problem. We're running dSPACE 7.4 (RTI 1006) on MATLAB 2011a, which I understand uses the dSPACE DS1006 C Compiler v. 2.2. When I try to compile one of our models, I wind up with a linker error claiming that fscanf is undefined (it's being invoked in a custom function). I have verified that stdio.h is where it should be in the system hierarchy and that it contains a definition for fscanf. Following are the steps I took to try to resolve the problem:

• linker initially complains about undefined fscanf()
• extra definition inserted in model-specific file where I know it will be compiled causes linker to complain about inconsistent definitions for fscanf()
• commenting out fscanf() definition in stdio.h then allows successful compilation/linking
• inserting stub definition into stdio.h and commenting out original (and stub in model-specific file) results in 'multiple definitions of fscanf' errors (this is the weirdest part of the whole story)

The stub definition (I am assured by a higher-up that this shouldn't break our model but I haven't yet had a chance to verify this) is as follows:

int fscanf(int a, char *cp, void *b, ...){return 0;}

So, if I'm reading it correctly it's a version of fscanf that won't actually do what fscanf is supposed to do. In summary, I have to hack my compiler's library to get this model to build, and I'm not entirely confident that it will run on our hardware at present. I also don't want to tell everyone in the office to modify their dSPACE installation and break fscanf unless I know that it works and it's the only way forward.

Can anyone give me some insight on this?

UPDATE: It does indeed run on our hardware. But I don't like breaking fscanf(), so I'd still like to figure this out.

Answer 1

This presumably worked before. So the fundamental first step is to regress any and all of the changes you made (you are using source control, right?) until you get it back to a known good state.

From there, you need to examine the change you made. C supports methods having identical names so long as they have different method signatures. I.e. the input parameters must be different between the two methods.

C also supports letting you define those two identically named methods in two different areas. So you can use the standard fscanf method as well as this custom implementation that you've run into.

The definition you mentioned:
int fscanf(int a, char *cp, void *b, ...){return 0;} is likely where you're having problems. And you likely have an additional definition of fscanf beyond the standard lib definition. And the two "home grown" fscanf methods likely have conflicting method signatures. The ... as the fourth parameter indicates that the method can take a variable number of inputs. My best guess is that there's another fscanf definition with 4 inputs defined and / or followed by the variable input indicator.

In short - hunt down all of the definitions you have in your application for fscanf. That's where you'll find the conflicting definition and the source of your linker error.