ebuild installs /usr/lib/libiniparser.a /usr/lib/libiniparser.so.0 but usually there should be something like: /usr/lib/libiniparser.a /usr/lib/libiniparser.so -> libiniparser.so.0.X.X /usr/lib/libiniparser.so.0 -> libiniparser.so.0.X.X /usr/lib/libiniparser.so.0.X.X (maybe .0.3.0 ?) Reproducible: Always Steps to Reproduce: 1. emerge iniparser Actual Results: /usr/lib/libiniparser.a /usr/lib/libiniparser.so.0 Expected Results: /usr/lib/libiniparser.a /usr/lib/libiniparser.so -> libiniparser.so.0.X.X /usr/lib/libiniparser.so.0 -> libiniparser.so.0.X.X /usr/lib/libiniparser.so.0.X.X (maybe .0.3.0 ?)
This is a convention, not a requirement. Nowadays it's good practice to keep a global version symbol in the library. Assigning never the lass, just in case...
(In reply to comment #1) > This is a convention, not a requirement. Nowadays it's good practice to keep a > global version symbol in the library. > > Assigning never the lass, just in case... > I know that this is not a _real_ requirement, but a very useful convention. I don't know much about how to set/use a 'global version symbol' in a dynamic library, but if I compile a program which tries to dynamically link against libiniparser I usually use a gcc-option like '-liniparser'. So what happens here is that gcc searches for libiniparser.so, which is apparently not available, then it simply takes the static libiniparser.a _without_ any warn message and that's it, not really what I wanted to achieve.
Done without rev.bump.
