I've encountered a problem starting a second instance of Delphi 2010 for debugging a design time package. Under Project Options|Debugger, I use "C:\Program Files\Embarcadero\RAD Studio\7.0\bin\bds.exe" as the host app with these parameters: "-pDelphi -nocache"
I get the following error message when I run the package:
If I continue, I get the following:
Then, if I continue, I get the following:
What am I doing wrong? This has always worked before. (I have repaired and uninstalled/reinstalled Delphi 2010.)
You have a debug build of DDevExtensions installed. This version verifies its GetProcAddress calls to show missing symbols if a debugger is attached. DDevExtensions tries to hook into bcbide140.bpl (C++Builder) but doesn't find the symbols because the BPL isn't loaded (bds -pDelphi).It should skip the hooking but due to the debug build and an attached debugger it runs into the assertion.
The reason for the debug build lies in the build script of DDevExtensions: msbuild /p:Configuration=Release instead of msbuild /p:Config=Release. (So thanks for "reporting" this so I can fix the build script).
Related
A couple of days ago I have started to migrate my CMake-based C++ library project from Travis CI to GitHub Actions. I immediately ran into trouble with the windows-latest runner (link to runner specs). After many wasted hours I tracked down the issue to the Windows SDK that CMake selects when it generates the build system.
On a local VM where I tried to replicate the runner environment CMake always selects the SDK version 10.0.18362.0, because no other SDK is installed on that system. On the runner system, though, there seem to be several SDKs installed (cf. the runner specs), and CMake by default selects SDK version 10.0.17763.0.
The actual problem: With 10.0.17763.0 selected, as soon as the first file is being compiled the compiler starts spewing out C5105 warnings like the following (line breaks added by me for better readability):
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\corecrt_search.h(188,5):
warning C5105: macro expansion producing 'defined' has undefined behavior
[D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\stdlib.h(79,5):
warning C5105: macro expansion producing 'defined' has undefined behavior
[D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]
[...]
Eventually there are also errors which cause the build to fail. The first of these errors is this:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(487,17):
error C2059: syntax error: '/'
[D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]
When I force CMake to use a different SDK, by setting CMAKE_SYSTEM_VERSION to 10.0.18362.0, all problems go away and the build works fine.
Before I go down that road of forcing CMake to do something it doesn't want to do, I wanted to ask for advice if someone can recommend a better approach?
Also of interest would be if someone could explain what's actually going on here? How is it possible that MSVC has problems parsing Microsoft's own system header files when using one SDK version, and no problem at all when using another SDK version? Link to a build log in case someone is interested, but this might go away soon when I delete the branch.
In the meantime I managed to reproduce the problem on my local VM by installing the component "Windows 10 SDK (10.0.17763.0)" in the Visual Studio Installer. On the VM CMake still defaults to 10.0.18362.0, but when I force it to use 10.0.17763.0 like this
cd build
cmake -DCMAKE_SYSTEM_VERSION="10.0.17763.0" ..
then I get the same build failure as on the Github Actions runner. At least I can now say that it's not the Github Actions runner that is at fault.
On the other hand I also can't see how my project should be the culprit. I certainly don't do anything special that should make the project build with one Windows SDK, but not with the other.
Lacking the time (and the will) to further investigate the issue, for the moment I decided to follow the path of least resistance and am now building with these lines in the project's build.yml:
cd build
cmake -DCMAKE_SYSTEM_VERSION="10.0.18362.0" ..
cmake --build . --config Release
I need to build old components made for BCB6 (Borland C++ Builder 6) in Embarcadero RAD Studio XE5. Projects are CPP- projects, and the component code is contained in the *.PAS - files.
The project contain 6 packages:
three packages a design time
three packages runtime
First I build packages runtime. After that I start building and installing the packages design time that use packages runtime. And one design time package has a problem during installation:
I found a runtime package that causes this problem. My question is how do I find and resolve the following error? After all, when the package is installed, I cannot start the debugger, see the stack trace, nothing at all. What are the options? Thanks.
For that you need to run a second instance of the IDE in the debugger:
Uninstall the packages
Compile all packages with debug information
Load the project of the runtime package that causes the problem
In Run -> Parameters Set the Host application to $(BDS)\Bin\bds.exe
Press run with debug
This will start a second instance of the IDE. You might have to ignore some exceptions that it internally raises (and handles).
In that second instance, load the design time package which loads the runtime package that causes the problem
Hopefully you will now see what happens
In a Rad Studio Rio C++ project, when I compile, I get:
MSBUILD : error E1028: unable to open output file '.\Win32\Debug\Unit1\obj': 'no such file or directory'
Note that it shows Unit1\obj, not Unit1.obj.
It works fine if I compile from command line using MSBUILD MyProject.cbproj
Also, it works fine if I set on the Run C++ compiler in separate process
Also, I have found that the problem is only when I use the Configuration Manager, assigning to the projectt an .optset file. If I unlink this .optset file, then it compiles from the IDE again.
It seems a bug.
I am building OpenCV source code on Windows 10 with Visual Studio 2015, but encounter an strange error.
First of all, I configured the source code with CMake. After configuration successfully done, I opened the configured OpenCV solution with VS2015 and press F7 to build. However, seems that every project being built encounter following error caused by 'setlocal' is not recognized.
6>------ Build started: Project: IlmImf, Configuration: Debug x64 ------
6> 'setlocal' is not recognized as an internal or external command,
6> operable program or batch file.
Things are strange because previously I also built OpenCV source code on Win10 with VS2015 and there was no any such kind of error before. But not know why this error appears now.
How do resolve this error?
When I compile my code using Borland C++Builder (it is necessary for me to use only the Borland compiler), bcc32.exe is able to compile the code successfully. When I build this same code with the cov-build command inside of cmd.exe, the build fails with errors like:
cannot open source file "iostream"
What is the possible reason behind this, and how do I debug it?
Here is the code
Coverity requires that you configure your compiler in the same environment that you build it in. If you fail to do so, the configuration probes will not pick up your include paths, amongst other things.