> I assume that the recompile fails because compiling the C code fails.
You should compile the C code yourself, producing a .syso file. You
should add that .syso file to your package directory. You should
remove the C code from your package directory--you can still put it in
a subdirectory, of course, for reference. Then a Go program can
import your package, compile the Go code as usual, and use the .syso
file for the C code. Hopefully that won't be any more painful than
the approach you are using today, although it is different.
This is not an option.
> The reason for the change is that binary packages are hard to support
correctly. There are many ways to modify how Go code is compiled,
with options like -buildmode and -gcflags. If those options do not
match exactly how the binary package was built, it's easy for there to
be a silent error in the resulting program. That is not a good
experience.
The only thing that changes in our situation is the location of dynamic
libraries. Is there any way to specify at installation time where packages
should look for resources? Or what options to use when importing the package?
Something like...
go get -L /opt/foo/lib -I /opt/foo/include -Wl,-rpath=/opt/foo/lib
github.com/some/gofoo
And then Go would know to add those options whenever it needs to compile the
package?
--
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.
For more options, visit https://groups.google.com/d/optout.
