Question

I’m trying to port a program written in Microsoft Visual Studio (in c, c++ and fortran) to a mac OSX. Within this program is a c++ function being called by a fortran source code. Basically its interloping c++ and fortran. I have wrapped the C++ function in an "extern C" brackets, which I’m told via the internet is the proper method. However, the linker is still complaining of an undefined symbol within this c++ function…

Undefined symbols:
  "__Z7_getcwdPci", referenced from:
      _bisimr_ in bisimR.o
ld: symbol(s) not found

if you look through the internet, getcwd is a function defined in a header file, "direct.h". It is not part of the mac OS and is only inherent on a Windows system. I was able to find the file on the internet that, to the best of my knowledge, seems to be the windows “direct.h” file.

Now that we are done with the context, here is my question

Given that I get an error, could it be that my direct.h file is not the correct header file that is part of Windows? or is name mangling, going from C++ to fortran, throwing out this error?

note:

• I can get through the compile stage, its the linking of the libraries that throws this error.
• bisimr_ is the c++ function

Answer 1

As far as I understand your question, you tried to build the program by copying a header file from a Windows system. Right so far? That approach is bound to fail: the presence of the header file will provide the compiler with information as to what functions are available on a Windows system, but the linker will complain because none of the listed libraries defines a function of said name.

You should only be using headers which come with your system, or from third-party libraries which you already compiled successfully for your system. Sourcecode-only headers (template libraries in particular) are OK as well. The use of any other header is just asking for linker errors.

The fact that the name appears mangled is an indication that the compiler considers it a C++ function which might be overloaded, so it will include details about the argument types in the name. That aspect might be avoided by enclosing the #include statement in an extern "C" block. For the windows file direct.h this will not solve the above problems, but perhaps it will make unistd.h useful to you:

extern "C" {
#include <unistd.h>
}