FTDI static library: Error reading from file: 'LibFT4222-v1.4.7\imports\LibFT4222\lib\ucrt\amd64\LibFT4222-64.lib'.

[AllenInIowa]

I have a LabWindows/CVI 2017 program that uses the FTDI USB and I2C drivers. We have always used the DLL versions.

This weekend I was trying to make a standalone .exe tool that did not require the DLL. FTDI provides DLL and static .libs.

When I bring in the static .lib, it required setting a define "FT4222_STATIC" which I do in the Build Options:

Compiler Defines: /DWIN32_LEAN_AND_MEAN /DFT4222_STATIC

I have confirmed this define is seen (#ifdef and #error).

But, the compiler says it has an "error reading" this lib file. There is a second static .lib that it reads fine.

Any clue what could be the problem? I assume FTDI is placing working .libs in their zip file. I even re-downloaded it today to see if they had a problem and updated it in the past year.

[rolfk]

They do but a one lib is not the same as another lib.

First you have the bitness. Libs in folders called amd386 (or x86) are for 32-bit compilation. Libs in folders called amd64 (or x64 or x86_64) are for 64-bit compilation.

To make matters even more interesting there are different library formats. In old days you had the OMF (Object Model Format) library which was originally developed by Intel for their 8086 CPUs. Borland, Symantec and other compiler builders adopted this format.

Then there is the COFF (Common Object File Format) that is currently the only really used standard on Windows platforms. It was originally developed for Unix System V but Microsoft adopted it for its PE executable format (a exe file or DLL is pretty much a collection of COFF records with an extra startup stub). It also selected it for their Microsoft C compiler, later to be the Visual C compiler.

Last but not least you have ELF (Executable and Linkable Format). This was invented by AT&T to replace the COFF format for Unix SVR4, since COFF had back then many limitations that made it unsuitable to be used for shared libraries. ELF is nowadays the defacto standard on all Linux based systems.

Macintosh used a different object file format again, called PEF (Preferred Executable Format). This were the so called Code Fragments. Modern macOS uses the Mach-O file format.

So if your FTDI driver is relatively recent, it most likely contains 32-bit and 64-bit compiled libraries in the Microsoft COFF format. If it is an older driver archive it may instead contain in addition to COFF libraries also binary libraries in the OMF format for use with Borland C and Symantec C, but almost certainly only for 32-bit. LabWindows CVI supported generation and use of OMF libraries too in old versions. I believe support for that was removed somewhere around 2009.

[AllenInIowa]

Thanks for the notes. We used to build with the 32-bit .lib and DLL, but switched to the 64-bit versions years ago. We have never used the static libraries.

The 64-bit DLL .lib works fine. The 64-bit static DLL (from the same level in the FTDI zip file, just in "lib" instead of "dll") is the one that LabWindows says it cannot read.

I would have thought they would be the same type of .lib, but maybe there is a difference.

The previous FTDI 1.4.5 zip shipped with a messed up header file you had to replace with one from a different .zip they sent you to download, so perhaps it is just another bad file in the distribution.

[rolfk]

Did you try the LibFT4222-v1.4.7.zip\imports\LibFT4222\lib\vs2013\amd64\LibFT4222-64.lib?

This will need the Microsoft C runtime version 12 installed: https://www.microsoft.com/en-us/download/details.aspx?id=40784 

LibFT4222-v1.4.7.zip\imports\LibFT4222\lib\ucrt\amd64\LibFT4222-64.lib is for Universal C Runtime in Windows 10 and newer. This is a feature that was introduced with Visual Studio 2015 and eliminates the need to install a separate C runtime library for a DLL component as long as it is used on a supported platform (Windows 10 and 11).

According to the Release Notes for LabWindows/CVI 2017, it uses the Microsoft Visual C++ 2015 runtime. That version information is a little confusing as the latest Microsoft C runtime (the Universal C Runtime) is actually version 14.42. I assume they wanted to say Visual Studio 2015, which indeed comes with C Runtime 14.0, so the first version of the Universal Runtime. Currently we are at least at C runtime 14.42 for Visual Studio 2022.

[AllenInIowa]

Yes, those were the files I was trying to use. The weird thing is dragging in the .lib from the 64-bit folder was being identified as 32-bit by LabWindows. I do not know how to verify that the file in the .zip is correct.

Oddly, the "cannot read" error is the same type of error the Distribution Kits built by my PC give now. Anything I build fails right at startup, with an error pointing to a file that is there -- but says the same "cannot read".

Build the same files on a fresh Windows install and they work. Something like this happened August 2024, and after days of removing everything I could (all NI stuff) and starting over, even with the 2020 trial, it still wouldn't work. At some point, something messed up and only resetting my PC back to fresh Windows got me going again.  Then, a few months later, it happened again.

No clue if that is related, but it is the same "error reading from file" type error.

[AllenInIowa]

Today, I created a tiny sample program to test this:

#include <ansi_c.h>

#include "ftd2xx.h"     // Add to include path.
#include "LibFT4222.h"  // Add to include path.

#ifndef FT4222_STATIC
#error FT4222_STATIC must be defined to use static libs.
#endif

int main (void)
{
    FT_STATUS ftStatus = 0;
    FT_HANDLE ftHandle;

    ftStatus = FT_OpenEx ((void*)"OurCustomName A",
                          FT_OPEN_BY_DESCRIPTION,
                          &ftHandle);

    if (FT_OK == ftStatus)
    {
        FT_Close (ftHandle);
    }    
	
    return 0;
}

I set the include paths to point inside the extracted .zip file of the FTDI drivers, and I added the 64-bit static library files.

In this project, it does not complain about that .lib. The same file added to my other project gives me the "cannot read" error I posted uptopic.

What's going on here? What could I have done in a project that makes it unable to "read" a .lib file? Is LabWindows project file corruption a thing that happens or something?

This still does not work -- I get linker errors, so i have posted over in the FTDI Community to see what else I may need to add.

Can someone explain what may be going on? Thanks!

[AllenInIowa]

One difference -- the project that links is just a normal command line project, and the one that won't read the .lib is a DLL project.

But, when I change my "LibTest.c" to be a DLL, it then suddenly reads the .lib just fine, though I still have linker errors for something I am missing.

[rolfk]

There are a zillion possible reason for linker errors. For what sort of symbols are they?

[AllenInIowa]

Building in LabWindows is looking for some stdlib looking things:

 Link LibTest.dll
  error: Undefined symbol '??2@YAPEAX_K@Z' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??3@YAXPEAX_K@Z' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??_7type_info@@6B@' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??_U@YAPEAX_K@Z' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??_V@YAXPEAX@Z' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '__acrt_iob_func' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '__stdio_common_vfprintf' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_i64toa' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_ismbcalpha' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_localtime64' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_mbctolower' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_mbctoupper' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_purecall' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_strupr' referenced in "c:\Users\huffm\OneDrive\Bitbucket\development\SST\Host\PrecisePowerDLL\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
Build failed.

Building in GCC just wants the mangled functions:

..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0xec)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x16d)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x1e5)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x25d)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x2d5)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\fteepd.obj):(.data$r+0x0)||undefined reference to `??_7type_info@@6B@'|

The FTDI example that does this is designed for Visual Studio.

[AllenInIowa]

When compiling using GCC, I get some mangled names that make me think there is some C++ stuff going on:

..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0xec)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x16d)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x1e5)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x25d)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\FTD2XX.obj):(.text$mn+0x2d5)||undefined reference to `??3@YAXPEAX_K@Z'|
..\..\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib(x64\Release\fteepd.obj):(.data$r+0x0)||undefined reference to `??_7type_info@@6B@'|

When I build from inside LabWindows, I get those linker errors, plus a bunch more that look like some kind of C lib stuff:

 Link LibTest.dll
  error: Undefined symbol '??2@YAPEAX_K@Z' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??3@YAXPEAX_K@Z' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??_7type_info@@6B@' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??_U@YAPEAX_K@Z' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '??_V@YAXPEAX@Z' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '__acrt_iob_func' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '__stdio_common_vfprintf' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_i64toa' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_ismbcalpha' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_localtime64' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_mbctolower' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_mbctoupper' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_purecall' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
  error: Undefined symbol '_strupr' referenced in "(path removed)\\LibFT4222-v1.4.7\imports\ftd2xx\lib\amd64\ftd2xx.lib".  
Build failed.

Someone from FTDI reached out to me (they saw a post I made elsewhere) and pointed me to a different .lib from a different zip file, but it does the same thing.