2011/8/5 Andrea Di Pasquale <[email protected]>: > 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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
