I have some HDF5 C code that I am trying to port to C++Builder. I am getting this error at build time:
[ilink64 Error] Error: Unresolved external 'H5check_version' referenced from D:\DELPHITOOLS\PASHDF\C\WIN64\DEBUG\FILE2.O
H5check_version is included in H5public.h as a macro.
Why does C++Builder not find this?
H5check_version is included in H5public.h as a macro.
If that were true, you would not be getting a linker error, since macros are handled only during the preprocessor stage.
Somewhere in your project, the compiler is seeing a declaration of H5check_version as a function, and your file2 unit is calling it as a function, but the linker can't find the implementation of that function, hence the error.
Your project needs to contain a reference to the appropriate .lib file that either implements the actual function (static linking) or tells the linker which DLL the function is exported from (dynamic linking).
C/C++ is case sensitive, so H5check_version is different from H5Check_version.
AFAIK pascal is not case sensitive at all.
Regards
Related
I am creating a DLL and exporting a SimpleMAPI DLL function and one of the functions signature is as following:
extern "C" ULONG __declspec(dllexport) WINAPI MAPISendMail(LHANDLE lhSession, ULONG_PTR ulUIParam, lpMapiMessage lpMessage, FLAGS flFlags, ULONG ulReserved);
I am using C++ Builder, using clang compiler. Compiler issues warning:
[bcc32c Warning]: redeclaration of 'MAPISendMail' should not add 'dllexport' attribute mapi.h(262): previous declaration is here
It compiles and works, but I am bothered by this warning. Can it be avoided?
As #RemyLebeau pointed out, the warnings happened because I included <mapi.h> header.
If MAPI DLL is being created (creating your own DLL that other programs will use or exporting MAPI functions), so if one is implementing MAPI support in their own program, then the required structures and #define are copied from the original mapi.h file into a custom header file which is then included. #define such as FLAGS or MapiMessage struct.
If MAPI is being used (so using calling MAPI functions from other DLL, or other programs) then <mapi.h> is included.
So after creating a custom mapidefs.h file which only contained required structures and #define, the problem is now solved.
There is also this example on StackOverflow as well.
My codes and the errors that I got
I got this problem with the turbo c++ that every time I'm compiling my codes it just pull some errors which I already tested to online compiler (gdb online compiler).
The first error is "Declaration is not allowed here".
The file is .C, not .CPP, so it is probably compiled as C and not as C++. Variable definitions in the middle of the code are only allowed in C++. Just move the definition to the beginning of the function.
The following warnings are "Function should return a value".
If a function is not defined as void (eg. int) it should have a return statement which returns a value of the type of the function.
I am facing quite a strange situation trying to build a mixed-language dynamic iOS framework with Bazel.
The source code of the framework consists of *.c, *.cpp, *.m, *.mm, *.h, *.hpp files.
My first naive attempt was to declare a single objc_library rule referencing all the sources. That failed with an error message reading something about conflicting rules. Then I declared four distinct objc_library rules for *.m, *.mm, *.c, and *.cpp files respectively, and then referenced all these four rules as dependencies for the final ios_framework rule.
At this point, everything compiled and linked just fine (barring several compiler warnings which were expected). However, now the black magic begins:
The static library resulting from compiling ObjectiveC++ sources does contain all the necessary symbols (verified with the "nm" tool)
The .apple_binary_lipobin file resulting from the linking phase does not contain symbols from ObjectiveC++ sources
I believe I carefully went through the command lines used for compiling and linking, both for Bazel and xcodebuild.
The only anomalies I was able to spot:
xcodebuild passes a -single_module argument when linking, while Bazel cross tool does not.
Bazel cross tool adds '-stdlib=libc++' '-std=gnu++11' command line arguments when invoking wrapped_clang_pp during linking, while xcodebuild does not pass these arguments. I guess Bazel does this because there're these lines in the default Apple CROSSTOOL:
action_config {
config_name: "objc++-executable"
action_name: "objc++-executable"
tool {
tool_path: "wrapped_clang_pp"
execution_requirement: "requires-darwin"
}
flag_set {
flag_group {
flag: "-stdlib=libc++"
flag: "-std=gnu++11"
}
but I am not sure if these flags are really needed when invoking the linker.
I must admit I've run out of ideas except for trying to patch the CROSSTOOl file to make it behave as close as xcodebuild as possible.
Please help.
Can you try adding alwayslink = 1 to the objc_library target containing the C++ symbols? The linker is deadstripping the C++ symbols as they are not being referenced anywhere in the binary.
I'v been trying to get OmniThreadLibrary to run in builder, i've built it with all the c++ required files it builds ok but when i use it in an c++ builder app i get a bunch of error messages that look like the following
[bcc32 Error] DSiWin32.hpp(385): E2040 Declaration terminated incorrectly
one points at this line of code in the generated hpp file
static const System::Int8 CSIDL_ADMINTOOLS = System::Int8(0x30);
has anyone had this working in C++ builder or know the best way to resolve these issues
I'm using c++ builder settle and OmniThreadLibrary version 3.06
The Win32 API (and Delphi, for that matter) already declares CSIDL_ADMINTOOLS, Omni should not be declaring it at all. It should be using Delphi's Shlobj unit instead.
The Win32 API declares CSIDL_ADMINTOOLS using a #define statement:
#define CSIDL_ADMINTOOLS 0x0030
So the declaration in Omni's .hpp is getting modified by the C++ preprocessor to this:
static const System::Int8 0x0030 = System::Int8(0x30);
Thus the "Declaration terminated incorrectly" compiler error.
When Delphi code declares something that already exists in C++, it needs to be declared as either {$EXTERNALSYM} or {$NODECLARE} to avoid duplicate declarations, and then optionally use {$HPPEMIT} to output a relevant #include statement in a generated .hpp file. Delphi's units already do that for its Win32 declarations.
If Omni is not already doing that (and the error would suggest it is not) then it needs to be updated accordingly.
I am converting a component package from Delphi 2007 to Delphi 2010.
When I do a full build, it compiles and begins to link. During linking, I get two messages:
[DCC Warning] MyPackage.dpk(235): W1033 Unit 'OleAuto' implicitly imported into package 'MyPackage'
[DCC Error] E2223 $DENYPACKAGEUNIT 'OleAuto' cannot be put into a package
What determines the units in $DENYPACKAGEUNIT? How should I resolve this error?
I found this inside the OleAuto.pas unit, which pretty much answers my question.
unit OleAuto deprecated;
{$DENYPACKAGEUNIT}
{ OleAuto cannot be used in a package DLL. To implement
an OLE automation server in a package, use the new
OLE automation support in comobj and comserv.
}
I found that someone had placed a call to MtsObj file, thats what seemed be to causing my issue.