Red Hat Bugzilla – Bug 133389
RFE: add __soext macro
Last modified: 2007-11-30 17:10:49 EST
Description of problem: Not all platforms have .so as the dynamic library suffix. For instance, Mac OS X and Darwin uses .dylib instead... Here is a macro to help with writing portable spec files: %ifnos darwin %define __soext so %else %define __soext dylib %endif But it would be better if I didn't have to add this macro to all of my own specfiles (or in any custom .rpmmacros) ? Another problem is the versioning, but there there is no choice but to modify the specfile %files with %ifos tags: %ifnos darwin %{_libdir}/libz.%{__soext}.* %else %{_libdir}/libz.*.%{__soext} %endif Darwin has the version inbetween the library and the suffix, which makes it possible to specify which version to link to. But it also makes constructs like "*.so" to match the developer libraries only fail, since it will match all library versions... To make matters worse, some of the things such as perl or python modules are not dynamic libraries but loadable bundles, so they use a .bundle suffix instead... But that is a whole other story.
Something like this is needed, and not only for mac os x; both hpux and aix have other than *.so markers for shared libraries iirc. I'd probably go with the shorter %{so} if/when the time comes. Note: current restrictions on macro definitions prevent defining 2 character macros iirc, that is intentional ;-)
I thought a cool feature would be to have a %{__sover} macro (or something), that would expand to versioned libraries ext: %ifnos darwin %define __sover %{__soext}.* %else %define __sover *.%{__soext} %endif But one still needs to change the spec files from the current *.so, to listing both libfoo.%{__soext} and libbar.%{__soext} Since otherwise the wild card matches the runtime libraries too, not only the developer library symlinks (like it does on Linux)
This is added as the macro %__so since (at least) rpm-4.4.2.