символы из статической зависимости cc_library отсутствуют

Как я могу сказать bazel связать предварительно скомпилированную (статическую) библиотеку?

Я сослался на существующий проект статической библиотеки (xy.BUILD):

cc_library(
  name="xy",
  srcs=["lib/x86_64/libxy.a"],
    hdrs=["include/xy.h"],
  includes=["include"],
  #linkstatic=True,                          <---- *1
  #alwayslink=True,
  visibility=["//visibility:public"],
)

Внутри другого проекта (СТРОЙКА):

cc_library(
  name="myxylib",
  hdrs=["myxylib.h"],
  srcs=["myxylib.c"], 
  visibility=["//visibility:public"],
  deps=["@xy//:xy"],
  linkopts = ["-pthread", 
            #"-Lexternal/xy/lib/x86_64/",    <---- *2
            #"-lxy", 
            #"-z defs"
  ],

)

... как внешняя зависимость (new_local_repository в WORKSPACE). Я могу использовать файлы заголовков и скомпилировать код как библиотеку .so, но символы из статической библиотеки отсутствуют внутри общего объекта, потому что bazel не устанавливает флаги -L и -l (см. комментарии *2) автоматически для зависимость. Есть ли способ заставить базель сделать это автоматически? Я уже пробовал параметры в комментарии *1, но это не помогает.

Мне очень неудобно устанавливать флаги -L и -l вручную, потому что мне придется поддерживать разные архитектуры, и я предпочел бы устанавливать пути для зависимых от архитектуры разных библиотек только один, а не повторять его в каждом унаследованном артефакте.


bazel
person Jan    schedule 29.09.2015    source источник
comment
Вы получаете сообщение об ошибке при связывании или пытаетесь распространять автономную библиотеку?   -  person kristina    schedule 30.09.2015
comment
Я не получаю никаких ошибок во время сборки, но я хочу, чтобы символы из статической библиотеки (xy) были включены в myxylib. Это работает, если я добавляю -Lexternal/xy/x86_64 -lxy к linkopts, но, поскольку пути зависят от платформы, я бы предпочел иметь какой-либо флаг bazel или что-то подобное, чтобы bazel автоматически добавлял это на основе информации о зависимости, которая у него уже есть. Расположение файла libxy.a уже указано в параметре srcs cc_library(xy), поэтому мне не нужно повторяться в определении cc_library(myxylib)   -  person Jan    schedule 01.10.2015

Ответы (3)


arrow_upward
4
arrow_downward

Использование cc_binary вместо cc_library с измененными параметрами ссылок (-shared) и name("lib myxylib .so"):

cc_binary(
  name="libmyxy.so",
  hdrs=["myxylib.h"],
  srcs=["myxylib.c"], 
  visibility=["//visibility:public"],
  deps=["@xy//:xy"],
  linkopts = ["-shared"],
)

... кажется полезным в качестве обходного пути, если кто-то доволен тем, что все связано с двоичным файлом без особого контроля. Это также включает привязку версии clib.

person Jan    schedule 05.10.2015

arrow_upward
3
arrow_downward

cc_library не связывает свои зависимости, пока не будет объединен в cc_binary (все будет связано с cc_binary без необходимости указывать это).

Не существует элегантного способа заставить его связать все в cc_library. Вы можете использовать genrule с $location, поэтому вам не нужно указывать специфическая архитектура. Или не стесняйтесь запросить функцию, если вы хотели бы, чтобы мы добавили ее.

person kristina    schedule 01.10.2015
comment
Спасибо за информацию, я отправил запрос функции (github.com/bazelbuild/bazel/issues/ 492). А пока попробую с genrule и $location - person Jan; 02.10.2015

arrow_upward
1
arrow_downward

Как упоминает Ян, вы можете использовать cc_binary() для создания библиотеки. Вы должны использовать атрибут linkshared=1, чтобы Bazel выдавал правильные флаги для создания DSO.

person Han-Wen Nienhuys    schedule 06.10.2015