Maven NAR plugin: wrong linked library name

Question

I'm using for the first time the maven nar plugin to compile a bounce of corba IDL files in C++. I have generated the stubs and skeletons with success by using the exec plugin and omniidl and now I have under src/ all the *.C and *.H files.

We are using an internal Nexus repository to retrieve the NAR dependencies and so far I managed to compile all the *.o files. However, the linker fails with the following message:

[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

The thing is that for instance the folder

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

contains the following shared objects:

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

and the linker tries to link against the library name containing the full version (the dependency version)

-lomniORB4-4.2.0-R1

My questions are the following:

1. Can I assume that the omniORB4 NAR dependency made available in our Nexus repository which contains the shared objects, contains wrong .so names?
2. Is there a way to workaround it by telling the NAR plugin to use different library names to link against, in the linker section?

Here is the pom section which configures the NAR plugin:

 <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>
   ....

Thanks.

Answer 1

There are two ways to approach the packaging of third-party libraries as NAR.

Renaming libraries to match NAR conventions

The first is to rename the library to match the conventions of the plugin. These conventions match the naming used if the plugin were to be used to build the library. An example of this packaging is provided as one of the integration tests in the github project. See: Integration-test it0020

Supplying a custom nar.properties

When building the NAR the plugin normally generates a nar.properties file which has some, currently incomplete, documentation here NAR Dependencies. When publishing the third-party NAR it is possible to provide a custom properties file that overrides the library names for specific AOLs. The property is:

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

So for example:

amd-Linux-gpp.output=fooapi foobasic

Would cause the linux link line for this architecture to contain -lfooapi and -lfoobasic.

The other properties, from the generated build should be copied over such as the type of library binding and how the nars are linked.

Some documentation says that it is not possible to override this file, but following the normal maven conventions for resources allows it to be replaced. Placing a nar.properties file in src/main/resources/META-INF/nar/<groupId>/<artifact-name> within the project will build a custom properties file into the library nar.

Answer 2

Use the libsName configuration option in your dependency's pom.xml:

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

libsName

This tag is use to list multiple libs to be included into the linker. This is really usefull when packaging 3rd party libraries.

Use the CSV notation: lib1,lib2

Answer 3

The error was in the dependency NAR content which was malformed.