Conditionally specifying link libraries in cgo

[SteveD]

Currently pseudo-comments can be used to specify this on a per-platform basis (e.g. //#cgo linux LDFLAGS: -llua5.1) but sometimes this isn't specific enough.

Even when working just with Linux, we hit the problem that nobody agrees how to name libraries. 'lua5.1' is fine on Debian/Ubuntu, but Fedora does things differently, and so forth.

Any strategies I can use to solve this problem while using the standard Go build machinery?

steve d.

[André Moraes]

Maybe build tags could help, selecting the right file for ubuntu/fedora

* http://golang.org/cmd/go/#Compile_packages_and_dependencies
* http://golang.org/pkg/go/build/

--
André Moraes
http://amoraes.info

[SteveD]

On Tuesday, December 11, 2012 12:23:44 PM UTC+2, André Moraes wrote:

Maybe build tags could help, selecting the right file for ubuntu/fedora

Thank you, that is most interesting. In particular, the -tags parameter for build etc does the trick. It isn't clear from the cgo documentation that it applies, but it does.

So now I have this (the wandering include directory problem is solved by including the headers in the package source)

// #cgo CFLAGS: -Ilua
// #cgo llua LDFLAGS: -llua
// #cgo darwin LDFLAGS: -llua
// #cgo freebsd LDFLAGS: -llua
// #cgo linux LDFLAGS: -llua5.1

And indeed if I say 'go build -tags 'llua' ....' on Debian, we get the appropriate error message 'cannot find -llua'.

So for non-Debian Linux users,an explicit -tags 'llua' solves the problem.

However, I can't see any options for auto-detecting this condition.  One can use pkg-config, but again the name is 'lua5.1' on Debian, and so forth ;)

steve d.

[André Moraes]

> However, I can't see any options for auto-detecting this condition. One can
> use pkg-config, but again the name is 'lua5.1' on Debian, and so forth ;)

Read the "Build Constraints" section here:
http://golang.org/pkg/go/build/#pkg-overview

[SteveD]

On Tuesday, December 11, 2012 5:35:56 PM UTC+2, André Moraes wrote

Read the "Build Constraints" section here:
http://golang.org/pkg/go/build/#pkg-overview

That gets us closer.  Once I actually tested on a Fedora machine,  I needed to do this (ignoring other platforms for a moment)

// #cgo llua LDFLAGS: -llua 

// #cgo linux,!llua LDFLAGS: -llua5.1 

That is, the section on +build directives is applicable to cgo directives.

(So a 'go get' should work fine, if the person adds -tags 'llua')

But I cannot see any way to make these fine distinctions between variants of a single platform without actively probing the environment in some way.

(As for Windows, well that always was a very special case anyway)

steve d.

[André Moraes]

> That gets us closer. Once I actually tested on a Fedora machine, I needed
> to do this (ignoring other platforms for a moment)
>
> // #cgo llua LDFLAGS: -llua
> // #cgo linux,!llua LDFLAGS: -llua5.1
>
> That is, the section on +build directives is applicable to cgo directives.
>
> (So a 'go get' should work fine, if the person adds -tags 'llua')
>
> But I cannot see any way to make these fine distinctions between variants of
> a single platform without actively probing the environment in some way.

I think you will not be able to do that, without user intervention.

I don't know pkg-config a lot, but if you request a library and that
library isn't installed in the system, it should return an empty
string.

So, maybe, you could just use pkg-config and request both libs (llua
and lua5.1) and let pkg-config find the right one to use.

[SteveD]

On Wednesday, December 12, 2012 12:37:12 PM UTC+2, André Moraes wrote:

I don't know pkg-config a lot, but if you request a library and that
library isn't installed in the system, it should return an empty
string.

Alas, but pkg-config is not universal.  Especially when we consider the difficulties with Windows, it's inevitable that some user intervention will be needed (there are no standard places for libraries).