Hi all
Thanks for the reply.
A good news, it seem that this isn't a problem now.
I just download the other libtorrent -- libtorrent-
rasterbar-0.14.4.tar.gz,
after compile it, I saw it generate a library named libtorrent-
rasterbar.so
In its compile options, I saw this define: -DPACKAGE_NAME=\"libtorrent-
rasterbar\"
also the include directory it exported is named "libtorrent", while
our libtorrent's
include directory named "torrent".
That means there is not any conflict between both "libtorrent" now.
When we try to port libtorrent-rasterbar later, we can give it an other
package name : SUNWlibtorrent-rasterbar.
Thanks
- Alex
On Jun 4, 2009, at 8:36 PM, James Carlson wrote:
> Andras Barna writes:
>> yeap
>> they have libtorrent-rasterbar.so for libtorrent-rastebar
>> and for rakshasa's simply libtorrent. so we can go this way too (if
>> noone has other idea(s))
>
> If the library isn't really well-accepted in the open source community
> (i.e., it has just one consumer *and* there's an alternative that has
> many consumers), then making it a static library makes a lot more
> sense to me. That way, you don't have to deal with either the package
> naming or the /usr/lib real estate issues.
>
> You can always break it back apart later and deliver it as a dynamic
> library if you find that someone else needs it.
>
> --
> James Carlson, Solaris Networking <james.d.carlson at sun.com
> >
> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442
> 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442
> 1677
