[Mono-list] multiple dll mappings in library dllmap

[Chris Morgan]

On Mon, Feb 13, 2012 at 1:01 PM, Doug Blank <doug.blank at gmail.com> wrote:
> On Sun, Jan 29, 2012 at 12:32 PM, Chris Morgan <chmorgan at gmail.com> wrote:
>> Hello.
>>
>> I'm trying to dll map libpcap for the SharpPcap.dll.config file. The
>> difficulty is that different distros have different dll names:
>>
>> ubuntu has libpcap.so.0.8 and libpcap.so.1.1.1, fedora appears to have
>> libpcap.so.1 and libpcap.so.1.2.1.
>>
>> The documentation for dll mapping,
>> http://www.mono-project.com/Config_DllMap, doesn't seem to indicate
>> that multiple names are supported and testing with multiple dllmap
>> entries shows that the last entry takes effect.
>>
>> I also tried using a wildcard like '*' but that doesn't seem to work either.
>>
>> Any ideas on how I might be able to map to all three of these dll
>> versions so I can maintain compatibility with multiple distributions?
>
> Arguably, the OS should have sim links from  libpcap.so  to
> libpcap.so.1. If not, surely that must be breaking some Linux standard
> rules.
>

There are rules. The Debian packager isn't going to change the
packages though because technically the abi hasn't changed since
libpcap 0.8. See this bug report that I filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657900 Now I could be
confused and wrong and I'd like to know why. It just seems pretty dumb
to me that Fedora and OpenSUSE have the library symlink and name that
matches what the libpcap guys ship, but the Debian guy won't even
create the extra symlink just to match them. I can understand not
wanting to require all users of libpcap to re-link but its a little
frustrating that he won't add the symlink to make things look the
same.



> Can you create your own links to the correct files? That might require
> a config script, but that is probably the "correct" way to handle the
> problem.
>

It would be a huge pain. Users now just download the library, add it
as a reference in their project and go. Adding a config script that
would require root access to modify their filesystem would be a pain.
Or are you suggesting symlinks in the local directory? Its still a
pain since they would have to ship with that script and run it before
the user could run their app less the pinvokes would fail.

So far I haven't found a reasonable solution.

Chris