*.ldscript file will not propagate to the final step when linking

[chin33z]

cc_binary(
    name = "hello",
    srcs = ["main.c"],
    deps = [":lib"]  <----":lib.ldscript" to add here
)

cc_library(
    name = "lib",
    srcs = ["lib.c"],
    linkopts = ["-Wl,--version-script", ":lib.ldscript"],
    deps = [":lib.ldscript"],
)

Assume all files were placed & edited properly.

This will be fine :
$> bazel build //:lib

This will cause gcc error (lib.ldscript: No such file or directory) :
$> bazel build //:hello

However, if I add ":lib.ldscript" to the deps of "hello". I will not get the error.
But from encapsulated perspective, "hello" should not take care of this information.(The linker script is for "lib" only)

I guess this is because Bazel link all the objects/files in th last steps & the *.ldscript in deps is not propagated to the cc_binary(hello) when linking.

Is this a bug or WAD? Thanks.

[ulfjack]

It would help if you could show the libldscript rule. I think the most
likely reason is a file extension mismatch - we require linker scripts to
end with ".ld", ".lds", or ".ldscript".

On Tue, Dec 15, 2015 at 5:26 AM, David Hu notifications@github.com wrote:

cc_binary(
name = "hello",
srcs = ["mainc"],
deps = [":lib"] <----":libldscript" to add here
)

cc_library(
name = "lib",
srcs = ["libc"],
linkopts = ["-Wl,--version-script", ":libldscript"],
deps = [":libldscript"],
)

Assume all files were located properly

This will be fine :
$> bazel build //:lib

This will cause gcc error (libldscript: No such file or directory) :
$> bazel build //:hello

However, if I add ":libldscript" to the deps of "hello" I will not get
the error
But from modularized perspective, "hello" should not take care of this
information

I guess this is because Bazel link all the objects/files in th last steps
& the *ldscript in deps is not propagated to the cc_binary(hello) when
linking

Is this a bug or WAD? Thanks

—
Reply to this email directly or view it on GitHub
#716.

[chin33z]

lib.ldscript content:

{
  global: *;
};

I know the file extension requirement in deps (*.ld, *lds, *.ldscript).
And I think the problem is not the content of the linker script.

[ulfjack]

In the email I got, it said ":libldscript" not ":lib.ldscript". Well, it does sound like a bug.

[chin33z]

It does behave weird for me. I think the "-Wl,--version-script" argument should only present when linking the "lib". However, it shown up when "hello" is linked. Thus, the lib.ldscript is not in the sandbox at that moment.(I guess)

[burkpojken]

Hi!
Is it possible to push for this feature to be implemented earlier than 1.0??
Or even make it more generic to be able to add any type of target as a dependency (or e.g. tools = [":myLinkscript"]) that then can be used with $location in e.g. linkopts?

[hlopko]

CC @oquenchil

[cpsauer]

FWIW, I'm seeing this work correctly when used a little differently.

The specific case: I'm passing "-Wl,--version-script,$(location example.ldscript)" into a cc_library's linkopts, and seeing things get compiled correctly by an android_binary that indirectly depends on it.

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.