In C++ Builder when I compile I get
[ilink32 Error] Error: 'C:\PATH\TO\A\LIB\INCLUDED\IN\THE\PROJECT\ALIBRARY.LIB' contains invalid OMF record, type 0x21 (possibly COFF)
When I convert .lib with utilities coff2omf, new lib looses significant functions.
C++Builder cannot use .lib files from other compilers, only its own.
If the .lib file is an import lib for a DLL, use C++Builder's command-line IMPLIB tool to create a new .lib file from the DLL directly.
If the .lib file is a static library (containing actual code), C++Builder's command-line COFF2OMF tool MAY be able to convert the library, but it is not guaranteed. It really depends on what kind of code the library is actually using. If the conversion is not possible, you will have to wrap the .lib file into a DLL that is written in the same compiler that created the .lib file. Then you can use the DLL in C++Builder.
I was facing the same issue. I have used the tool COFF2OMF to covert the existing lib files to make them compatible with C++Builder. It works for me.
Syntax:
..Embarcadero/../bin> COFF2OMF libssl.lib alibssl.lib
..Embarcadero/../bin> COFF2OMF libcrypto.lib alibcrypto.lib
Renamed the converted files and placed them in the required location.
Related
Today I'm trying to figure out why something works when I think it should be broken.
I have little Delphi experience, and I've inherited a Delphi codebase and am setting up a machine where it will be maintained and compiled. I have a package that compiles successfully but can't figure out how it is resolving one of the types. My understanding is that when you use a unit, you must either
Include the source file in your package directly
Resolve the source pas or dcu file on your project search path
Resolve the source pas or dcu file on your IDE library path
None of these appear to be happening, and yet the package compiles. How else could this be compiling successfully?
Details
I have 'base' package that has a direct include on the file THotLog.pas. The file appears under the project's Contains folder in Project Manager. THotLog is NOT one of the components in the package, it is not in the register procedure for base package.
I then have 'consuming' package that requires base package. Consuming package has several components with THotLog members, and consuming package compiles. This surprises me, because I thought consuming package would have to be able to locate THotLog.pas or THotLog.dcu.
This is for RAD Studio 10.1. The project search path (Project > Options : Search path) is empty, and the IDE search paths (Tools > Options , then Environment Options > Delphi Options > Library) do not include where THotLog is.
I've also tried renamed all THotLog files on the hard drive and consuming package still compiles.
Hypothesizing that my understanding about type resolution is wrong, I tried making a set of sample projects with a similar layout and the sample consuming package cannot resolve sample THotLog without locating the pas or dcu file.
When you build a Delphi package, the compiler/linker creates a Compiled Package File named [package-name].dcp. It is a binary file containing all of the compiled units included in that package.
Compiling your "base" package created a [base-package].dcp file that is visible to the "consuming" package. The "consuming" package is referencing the base-package in its "Requires" section; this is the link to the base package's DCP file.
Delphi Compiled Package File
When I tried to compile one of my BPL files, I get an error:
dxGDIPlusClasses.pas not found.
I double checked the unit file exists on the hard drive.
I also added $(BDSCOMMONDIR)\Dcp to the DCP Output directory, and $(BDSCOMMONDIR)\Bpl to the Package Output directory. The runtime package containing the unit was also added to the BPL.
I searched online for answers, foound one suggestion to enable Build with runtime packages under the Project Options, but when I checked I dont have that option.
Does anyone know how to solve this?
The error message indicates that either:
the compiler can't find the source file it needs for the unit.
the compiler found a .dcu file compiled with a different version of the compiler and needs to recompile it.
.dcu files are not compatible across compiler versions (with the single exception of D2006->D2007), meaning that every new version release of the compiler means all your source needs to be recompiled in order to be compatible with it.
You need to add the path to the source to Project->Options->Directories and Conditionals->Search Path so it can find the source code it needs.
I want to create my own .dll file with visual studio.
The problem is, that I have included Open CV inside my program, because I'm using a method from Open CV.
My question now is, is it possible to create my own .dll file although I'm using a Open CV library? Is the Open CV lib, included inside my own .dll than, or how does it work?
Thank and best wishes,
Andi!
I think you can do this in two ways:
Statically link OpenCV into your DLL
Run-time Dynamically link OpenCV from your DLL
The first one requires you to build OpenCV as a static library (output is a large .lib file, no .dll).
In your own DLL, you specify you want to link with opencv.lib.
The second one requires you to build OpenCV as a dynamic library (output is a small .lib file, and a big .dll).
In your own DLL, you would have to add code to manually load the OpenCV library and find the addresses of the functions you need to call from OpenCV (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms685090%28v=vs.85%29.aspx)
In Delphi linker tab (project option), there is a "Map file" option. I need to know a way to use with $IFOPT to detect the option is specified when compiling in order to have certain codes to be compiled.
{$IFOPT MapFileOption.....}
{$ENDIF}
There is no way to test this from code using $IFOPT.
The reason for this is that the map file generation happens post-compile. It is a link time step. So, you can take compiled dcu files and link them into an executable, generating a map file at that point. You can do this repeatedly, choosing different map file options each time, using the same dcu files. So, at the point of compilation, it is not known which map file option will be used.
I suppose the easiest way to see this is to consider the code in the Delphi RTL. That is supplied to you in the form of dcu files compiled by the vendor. You can build your executable with detail map, and I build mine without. But we both used the same RTL dcu files.
We have a modified menus.pas.
At
uses ...,Controls,...;
The compiler raised a fatal error:
[DCC Fatal Error] Menus.pas(*): F2051 Unit Controls was compiled with
a different version of Menus.TPopupMenu
tried:
deleted all dcu in the project.
build
build all
tried adding the file to library path which leads to add db folder(from vcl too) and then to
[DCC Error] jpeg.pas(872): E2065 Unsatisfied forward or external declaration: 'jpeg_save_markers'
which is a dead end.
deleted the controls.dcu (all 3) and the delphi did not know automaticaly to recompile them, instead reported that controls.dcu is missing.
Here is how I handle modifications to VCL source files:
Make a copy of the file in your project structure. Either add the file to your project, or make sure the search path finds your modified file.
Make modifications, but only in the implementation section. You are not able to modify the interface section if you use any other units that themselves use the unit you are modifying.
Explicitly set the compiler options at the top of the modified source file. Use default Delphi options, as found by pressing CTRL+O O in a default vanilla project.
I'd guess that one of the final two bullet points is what is tripping you up.
In Delphi XE7 (and below) themes and styles are totally unusable.
So, I patched the file ( Delphi XE7\source\vcl\Vcl.Themes.pas ) add it to the project file, compiled it and got a DCU. I replaced the old DCU ( Delphi XE7\lib\win32\release\Vcl.Themes.dcu - same for "debug" folder) with the new one. Everything works smooth now. I don't even have to link the PAS file to my projects.