Reputation: 33
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:
bisimr_
is the c++ functionUpvotes: 2
Views: 387
Reputation: 60908
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>
}
Upvotes: 2