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

FR: Support implicit linking with DLLs #3311

Closed
benvanik opened this Issue Jul 1, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@benvanik

benvanik commented Jul 1, 2017

Description of the problem / feature request / question:

Requesting the ability to access the .lib files for DLLs produced by link.exe from cc_binary rules and pass them to other cc_library/cc_binaries as dependencies.

Discussion here: https://groups.google.com/forum/#!topic/bazel-discuss/aLExoG4m5Us

If possible, provide a minimal example to reproduce the problem:

Extending https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll:

Add hello-world-implicit.cpp:

#include <stdio.h>
#include <windows.h>
__declspec(dllimport) char *get_time();
__declspec(dllimport) void say_hello(char *message);

int main() {
  char *now = get_time();
  say_hello(now);
  return 0;
}

And a build rule like:

cc_binary(
    name = "hello-implicit",
    srcs = [
        "hello-world-implicit.cpp",
    ],
    deps = [":hellolib.dll"],
)

Expect the following the link without unresolved symbols:

bazel build --cpu=x64_windows_msvc :hello_implicit

Currently since the lib is not passed on to the exe the linking will fail with unresolved symbols. Adding the dll as a dep also causes issues as it is passed to cl.exe as such:

external/local_config_cc/wrapper/bin/msvc_cl.bat ... -Lbazel-out/msvc_x64-dbg/bin/_solib_x64_windows/ hellolib.dll ...

This causes the msvc_tools.py ArgParser to emit the following warning:

Warning: Unmatched arguments: hellolib.dll

benvanik added a commit to google/xrtl that referenced this issue Jul 1, 2017

Swiftshader on Windows.
This is not directly usable until bazel supports implicit linking:
bazelbuild/bazel#3311

Until then, copying libEGL.lib and the dlls to random paths works.

benvanik added a commit to google/xrtl that referenced this issue Jul 2, 2017

Swiftshader on Windows.
This is not directly usable until bazel supports implicit linking:
bazelbuild/bazel#3311

Until then, copying libEGL.lib and the dlls to random paths works.

@mhlopko mhlopko self-assigned this Jul 3, 2017

@mhlopko mhlopko added this to the 0.6 milestone Jul 3, 2017

@mhlopko

This comment has been minimized.

Show comment
Hide comment
@mhlopko

mhlopko Jul 3, 2017

Contributor

Related to #1920

Contributor

mhlopko commented Jul 3, 2017

Related to #1920

@mhlopko mhlopko assigned mhlopko and meteorcloudy and unassigned mhlopko Jul 3, 2017

benvanik added a commit to google/xrtl that referenced this issue Jul 3, 2017

Swiftshader on Windows.
This is not directly usable until bazel supports implicit linking:
bazelbuild/bazel#3311

Until then, copying libEGL.lib and the dlls to random paths works.
@dslomov

This comment has been minimized.

Show comment
Hide comment
@dslomov

dslomov Jul 24, 2017

Contributor

@mhlopko @meteorcloudy feasible for 0.6? Is there any workaround?

Contributor

dslomov commented Jul 24, 2017

@mhlopko @meteorcloudy feasible for 0.6? Is there any workaround?

@meteorcloudy

This comment has been minimized.

Show comment
Hide comment
@meteorcloudy

meteorcloudy Aug 18, 2017

Member

I've wrote a doc about building dynamic library on Windows, please check out here:
https://docs.google.com/document/d/1ZK4f84wype5NsZ7ltOUqvyFr7eKOIf4Wd-DrU6HCBkA/edit

Member

meteorcloudy commented Aug 18, 2017

I've wrote a doc about building dynamic library on Windows, please check out here:
https://docs.google.com/document/d/1ZK4f84wype5NsZ7ltOUqvyFr7eKOIf4Wd-DrU6HCBkA/edit

@mhlopko mhlopko modified the milestones: 0.7, 0.6 Sep 13, 2017

bazel-io pushed a commit that referenced this issue Sep 18, 2017

Bazel now can build dynamic library from cc_library
Working towards: #3311

When building dynamic library on Windows, Bazel builds an import library
and a DLL.

Bazel provides a feature called windows_export_all_symbols, if this
feature is enabled(and no_windows_export_all_symbols is not) for a
cc_library, then Bazel parses object files of that cc_library to generate
a DEF file that will be used during linking time to export symbols from
DLL. This feature can be specified at crosstool, package, target and
command line level.

A few differences from Unix platforms:

1. We don't build the shared library on Windows by default, users have to
specifiy --output_groups=dynamic_library for building dynamic libraries.
This output group is also available on other platforms.

2. By default, cc_test is dynamically linked on Unix, but it will be
statically linked on Windows by default. (meaning the default value of
linkstatic in cc_test is 1 on Windows, and 0 on other platforms)

3. For global data symbols, __declspec(dllimport) must still be used in
source files.

Remaining issues:

1. Extensions for import library and DLL are not correct yet.
2. DLLs are not guaranteed to be available during runtime yet.
3. Diamond problem
If a cc_library A is specified as linkstatic=0, then no dynamic library
will be built for it, so if another cc_library B depends on it, A will
be statically linked into B, and if a cc_binary C depends on B, A will
also be statically linked into C and B will be dynamically linked to C.
This is wrong because A is duplicated in both B and C.
It is essentially a diamond problem describled in C++ Transitive Library.
(https://docs.google.com/document/d/1-tv0_79zGyBoDmaP_pYWaBVUwHUteLpAs90_rUl-VY8/edit?usp=sharing)
Hopefully, we can avoid this by using cc_shared_library rule in future.

Change-Id: I23640d4caf8afe65d60b1522af6368536d7a8408
PiperOrigin-RevId: 168829958

rahul-malik added a commit to pinterest/bazel that referenced this issue Sep 18, 2017

Bazel now can build dynamic library from cc_library
Working towards: bazelbuild#3311

When building dynamic library on Windows, Bazel builds an import library
and a DLL.

Bazel provides a feature called windows_export_all_symbols, if this
feature is enabled(and no_windows_export_all_symbols is not) for a
cc_library, then Bazel parses object files of that cc_library to generate
a DEF file that will be used during linking time to export symbols from
DLL. This feature can be specified at crosstool, package, target and
command line level.

A few differences from Unix platforms:

1. We don't build the shared library on Windows by default, users have to
specifiy --output_groups=dynamic_library for building dynamic libraries.
This output group is also available on other platforms.

2. By default, cc_test is dynamically linked on Unix, but it will be
statically linked on Windows by default. (meaning the default value of
linkstatic in cc_test is 1 on Windows, and 0 on other platforms)

3. For global data symbols, __declspec(dllimport) must still be used in
source files.

Remaining issues:

1. Extensions for import library and DLL are not correct yet.
2. DLLs are not guaranteed to be available during runtime yet.
3. Diamond problem
If a cc_library A is specified as linkstatic=0, then no dynamic library
will be built for it, so if another cc_library B depends on it, A will
be statically linked into B, and if a cc_binary C depends on B, A will
also be statically linked into C and B will be dynamically linked to C.
This is wrong because A is duplicated in both B and C.
It is essentially a diamond problem describled in C++ Transitive Library.
(https://docs.google.com/document/d/1-tv0_79zGyBoDmaP_pYWaBVUwHUteLpAs90_rUl-VY8/edit?usp=sharing)
Hopefully, we can avoid this by using cc_shared_library rule in future.

Change-Id: I23640d4caf8afe65d60b1522af6368536d7a8408
PiperOrigin-RevId: 168829958
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment