Can you link to a pre-compiled Go library without the source?

[Art Mellor]

Perhaps I am suffering from "C" brain, but I'm wondering if it is possible to distribute a pre-compiled Go library to be used without having access to the source.

In the C world I can link to a binary-only library via including the header file to define the data structs and funcs I will access in my main.

My initial foray into Go would indicate that I need to source package to know the necessary info to use a pre-compiled library.

I feel like I may be missing something obvious, but I *am* missing it if it is there.

How would I distribute a pre-compiled Go library for use elsewhere without also distributing the source?

Thanks in advance for any insight into this.

- Art

[Rodrigo Kochenburger]

All the compiled libraries live on the $GOPATH/pkg folder, they are *.a files. You could distribute those and link the application against those. In terms of documentation, you'd have to provide a separate documentation that can easily be generated using the godoc tool.

- RK

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dave Cheney]

The short answer is No.

The longer answer is this is not a limitation of Go itself, or its
implementations, but the cmd/go build tool which requires the source
to be present to determine if any dependencies need to be rebuilt.

This issue is tracked in
https://code.google.com/p/go/issues/detail?id=2775, and there is a
workaround provided in one of the comments.

[Rodrigo Kochenburger]

Go definitely is designed around the open source world that we live today, so it's easier to work with open source projects or if it's a internal project with limited access to the source code. Distributing compiled libraries is probably something most Go devs (and users) end up not needing.

This is a little off topic but releasing as open source with a proper licensing might be way more healthy to your project now adays :)

- RK

[Art Mellor]

Thanks. So (and this is probably what I'm missing) is the necessary info needed by 'import "foo"' in the compiled library rather than in the source? I.e. data structures will appear to be defined and function call sigs will be known, etc.? My mental model of 'import' has largely been that it was like a C 'include', but I'm now thinking that is very wrong.

[Rob Pike]

A slightly less short answer is, "Yes, if you write a Makefile".

-rob

[minux]

a workaround has been given many times on this list. you will need to provide a dummy source file

for the package (just the correct package statement suffices), and then make sure the timestamp of

the go archive (*.a) is newer than the dummy source file.

One limitation is that this way won't handle packages that rely on cgo and contain C++ source files.

[Ian Lance Taylor]

On Thu, Dec 19, 2013 at 1:16 PM, Art Mellor <art.ze...@gmail.com> wrote:
>
> Thanks. So (and this is probably what I'm missing) is the necessary info
> needed by 'import "foo"' in the compiled library rather than in the source?

Yes.

> I.e. data structures will appear to be defined and function call sigs will
> be known, etc.?

Yes.

> My mental model of 'import' has largely been that it was
> like a C 'include', but I'm now thinking that is very wrong.

A C/C++ #include involves reparsing the header file each time it is
included. Go does not work that way.

Ian

[Art Mellor]

Thanks all, my brain has been debugged (at least for this issue).

[Aram Hăvărneanu]

Please note that the archive binary format is not stable, not even
between minor revisions. The archive needs to be compiled with the
*exact* same compiler used by your consumers.

--
Aram Hăvărneanu

[Kevin Gillette]

That's admittedly not a hard workaround to achieve, assuming a non-cgo package.