Плагин Maven NAR: неверное имя связанной библиотеки

Я впервые использую плагин maven nar для компиляции отказов файлов corba IDL в C++. Я сгенерировал заглушки и скелеты с успехом, используя плагин exec и omniidl, и теперь у меня есть под src/ все файлы *.C и *.H.

Мы используем внутренний репозиторий Nexus для получения зависимостей NAR, и до сих пор мне удалось скомпилировать все файлы *.o. Тем не менее компоновщик завершается со следующим сообщением:

[INFO] 21 files were compiled.
[INFO] 21 files were compiled.
[INFO] Linking...
[INFO] Linking...
[INFO] Starting link {4.8 -shared -L/home/dev/repos/idl/cpp-idl/bin/nar/omniORB4-4.2.0-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lomniORB4-4.2.0-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/omnithread-4.2.0-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lomnithread-4.2.0-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/c-2.19-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lc-2.19-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/m-2.19-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lm-2.19-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/stdc__plus__plus-4.8.3+r212056-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lstdc__plus__plus-4.8.3+r212056-R1 -fexceptions -lstdc++}
[INFO] Starting link {4.8 -shared -L/home/dev/repos/idl/cpp-idl/bin/nar/omniORB4-4.2.0-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lomniORB4-4.2.0-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/omnithread-4.2.0-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lomnithread-4.2.0-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/c-2.19-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lc-2.19-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/m-2.19-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lm-2.19-R1 -L/home/dev/repos/idl/cpp-idl/bin/nar/stdc__plus__plus-4.8.3+r212056-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared -lstdc__plus__plus-4.8.3+r212056-R1 -fexceptions -lstdc++}
[ERROR] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lomniORB4-4.2.0-R1
[ERROR] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lomnithread-4.2.0-R1
[ERROR] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lc-2.19-R1
[ERROR] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lm-2.19-R1
[ERROR] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lstdc__plus__plus-4.8.3+r212056-R1
[ERROR] collect2: error: ld returned 1 exit status

Дело в том, что, например, папка

/home/dev/repos/idl/cpp-idl/bin/nar/omniORB4-4.2.0-R1-amd64-Linux-gpp-shared/lib/amd64-Linux-gpp/shared

содержит следующие общие объекты:

libomniORB4.so  libomniORB4.so.2  libomniORB4.so.2.0

и компоновщик пытается установить связь с именем библиотеки, содержащей полную версию (зависимая версия)

-lomniORB4-4.2.0-R1

Мои вопросы следующие:

  1. Могу ли я предположить, что зависимость omniORB4 NAR, доступная в нашем репозитории Nexus, который содержит общие объекты, содержит неправильные имена.so?
  2. Есть ли способ обойти это, сказав плагину NAR использовать разные имена библиотек для ссылки в разделе компоновщика?

Вот раздел pom, который настраивает плагин NAR:

 <build>
   <defaultGoal>install</defaultGoal>
   <plugins>
     <plugin>
       <groupId>com.github.maven-nar</groupId>
       <artifactId>nar-maven-plugin</artifactId>
       <configuration>
         <libraries>
           <library>
             <type>shared</type>
           </library>
         </libraries>
         <cpp>
           <name>g++</name>     
             <sourceDirectory>${project.basedir}/src</sourceDirectory>
             <options>
               <option>-g</option>
             </options>
           <includes>
             <include>**/*.C</include>
           </includes>
         <includePaths>
           <includePath>${project.basedir}/src</includePath>
         </includePaths>
       </cpp>
     </configuration>
   </plugin>
   ....

Благодарю.

Источник

3 ответа

Решение

Ошибка была в содержании NAR зависимости, которое было искажено.

Источник

Использовать libsName опция конфигурации в pom.xml вашей зависимости:

<configuration>
    <libsName>omniORB4</libsName>
    ...
</configuration>

libsName

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

Используйте запись CSV: lib1,lib2

Источник

Есть два способа упаковки сторонних библиотек в виде NAR.

Переименование библиотек в соответствии с соглашениями NAR

Первый — переименовать библиотеку, чтобы она соответствовала соглашениям плагина. Эти соглашения соответствуют именованию, используемому, если плагин должен был использоваться для создания библиотеки. Пример этой упаковки предоставляется в качестве одного из интеграционных тестов в проекте github. См.: Интеграционный тест it0020.

Поставка на заказ

При создании NAR плагин обычно генерирует файл, в котором есть некоторая, в настоящее время неполная, документация здесь NAR Dependencies. При публикации стороннего NAR можно предоставить файл настраиваемых свойств, который переопределяет имена библиотек для определенных AOL. Собственность:

      <aol>.output=<space separated list of library names>

Так, например:

      amd-Linux-gpp.output=fooapi foobasic

Приведет к тому, что строка ссылки linux для этой архитектуры будет содержать -lfooapiа также -lfoobasic.

Другие свойства из сгенерированной сборки должны быть скопированы, например, тип привязки библиотеки и то, как связаны nars.

В некоторых документах говорится, что этот файл невозможно переопределить, но следование обычным соглашениям maven для ресурсов позволяет заменить его. Размещение nar.propertiesфайл в src/main/resources/META-INF/nar/<groupId>/<artifact-name>внутри проекта создаст файл пользовательских свойств в библиотеке nar.

Источник
Другие вопросы по тегам