I've tried to compile generated IDL files from Rhapsody 7.1.1 with the last version of TAO IDL Compiler (released package version 6.0.2), but I get some errors because anonymous types are deprecated in CORBA 3.1.
This kind of errors could be suppressed using TAO IDL Compiler "-as" option. But, for maintenance reasons, I want to generate compliant IDL files.
Also, I get other errors from the TAO IDL Compiler related with interface forwarding. This generated IDL files compile correctly until TAO version 5.7.9 (1.7.9).
Edited:
The main problem with interface forwarding is that a forward of an already defined interface hides the contents of such interface.
Example:
A.idl
interface A {
typedef long my_long_type;
};
B.idl
#include "A.idl"
interface A;
interface B {
typedef A::my_long_type my_b_long; // Error with TAO versions greater than 5.7.9
};
If I remove the forward of A there is no problem, but i can't because the IDL files are generated by Rhapsody by this way.
For the interface forward, create a small reproducer and if this is a bug in TAO_IDL, than report it in the TAO bugzilla at http://bugzilla.dre.vanderbilt.edu/
Related
I have a legacy Windows project using the legacy 32 Bit C++ compiler. For various reasons I need to use the Windows 8+ function PathCchCanonicalizeEx. C++Builder seems to provide the header and some module definition file for that, but I can't find any library to link against:
[ilink32 Error] Error: Unresolved external 'PathCchCanonicalizeEx' referenced from C:\[...]\WIN32\DEBUG\TMP\FILE.OBJ
How am I supposed to fix this? Do I need to add a Windows 8.1 SDK? Is the necessary lib simply named differently and I can't find it? Something completely different?
According my tests, one has two options:
IMPLIB/MKEXP
I'm developing/testing a some Windows 10 21H2, which provides an implementation for PathCchCanonicalizeEx in some DLL already. So if that source DLL is known, one can use IMPLIB or MKEXP to create an import library manually. I did that and after adding the created library from IMPLIB to my project, the linker errors were instantly gone.
Though, it's not that easy to know where PathCchCanonicalizeEx is placed in. One pretty easily finds the api-ms-win-core-path-l1-1-0.dll, but that thing is NOT an actual file on the disk and therefore can't be used by IMPLIB or MKEXP. That name is only a virtual concept for the library loader to address the same named API set of modern Windows, the extension .dll doesn't mean it's a file at all.
You can use an API set name in the context of a loader operation such as LoadLibrary or P/Invoke instead of a DLL module name to ensure a correct route to the implementation no matter where the API is actually implemented on the current device. However, when you do this you must append the string .dll at the end of the contract name. This is a requirement of the loader to function properly, and is not considered actually a part of the contract name. Although contract names appear similar to DLL names in this context, they are fundamentally different from DLL module names and do not directly refer to a file on disk.
https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets#api-set-contract-names
What you really need to work with is KernelBase.dll, which is even documented by MS.
implib "KernelBase x86.lib" C:\Windows\SysWOW64\KernelBase.dll
implib "KernelBase x86-64.lib" C:\Windows\System32\KernelBase.dll
Module Definition File
The downside of manually creating LIB files is that one needs to maintain those with the project. Things depend on if the target is 32 or 64 Bit, DEBUG or RELEASE, so paths might become a bit complex, one might need to create relative paths for libraries in the project settings using placeholders for the target and stuff like that.
It seems that all of this can be avoided with Module Definition Files, which's purpose is to provide IMPORT and EXPORT statements to either consume exported functions by other DLLs or make that possible for others with own functions. I've successfully resolved my linker problems by simply creating a file named like my app using the extension .def alongside my other project files. That file needs to be added to the project, though.
dbxml.cbproj
dbxml.cbproj.local
dbxml.cpp
dbxml.def
dbxml.res
[...]
The following content made the app use the correct function from the correct DLL. Though, what didn't work was using the API set name, which resulted in an error message by the linker.
IMPORTS
KernelBase.PathCchCanonicalizeEx
IMPORTS
api-ms-win-core-path-l1-1-0.PathCchCanonicalizeEx
[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.
[ilink32 Error] Fatal: Error processing .DEF file
The latter is after restarting C++Builder, so I guess the format of the file is simply wrong because of the API set name.
I'm compiling c++ to web assembly using clang --target=wasm32 --no-standard-libraries. Is there a way to convince clang to generate sqrt? It's not finding <math.h> with this target.
Do you already tried to compile without the flag --no-standard-libraries? If you remove it, the clang probably will find math.h library (because its a standard library).
This is because wasm32-unknown-unknown is a completely barebones targets in Clang, and doesn't have any standard library - that is, no math.h, no I/O functions, not even memcpy.
However, you can usually get away with using --target wasm32-wasi + WASI SDK instead: https://github.com/WebAssembly/wasi-sdk
It includes the whole standard library, including even functions for interacting with the filesystem via the WASI standard in compatible environments.
If your code doesn't depend on filesystem / clock / other I/O, then you can safely use WASI-SDK to get math.h, memcpy, malloc and other standard functions, and the resulting WebAssembly will be compatible with any non-WASI environments as well.
I'm using the python bindings to walk the clang AST...
When I encounter an error, I would like to dump the AST to a file, so that I can later load it from that file and debug the walker.
This works fine, if I dump and then load using the TranslationUnit.save() and Index.read() bindings, however this does not work if I move the AST file between platforms Linux -> Windows or Windows -> Linux.
Is this expected?
Is there a way to make the AST files "portable"?
Not "portable" if you have some template C++ code that is accepted by MSVC, but typically diagnosed by Clang as invalid.
From Clang Documentation:
Third, MSVC accepts some C++ code that Clang will typically diagnose as invalid. When these constructs are present in widely included system headers, Clang attempts to recover and continue compiling the user’s program. Most parsing and semantic compatibility tweaks are controlled by -fms-compatibility and -fdelayed-template-parsing, and they are a work in progress.
Compare your saved AST files to check if they have the same nodes (the raw pointer address could be different). If not, fixed with the mentioned flags -fms-compatibility, -fdelayed-template-parsing.
Delphi 10 Seattle introduces Winapi.Security.pas. The project (a package) I'm trying to upgrade already has a Security.pas file. Short of removing Winapi from the list of scope names for the project (huge undesirable ripple effect), is there a way to tell the IDE and compiler to use the project's Security.pas file instead of Winapi.Security.pas?
I already tried renaming the projects Security.pas, but that caused even more problems with the compiler generating errors that have nothing to do with the code it was complaining about, so that's a rathole I'd rather not go down right now. This project builds just fine unchanged in XE7, FWIW, so this isn't due to any code changes in the project.
Updates:
Renaming the file and using a unit alias doesn't work.
The compiler behavior for a package differs from an application.
Looks like this might actually be related to the Winapi.Security unit rather than something as generic as you suggest in the question. For instance, the following package compiles just fine:
package Package1;
requires
rtl;
contains
Windows in 'Windows.pas'; // blank unit named Windows.pas in project folder
end.
Note that I have, like you, included Winapi in the project's list of unit scope names.
On the other hand, this package does not compile:
package Package1;
requires
rtl;
contains
Security in 'Security.pas'; // blank unit named Security.pas in project folder
end.
The compiler fails with:
[dcc32 Error] Package1.dpk(7): E2200 Package 'rtl' already contains unit 'Winapi.Security'
If the issue was purely related to unit scope names then either both packages would compile, or both would fail. Hence my conclusion that there is something out of whack with Winapi.Security.
I can find no source code for Winapi.Security. I wonder what it actually is. [Nicholas Ring located the source for me, inside the rtl\win\winrt directory.]
Anyway, I think it's time to submit a QP report. The package below that fails to compile is probably the starting point for that QP report. [Your submitted report is here RSP-12469.]
It seems clear to me that in the short term you must rename your unit if you wish to adopt Seattle.
FWIW, here are some other units that behave the same way as Winapi.Security:
Winapi.ApplicationModel
Winapi.CommonTypes
Winapi.Devices
Winapi.Foundation
Winapi.Gaming
Winapi.Globalization
Winapi.GraphicsRT
Winapi.Management
Winapi.Media
Winapi.Networking
Winapi.Storage
Winapi.UI
Winapi.WebRT
These are all newly added WinRT units which I expect is important.
If you put both Winapi.Security and your local Security in the same uses clause then you are able to access the members of both of them without issue. If you put them in separate uses clauses (Interface vs. Implementation) then you will get the error:
E2004 Identifier redeclared: 'Winapi.Security'
If I only include Security.pas in the uses clause (and it is included in the project) then it accesses its members just fine.
Perhaps I need more information about what error you are running into? I'll send you a sample project that shows this working.
I might well be wrong, but I believe that if Security.pas is in the uses clause of the dpr file, along with its full path, it will be preferred over whichever file can be found via the namespaces and search paths.
Open project settings, in the Delphi Compiler section remove "Winapi" from "Unit scope names".
This way, when you need the Security unit shipped with Delphi, you'll have to write Winapi.Security, and if you write Security, it will use your custom Security unit.
When compiling a OpenCV 2.3 project in Builder I get multiple errors starting with "_fm_atan2l is not a member of 'std'" and continuing with other math related errors in that form. I also get "Multiple declaration of '_Ctraits::_Isnan(double)' and other similar errors. This happens after I simply include the OpenCV header files and thus seems unrelated to anything I have done in the application itself.
The only file I have included so far is "cv.h" in OpenCV's include directory. Am I doing it wrong already or is there maybe something else I have to set up first?
You can download simple project combining 2.3.2 and c++ builder xe2 from my site:
http://www.compvision.ru/forum/index.php?showtopic=763
There are fixed headers for builder, and lib converter in archive.
There are also .lib files in archive, but it'll be better if you make them by yourself from original .lib files contained in your opencv distribution using LibConverter.exe utility.
And there is some strange thing: some dll files need to be renamed to something like .dl or .d. Compiled program will prompt you about it.
you can correct OCV atan2 issue with bcc32, including fastmath in std namespace (for more info see: https://forums.embarcadero.com/message.jspa?messageID=363384 [^]).... but more other issues are there after ...
Until now I'm unable to build OCV 2.3.1 with CBuilder XE2 :(