[csw-maintainers] Issues with libdnet

[Maciej Bliziński]

2011/8/5 Andrea Di Pasquale <spikey.it at gmail.com>:
> sorry but soft link is a bad solution. :\

It's exactly the same solution as renaming /opt/csw/lib/libdnet to
/opt/csw/lib/libdnet.so; if you look at it, /opt/csw/libdnet is a
symlink.

Here is the pkgmap entry:

1 s none /opt/csw/lib/sparcv9/libdnet=libdnet.1.0.1

The "s" stands for symlink. I thought that if you accept the renaming
solution, you'd also accept creating a similar symlink in another
place. That would cause the wrong soname (libdnet.1) to be used in the
compiled binaries, but I guess it's a tangential problem for porting.
You could work on your port without waiting for the libdnet fix.

> I can't to do the port of ArpON for Solaris for libdnet problem, I'm sorry.

The progress so far looks like this: I've created an issue in the
libdnet bug tracker[2]. I also investigated the scenario described in
Debian docs[4], but regenerating all the autotools files did not help
with the issue. I've committed my patches anyway[3] and also submitted
them upstream for inclusion[5]. I still don't know what's the core
cause of this issue, I think that it's likely a problem with libtool,
but I haven't been able to pinpoint it. I've also contacted one of the
committers to see if the project is alive; the last commits are from
October 2010.  I heard that the primary developer is currently heavily
occupied with other projects, so we can't expect a quick response from
the upstream and sadly, we're on our own.

Maciej

[1] http://buildfarm.opencsw.org/pkgdb/srv4/c3becaf3633bfdbc0f315b73bc1d798c/
[2] http://code.google.com/p/libdnet/issues/detail?id=18
[3] http://sourceforge.net/apps/trac/gar/changeset/15258
[4] http://www.v7w.com/debian/libtool-missing_so.html
[5] http://code.google.com/p/libdnet/issues/detail?id=22