Re: resolving linker errors

On Mar 8, 10:35 pm, Norbert Unterberg <nunterb...@xxxxxxxxxxxxxxxxx>
wrote:
pauldepst...@xxxxxxx schrieb:

Not a language question at all but it is vc and any other group would
be hopelessly slow in responding.  In my project, there are lots of
declared functions that are not defined.  I am able to steadily
eliminate the linker errors by adding the definition files to the
solution and the files also become visible in solution explorer.

I wonder what you are doing here.
What functions are you talking about? Have you written them? Are they from other
members of your team? Are they from a third-party library, or are they part of
the standard runtime library?

If you have written them for the same project, then they should already be part
of the project workspace. If not, you should know them and you should be able to
simplay add all the cpp files from your project folder in one step.

If the functions are from a different (or third party) project, you would
normally have library (*.lib file) and all you should need to do is add the lib
file to your linker settings (look for "additional libraries" in the input files
section).

Norbert





I would bet that it's possible to tinker with the settings so that the
compiler finds the files even when they are not in the solution.  I
would bet there's a faster solution than simply adding the files one
at a time.

I am a newbie so I would be grateful for easily-followable
instructions such as "go to tools then options ..."

Thank you very much for your help.

Paul Epstein- Hide quoted text -

- Show quoted text -

The functions are from other members of my team. I think my
question's been answered and I certainly learned something.
So now, I'd like to follow up with a related question. The #include
"somefile.h" statements already tell the compiler to compile the
necessary h files. Therefore, what are the practical reasons (if any)
to add the included .h files to the solution so that they are visible
in solution explorer? My perception is that adding .h files in this
way doesn't really make any difference -- the only difference is in
the ability to get easy access to the .h files by using the explorer
tool.

But am I missing something? Is there some essential reason to add
a .h file to the solution space when an #include statement will
compile it anyway?

Thanks,

Paul Epstein
.

Relevant Pages

  • /ports/multimedia/gstreamer-plugins80/ fails
    ... checking for C compiler default output file name... ... checking whether we are using the GNU C compiler... ... checking whether the cc linker supports shared libraries... ...
    (freebsd-questions)
  • gstreamer-plugins80 compile fails
    ... checking for C compiler default output file name... ... checking whether we are using the GNU C compiler... ... checking whether the cc linker supports shared libraries... ...
    (freebsd-questions)
  • Newbie packages question
    ... checking for gcc... ... checking for C compiler default output file name... ... checking if the linker is GNU ld... ... checking how to recognise dependent libraries... ...
    (Debian-User)
  • Re: where does the header implentation get inserted
    ... suppose i declare a function in "myLib.h". ... where and how the compiler insert the lines in "somthing.c" ... tell the compiler to compile it too, and then tell the linker to link ... Libraries are processed at link time. ...
    (comp.lang.c)
  • SUCCESS: DBD::Oracle 1.15 on HP-UX 11.11
    ... to link 32bit executables to 64bit libraries. ... * The format of compiled objects is specified by compiler options. ... while ora9 delivers only 2.0/64. ... a bit inconsistent considering the ora8 setup, ...
    (perl.dbi.users)