c/c++ (and Fortran!) libraries installation under $GOPATH/pkg

[Sebastien Binet]

hi there,

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

?

-s

0: https://code.google.com/p/go/issues/detail?id=5629
1: https://codereview.appspot.com/8248043/

[Ian Lance Taylor]

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? 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.

Ian

[Sebastien Binet]

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