On Sat, Nov 27, 2021 at 3:53 PM David Karr <davidmichaelk...@gmail.com> wrote:
>
> On Saturday, November 27, 2021 at 1:13:12 PM UTC-8 David Karr wrote:
>>
>> On Sat, Nov 27, 2021 at 11:57 AM Ian Lance Taylor <ia...@golang.org> wrote:
>>>
>>> On Sat, Nov 27, 2021 at 11:01 AM David Karr <davidmic...@gmail.com> wrote:
>>> >
>>> > I'm aware of the "build constraints" mechanism, which lets individual
>>> > files be only compiled on specific oses or architectures.
>>> >
>>> > I am constructing an app that has a single cgo module, which is the
>>> > "meat" of the application (longest module). In my poc, the cgo header
>>> > specifies a lib path with "linux" in the path, to point to the linux
>>> > libraries. I haven't constructed a Makefile for this yet, but this works
>>> > well with vscode and simple testing.
>>> >
>>> > I now have to consider how to build this on Windows, although the
>>> > deployment target for this will be Linux. I have to allow for testing of
>>> > it on Windows, if possible. I thought perhaps that I could change the lib
>>> > path in the cgo header to reference "${GOOS}" instead, but it doesn't
>>> > seem to recognize that.
>>> >
>>> > It's not reasonable to use build constraints for this, because it seems
>>> > like I would have to duplicate the entire module in order to vary the lib
>>> > path. That would be absurd.
>>> >
>>> > What are reasonable strategies for this, including facilitating testing
>>> > of it in vscode on both Linux and Windows?
>>>
>>> If I'm reading this correctly, you can address this by using
>>> GOOS/GOARCH build tags in your #cgo comments. See, for example,
>>> https://go.dev/src/runtime/cgo/cgo.go?#L14. This is documented at
>>> https://pkg.go.dev/cmd/cgo#hdr-Using_cgo_with_the_go_command.
>>>
>>> Ian
>>
>>
>> So you're saying I could do this:
>>
>> // #cgo linux LDFLAGS: -L${SRCDIR}/../lib/linux -llib1 -llib2 -llib3
>> -llib4
>> // #cgo windows LDFLAGS: -L${SRCDIR}/../lib/windows -llib1 -llib2 -llib3
>> -llib4
>>
>> If so, that would be much better than duplicating the entire file. It looks
>> a little odd to duplicate the library list, but if that's the best we can
>> do, I guess that's it.
>>
>> I'll test this later.
>
>
> Hm, I'm going to guess you're going to tell me that I can't quite do that, as
> I just verified that, unless I'm simply doing it wrong. I wrote almost
> exactly what I showed there. I'm having some trouble figuring out how to set
> up the C compiler on Windows, but I have verified with other applications
> that I can cross-compile a build on Linux for Windows, so I simply ran this:
>
> GOOS=windows go build -o target/dist/windows-amd64
>
> This fails with:
>
> imports voltagems/voltagefuncs: build constraints exclude all Go files in
> /home/dk068x/git/voltagego/voltagefuncs
>
> Any way to fix this?
Here you are cross-compiling from Linux to Windows. With Go that is
easy but when using cgo it requires a Linux -> Windows C
cross-compiler in order to compile the parts of the program that are
written in C. If you have such a cross-compiler installed, you can
make this work by writing
GOOS=windows CC=linux-to-windows-cc CGO_ENABLED=1 go build ...
Ian
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUFTi3_zLhQ4ro0VJ3dtm10CvBe2f2CmWx52%2BTrgnO%2BzA%40mail.gmail.com.
