linking with SDK stubs 1.12.3 links with libeos.so.1.12 but rpm cannot find it on the switch

Hi,

I am linking my application with SDK stubs 1.12.3 libeos.so library like this:
g++ test.cpp -leos -L.
ldd is showing me that my application is actually linked with libeos.so.1.12.
That is not a problem when trying to run my application on the switch as there is symbolic link with such name, but when I build an RPM packages containing my app it has a dependency to libeos.so.1.12 which is not found by RPM as something that was installed by other RPM package. As a result I get an error during installation of my package:

error: Failed dependencies:
        libeos.so.1.12 is needed by ...

When you check with rpm command which package provides that library it say no package:

-bash-4.3# rpm -q --whatprovides libeos.so.1.12
no package provides libeos.so.1.12

however if you check libeos.so.1 then it find EosSdk package correctly:

-bash-4.3# rpm -q --whatprovides libeos.so.1
EosSdk-1.12.3-5927901.4184F.i686

Either there is something wrong in building EOS SDK stubs libeos.so.1.12.3 library so it is causing application to link with libeos.so.1.12 instead of libeos.so.1 or there is something wrong with the installation of EosSdk on the switch (build 4.18.4) so rpm cannot find a package that provides libeos.so.1.12.

For now I can workaround this problem by installing my package with --nodeps option but it would be good if it was fixed.

Regards,
Hubert

[jpsenior]

I am also experiencing this problem on 4.18.3.1F and 4.18.4F.

[ruferp]

Your application should link against libeos.so.1.12, this is how we can prevent it to try to run on the wrong target and then experience crashes due to binary incompatibilities.
The application should not link against 1.12.3, because the "3" is the patch number, and different patch numbers are supposed to be binary compatible (no need to recompile the application).
If your application links against libeos.so.1, then we might run into strange crashes if you run it on a switch with a different minor version (the "12") than the one used when you built the application.
libtool is a tone deaf when it comes to semantic versioning, so it is possible something went wrong trying to make it grok semantic versioning, I will have to look into it...
And just for completeness on the semantic versioning idea: a change in major version number means the app code needs to be modified before it can be recompiled.

In the meantime, you can install the extension with the "force" option, as in:

  ol422#extension HelloWorld.i686.rpm
  % Error installing HelloWorld.i686.rpm: RPM install error: Transaction check failed: libeos.so.1.12 is needed by HelloWorld-1.0-0.i686

  ol422#extension HelloWorld.i686.rpm force
  ol422#

Or add this line to your rpm spec file header when building your application:

AutoReqProv: no

Thanks for the hints, I didn't know about the force option, I guess it is an equivalent for --nodeps. I decided to patch Makefile.am file so the soname of the stubs library matches with the soname of the real library on the switch and now I can install my package without --nodeps/force option. I have a dependency on EosSdk package too with specified version >= 1.12.3 to avoid problems when someone is trying to install my package on an old image. AutoReqProv seems like a workaround to the problem not a solution.
Stubs SDK SONAME:

objdump -p <path_to>libeos.so.1.12.3|grep SONAME
  SONAME               libeos.so.1.12

Real SDK SONAME:

-bash-4.3# ./objdump -p /lib/libeos.so.1.12.3 | grep SONAME
  SONAME               libeos.so.1

[jpsenior]

@hubertsokolowskintl We build our agents against EOS 1.8, 1.9, 1.10, and now 1.12.3. Only 1.12.3 output a dependency to libeos.so.1.12. All others just point to libeos.so.1.

I am noticing a difference when compiling using the Arista SDK stubs on the support site and the github source code. These are clearly differently sourced... Very confusing from Arista.

I am spending a lot of time trying to understand and account for these differences.

I agree that 'force', '--nodeps', or AutoReqPrev are not valid workarounds. The dependency is actually available - if we run 'ldd' on the resulting binaries I install on the system, they can clearly find libeos.so.1.12 - dependencies work fine. This seems to be a purely RPM installation issue.

[ruferp]

Yes, we made that change (link against libeos.so.. instead of libeos.so.) to prevent an EosSdk app that was compiled against a different (than the one installed) to run, since those errors ("cannot find lib blah") are more straightforward than crashes due to binary incompatibilities.

I diffed the github and the www.arista.com/en/support/software-download stubs too the other day. The differences are mainly white space and copyright year and differences in included example code, which is annoying indeed. Will check how those are generated since that is definitely confusing.

So far I could not find out why rpm is more catholic that the pope: if you force the install, ldd and the loader have no problem finding that supposedly missing library!
Note that the SONAME of the lib on the switch should not matter (only thing that matters is the name of the link so the loader can find it). The SONAME is used at compile time when building a binary (to set the NEEDED field of the binary). And just to make sure: changing the soname to 1.12 on the switch does not make rpm any less cranky when trying to install.
More digging required...

Note on using "version >= 1.12.3": that will not save you from crashing on a EOS that comes with EosSdk 1.13.1 (which given the bump in the version means a recompile is required or binary incompatibilities might crash the app).

Note also that using the "extension" cli command (with the "force" option) is better than installing the rpm from bash (using --nodeps), since those will be re-applied on bootup before anything else runs (provided cli "copy installed-extensions boot-extensions" was also run).

[jpsenior]

@ruferp This may also be related with Arista SR 91352 I filed this morning.

[ruferp]

The reason for the delta between "software-download-page" and "github" is that the github build failed (travis-ci), and the fix for all those travis-ci warning=failures has not yet made it into our code base. So what was pushed to github was simultaneously too early (version) and too late (all those white-space and other irrelevant changes).

I agree it is better to link with libeos.1.12 then with libeos.1.

I may be wrong but I think rpm dependencies are built based on the SONAME and if you change it in the real SDK when you build it so its SONAME matches with the one in the stubs SDK then the problem would be fixed.

I am aware that installing with rpm does not survive reboot. I am doing it just to test my application. Finally my application gets installed as an extension. I just prefer not to use --nodeps or force.

[ruferp]

The problem is that rpm does not know which RPM provides libeos.so.1.12.
It does know however which RPM owns/contains libeos.so.1.12.
In other words: rpm is schizophrenic. I guess whatever is not explicitly stated as "Provides:" will not be exported to the rpm db, and thus not found, even if it exists on the target system!
So if you change the soname to libeos.so.1 it will work, since that one is "provided" by somebody:

[admin@ol422 ~]$ rpm -q --provides EosSdk
EosSdk = 1.12.3-5927901.4184F
EosSdk(x86-32) = 1.12.3-5927901.4184F
EosSdk-mp
_eossdk.so
libeos.so.0
libeos.so.1 <===
[admin@ol422 ~]$

So use the "force" option, or change the soname of your stubbed libeos.so to libeos.so.1, or wait for a new EosSdk.i686.rpm that was built with a "Provides: libeos.so.1.12" (next EOS release I guess).

I understand your confusion.
In fact I am waiting for 4.19.1 release. It would be good if it is fixed there. For now I will workaround the problem by changing the soname of the stubbed library.

[ruferp]

I will be fixed in 4.19.1 (should be out by next week).

[jpsenior]

@ruferp Considering this is an RPM/SDK packaging issue, what is the high-level anticipated fix in 4.19.1 ? Are we getting another SDK version to build against?

[ruferp]

same SDK version, we changed EOS.swi (the libeos.so inside the swi had no soname previously, which works fine for linux's loader that looks at filenames only, but the rpm tools are a bit more cranky and pedantic about when an rpm provides something -- not simply because it contains the file).