CVI 2020: error: Input file is not a valid archive

[FlorentSEFI]

Hi all,

I know this issue has been raised many times but none of the exposed resolutions fixed my problem.

I used a .lib file in my CVI 2009 project to use a C++ 32 bits DLL (compiled with Embarcadero® C++Builder® XE2 Version 16.0.4429.46931).

Today I need to migrate this project in CVI 2020.

My lib was totally functional with CVI 2009 but now with CVI 2020 I face this link error: "Input file is not a valid archive"

I have tried:

- Creating the project from scratch in CVI 2020 and add the files -> KO

- Adding .ddl and .h file in relation to my .lib -> KO

- Playing with "Enable LoadExternalModule option in Target Settings menu -> KO

- Options > Generate DLL Import Library menu, but it does not generate .lib as it was said in a similar subject but .dll file -> KO

What can I try now?

Why is the lib file OK with 2009 but not with 2020?

My lib is using other libs. Must I integrate them into the project too?

Since I have the sources of my lib, I can recompile it but how can I know what to change to make it compatible with CVI 2020?

I have noticed that in CVI 2009, "(32 bits)" is precised in the project tree for my lib file whereas it is not in CVI 2020.

Best regards,

[rolfk]

---

@FlorentSEFI wrote:

What can I try now?

Why is the lib file OK with 2009 but not with 2020?

---

Windows libs came in the past in two flavors. Borland, Symantec and friends used the so called OMF format, while Microsoft decided to go with the COFF format. LabWindows/CVI used to support both formats, but depending what you wanted to do you had to select Borland OMF or Microsoft COFF compatibility mode during installation and couldn't switch on the fly without running the installer again to switch the mode.

Most likely LabWindows/CVI lost that ability along the line, if not already around 2010 then at latest in 2015 with the change to the clang backend compiler. Considering that all the other compilers that could create OMF format object files/libraries are nowadays factually dead, this was a logical change to do. Supporting an unused format is a major liability as it is difficult to test and exercise. So my guess is that your lib files are using the OMF format because they were created using a Borland compiler product. And there is pretty much no official compiler out there that could still use them nowadays.

[FlorentSEFI]

Hi Rolf,

Thank you for your reply and wish you a happy new year!

So my only solution is to compile my lib again with another compiler using Microsoft COFF standard?

Regards,

[rolfk]

Your best bet might be this site: https://www.agner.org/optimize/

The description of the object file converter on there seems almost to good to be true. But you can always try. For a long term solution it would seem useful to bite the sour apple and attempt to convert that library to be compiled in a Visual Studio version. However depending on the code, it may be easy (if it is mostly standard C with no Borland specific compiler intrinsics), challenging (for normal C++ code) to pretty much impossible (if the code was written with the Borland C++ classes).