Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow -l option to ocamlmklib on MSVC ports #1189

Merged
merged 1 commit into from Aug 14, 2017

Conversation

Projects
None yet
2 participants
@dra27
Copy link
Contributor

commented Jun 4, 2017

In general (especially for the Windows API), -lfoo cannot be used to link libraries because the various drivers assume that libfoo.lib is meant. This patch allows ocamlmklib to mask this difference so that
-luser32 will refer to libuser32.a as normal on MinGW but user32.lib on MSVC.

The motivation for this is that ocamlmklib treats -l options differently from a manually specified library. So if you have a library requiring you to link against gdi32.lib and user32.lib, then you get various linker warnings when producing the static stubs library:

user32.lib(USER32.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in gdi32.lib(GDI32.dll); second definition ignored
user32.lib(USER32.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible

Though innocuous, these warnings are irritating and arise simply because a .lib file should not be linked with those libraries.

Allow -l option to ocamlmklib on MSVC ports
In general (especially for the Windows API), -lfoo cannot be used to
link libraries because the various drivers assume that libfoo.lib is
meant. This patch allows ocamlmklib to mask this difference so that
-luser32 will refer to libuser32.a as normal on MinGW but user32.lib on
MSVC.

@dra27 dra27 force-pushed the dra27:improve-msvc-link branch from 44244d4 to fc0bb84 Aug 12, 2017

@dra27

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2017

Rebased - I've marked the change as breaking as technically ocamlmklib is interpreting -l incompatibly with previous versions. While custom-compiled libraries may have chosen to name themselves libfoo.lib, it's never been possible to link with Windows API import libraries correctly.

Ready for merge - note that this complements the flexdll PR, they don't depend on each other.

@mshinwell mshinwell merged commit a032518 into ocaml:trunk Aug 14, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.