using static windows lib

[schnitzel]

My platform: Qt SDK 2010.01 with MingW and Qt Creator

I'm using a driver from FTDI for a project. I can successfully create an import library (using the reimp and dlltool as part of mingw-utils) from the vendor supplied DLL and lib file. App runs fine.

The vendor also supplies a static library (.lib extension) most likely built with MS VS, but I'm not sure how to convert it so it can be linked with my app. If I run reimp on it, it produces a bunch of .OBJ files and two .def and two .a libs.

[schnitzel]

I am able to successfully link external static libs (for example qextserialport) because I can just build the .a from source.
Just wanted to know if it can be done without rebuilding from source given that the static lib is actually from a different compiler.

[Timoteo]

No. A static lib is nothing more than object code from multiple modules all melded together, so there's a very explicit dependency between compiler and linker there. Staying within a given tool chain is fine (e.g. cl/ml + link of varying versions) but all bets are off once you cross that boundary.

[wysota]

Maybe you could ask the vendor to build the library with MinGW for you or to provide the source code so that you can do it yourself.

[schnitzel]

@Timoteo - I figured it would be too compiler dependent, but thanks anyway for the clarification

@wysota - I doubt they would give me the sources, but I'll kindly ask them to rebuild on MingW.

[marcvanriet]

Is there a reason why you can't use the DLL they provide ?

Regards,
Marc

[schnitzel]

Is there a reason why you can't use the DLL they provide ?

Regards,
Marc

I can use their DLL just fine as I have indicated. With static linking, I would have more control about using a specific and tested version in my app whereas now I need to make sure the other DLL is installed by the third party installer and that it is the correct version.

[marcvanriet]

OK

It's just that I have the experience with their devices that it is always best to install the latest version of their drivers from the website.

You have a point in having a 'stable' version since there's always a risk that the customer buys something like a serial cable with their chip in it, and they (or an installation CD that came with it) install an outdated version. But if your applicaton uses a FTDIchip cable that is bought off-the-shelf and integrated in your equipment, there's also the risk that some (newer) cable has a different chip revision or even a different chip built-in. Depends on your application of course.

The linux versions of the D2XX drivers are not open source by the way, so I guess you won't get the code for the windows drivers either.

Best regards,
Marc

[schnitzel]

I agree that you can rarely go wrong with the latest driver, but consider this:

I provide a certain version of the driver with my app (or at least point the user to the driver on the FTDI website), but what do you do if the user doesn't install it and they just happen to have an old version of the driver on their machine... I've actually run into a situation like that. I was on site and busting my head against the wall until I realized that the driver was way older than what my app was tested with. My application did work, but was running into a driver bug that was fixed after the old driver but before my expected driver.

I'm now planning to check for the version of the DLL so I don't run into this problem again.