Ian,
On Thu, Jun 6, 2013 at 7:35 PM, Ian Lance Taylor <
ia...@golang.org> wrote:
> On Thu, Jun 6, 2013 at 2:41 AM, Sebastien Binet <
seb....@gmail.com> wrote:
>>
>> while waiting for issue[0] 5629 to be fixed and until go-1.2 is
>> released (so one gets [1]), I was wondering whether there was a
>> consensus where to install .so and/or .a C/C++ libraries under $GOPATH
>> ?
>>
>> I see shared libraries created through go-get+swig are installed under:
>> $GOPATH/pkg/$GOOS_$GOARCH/swig
>>
>> should I just piggy back on this and install my own Makefile-based
>> libraries under this location ?
>> or rather, install them under, say:
>> $GOPATH/pkg/$GOOS_$GOARCH/lib
>>
>> ?
>
> Now that we have external linking, I hope that the SWIG shared
> libraries can go away. So I don't think we should put other shared
> libraries in a swig directory.
>
> That said, I don't understand why you want to install shard libraries
> at all. The go tool won't build them. Are you talking about shared
> libraries that are part of, and distributed with, a Go package?
yes.
that's exactly my use case.
(also, I don't think the go tool will ever -nor should it ?- compile
Fortran libraries :P)
> I guess I don't know whether those should be installed or not. We could
> copy them to a lib directory, but because of name conflicts we would
> have to put them in a package specific subdirectory. I don't think it
> would work to give them package specific names because we would not be
> able to recreate any existing DT_NEEDED/DT_SONAME relationships. So
> perhaps we should just leave them in the package source directory and
> arrange to pass appropriate -rpath options to the external linker.
that has been my solution, except that, for packaging reasons, I
preferred not to leave the library under the source directory.
I'll heed your advice and install the library under:
$GOPATH/pkg/$GOOS_$GOARCH
<pkg-import-path>/_lib
(so limited conflict with go namespace should arise)
-s