HiGHS Supplying a *.lib File Instead of the libhighs.dll.a

[jeffreydeankelly2]

Hi All;

When downloading the HiGHS binaries, only a libhighs.dll.a file is provided in the LIB sub-directory.

I am wondering if you can supply a *.lib file as well as part of your installation?

Our software has interfaced the following third-party solvers and all of them supply a *.lib file as their standard / default binary file install.

We statically link these *.lib files using Intel Fortran via its Fortran-C interoperability capability.

COINMP, GLPK, LPSOLVE, SCIP, IPOPT, CONOPT, KNITRO, LINDO, MOSEK, GUROBI, CPLEX, XPRESS and OPTONOMY.

Of course at runtime if the corresponding *.dll is not found, then an exception is raised.

All the best - Jeff

[odow]

The current binaries are not maintained by the core HiGHS team. We dynamically link things for use in Julia, but these binaries can also be used outside of Julia.

Do you only want static windows binaries? We had a look at compiling static libraries, but it gets complicated across all systems because it pulls in GPL software on linux.

HiGHS is also pretty easy to compile, so it shouldn't be hard to add that to your build system.

See also: #746

[jeffreydeankelly2]

Hi Oscar; Do you only want static windows binaries? Yes, I believe so if that is what all of the solver *.lib binaries are. These *.lib files have been very consistent across the 13 third-party solvers we include in our software. HiGHS is also pretty easy to compile, so it shouldn't be hard to add that to your build system. Unfortunately our software is in Intel Fortran and we cannot compile from C or C++, hence the reason we deploy with the pre-compiled Windows binaries prepared by the other solvers. Do you know if there is a way to link to the *.dll.a similar to a *.lib file? All the best - Jeff

…

On Wed, Mar 23, 2022 at 2:53 PM Oscar Dowson ***@***.***> wrote: The current binaries are not maintained by the core HiGHS team. We dynamically link things for use in Julia, but these binaries can also be used outside of Julia. Do you only want static windows binaries? We had a look at compiling static libraries, but it gets complicated across all systems because it pulls in GPL software on linux. HiGHS is also pretty easy to compile, so it shouldn't be hard to add that to your build system. See also: #746 <#746> — Reply to this email directly, view it on GitHub <#777 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEC2VIH7TN552KGTESDVBNSDPANCNFSM5ROKXTVQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ********************************************************** *I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m a t i o n S m a r t e r"* Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: ***@***.*** Phone: (647) 917-4675 (IMPL) *Making Industrial AI (Algorithms & Integration) Real!* ********************************************************** This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

[odow]

Do you only want static windows binaries?

I meant, is your application distributed on Windows only, or do you also ship macOS and linux?

[jeffreydeankelly2]

Sorry, yes on Windows only.

…

On Wed, Mar 23, 2022 at 4:09 PM Oscar Dowson ***@***.***> wrote: Do you only want static windows binaries? I meant, is your application distributed on Windows only, or do you also ship macOS and linux? — Reply to this email directly, view it on GitHub <#777 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEH2DLMO5YQQ6LCXUU3VBN3ANANCNFSM5ROKXTVQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ********************************************************** *I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m a t i o n S m a r t e r"* Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: ***@***.*** Phone: (647) 917-4675 (IMPL) *Making Industrial AI (Algorithms & Integration) Real!* ********************************************************** This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

[odow]

hence the reason we deploy with the pre-compiled Windows binaries prepared by the other solvers.

How does this work if you deploy GPL solvers like GLPK? Our static build of HiGHS includes the GCC runtime which is GPL, so you wouldn't be able to redistribute it unless your application was also GPL.

[jeffreydeankelly2]

Is the GCC runtime licensed as LGPL (lesser)? This is the same issue with Microsoft's C++ redistributables and Intel Fortran's redistributables which are royalty-free. Even though these compilers are commercial their runtimes are not.

…

On Wed, Mar 23, 2022 at 5:41 PM Oscar Dowson ***@***.***> wrote: hence the reason we deploy with the pre-compiled Windows binaries prepared by the other solvers. How does this work if you deploy GPL solvers like GLPK? Our static build of HiGHS includes the GCC runtime which is GPL, so you wouldn't be able to redistribute it unless your application was also GPL. — Reply to this email directly, view it on GitHub <#777 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEDRAK6MUDEHFGLQLYLVBOFZTANCNFSM5ROKXTVQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ********************************************************** *I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m a t i o n S m a r t e r"* Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: ***@***.*** Phone: (647) 917-4675 (IMPL) *Making Industrial AI (Algorithms & Integration) Real!* ********************************************************** This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

[mmuetzel]

Re licensing: IIUC, the GCC Runtime Library Exception allows linking the runtime (including statically) to non-GPLed code:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

[mmuetzel]

Do you know if there is a way to link to the *.dll.a similar to a *.lib file?

The .dll.a file extension is often used by mingw toolchains on Windows to indicate "import libraries". Import libraries are used on Windows when dynamically linking to a library. It might be possible to link to the .dll.a just like you would link to a .lib file. But you'd need to supply the "actual" dynamic library (.dll file) when running your program.

Actual static libraries often use the .lib or .a file extension with a mingw toolchain. They differ from static shared libraries by the fact, that the actual code of the library will be part of your program (licenses must be compatible!).

MSVC toolchains don't have established file extensions that differ between import libraries and static libraries. They use .lib by default for both. So, it depends on what you'd like to do: If you'd like to dynamically link highs, use the .dll.a files just like you would use the import libraries (potentially ending with .lib if they were compiled with MSVC) of other projects.
But keep in mind that mixing libraries compiled with MSVC and mingw might be problematic. It might work ok (e.g., if the interface is limited to POD types, malloc-free isn't used across library borders, and ...).

Additionally, that means that a static library (.lib) should not replace the existing import library (.dll.a). Both are used in different cases. (Maybe the title could be changed to reflect that?)

[jeffreydeankelly2]

Hi Markus; Thank you for the clarity! Yes, the *.lib files I am referring to are the MSVC import libraries (*.lib) where the corresponding *.dll files are also supplied. What I am ultimately looking for are HiGHS binaries compiled using Microsoft Visual Studio to be compatible with our MSVC and Intel Fortran Windows development environment. All of the other community-based and commercial-based mathematical optimization solvers provide these MSVC import libraries so I assumed that HiGHS would provide these as well. My understanding is that only the MinGW binaries are available. All the best - Jeff

…

On Mon, Mar 28, 2022 at 4:52 AM Markus Mützel ***@***.***> wrote: Do you know if there is a way to link to the *.dll.a similar to a *.lib file? The .dll.a file extension is often used by mingw toolchains on Windows to indicate "import libraries". Import libraries are used on Windows when dynamically linking to a library. It might be possible to link to the .dll.a just like you would link to a .lib file. But you'd need to supply the "actual" dynamic library (.dll file) when running your program. Actual static libraries often use the .lib file extension with a mingw toolchain. They differ from static libraries by the fact, that the actual code of the library will be part of your program (licenses must be compatible!). MSVC toolchains don't have established file extensions that differ between import libraries and static libraries. They both use .lib by default for both. So, it depends on what you'd like to do: If you'd like to *dynamically* link highs, use the .dll.a files just like you would use the import libraries (potentially ending with .lib if they were compiled with MSVC) of other projects. But keep in mind that mixing libraries compiled with MSVC and mingw might be problematic. It might work ok (e.g., if the interface is limited to POD types, malloc-free isn't used across library borders, and ...). Additionally, that means that a static library (.lib) should *not* replace the existing import library (.dll.a). Both are used in different cases. (Maybe the title could be changed to reflect that?) — Reply to this email directly, view it on GitHub <#777 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEHZRCULFFTLS4E2UHLVCFXNJANCNFSM5ROKXTVQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ********************************************************** *I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m a t i o n S m a r t e r"* Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: ***@***.*** Phone: (647) 917-4675 (IMPL) *Making Industrial AI (Algorithms & Integration) Real!* ********************************************************** This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

[mmuetzel]

Thanks for clarifying.
Have you tested if you can link the (mingw) highs library with your (msvc) project? It might work. (But no guarantees it will.)

IIUC, your feature request is something like: "Distribute Windows binaries compiled with MSVC". Is that correct?

[jeffreydeankelly2]

Hi Markus; Unfortunately, no I have not / never tested using the *.dll.a file compiled by MinGW as an import library in MSVC. "Windows binaries compiled with MSVC". Is that correct? Yes, something like what is provided by COIN's IPOPT i.e., Ipopt-3.14.2-win64-msvs2019-md.zip. All the best - Jeff

…

On Mon, Mar 28, 2022 at 10:57 AM Markus Mützel ***@***.***> wrote: Thanks for clarifying. Have you tested if you can link the (mingw) highs library with your (msvc) project? It *might* work. (But no guarantees it will.) IIUC, your feature request is something like: "Distribute Windows binaries compiled with MSVC". Is that correct? — Reply to this email directly, view it on GitHub <#777 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHONEHYCXWIPKEWI6X2TKTVCHCFRANCNFSM5ROKXTVQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- ********************************************************** *I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m a t i o n S m a r t e r"* Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: ***@***.*** Phone: (647) 917-4675 (IMPL) *Making Industrial AI (Algorithms & Integration) Real!* ********************************************************** This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

[odow]

The current binaries are compiled primarily for HiGHS.jl in Julia and made available for wider use. Notably, they aren't maintained or distributed by the official HiGHS team, and we don't have the ability to use MSVC in our compilation infrastructure (https://github.com/JuliaPackaging/Yggdrasil), so it's unlikely that this will happen from my side.

You have the ability to compile HiGHS yourself, otherwise, @jajhall might be in a position to provide commercial support.

[jeffreydeankelly2]

This issue has been solved using the dll2lib.bat file which generates an import library *.LIB directly from the *.DLL.

The libhighs.lib was successfully created from the libhighs.dll and HiGHS has been interfaced to Intel oneAPI Fortran via Microsoft Studio 2019 with no issues.

---

Here is a website which hosts the MS DOS batch file to automatically generate the import library *.LIB using the Visual Studio ID dumpbin.exe, etc. utilities. This BAT file requires the path environment setup from a Microsoft Visual Studio IDE command prompt with administration priviliges.

https://rotadev.com/how-to-generate-an-import-library-lib-file-from-a-dll-dev/

REM Usage: dll2lib [32|64] some-file.dll
REM
REM Generates some-file.lib from some-file.dll, making an intermediate
REM some-file.def from the results of dumpbin /exports some-file.dll.
REM Currently must run without path on DLL.
REM (Fix by removing path when of lib_name for LIBRARY line below?)
REM
REM Requires 'dumpbin' and 'lib' in PATH - run from VS developer prompt.
REM
REM Script inspired by http://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll
SETLOCAL
if "%1"=="32" (set machine=x86) else (set machine=x64)
set dll_file=%2
set dll_file_no_ext=%dll_file:~0,-4%
set exports_file=%dll_file_no_ext%-exports.txt
set def_file=%dll_file_no_ext%.def
set lib_file=%dll_file_no_ext%.lib
set lib_name=%dll_file_no_ext%

dumpbin /exports %dll_file% > %exports_file%

echo LIBRARY %lib_name% > %def_file%
echo EXPORTS >> %def_file%
for /f "skip=19 tokens=1,4" %%A in (%exports_file%) do if NOT "%%B" == "" (echo %%B @%%A >> %def_file%)

lib /def:%def_file% /out:%lib_file% /machine:%machine%

REM Clean up temporary intermediate files
del %exports_file% %def_file% %dll_file_no_ext%.exp

---