Ian Lance Taylor <i...@golang.org> schreef op 19 december 2018 23:27:13 CET: > On Wed, Dec 19, 2018 at 2:15 PM Peter Kleiweg <pklei...@xs4all.nl> > wrote: > > > > > 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. > > If you were able to use Go binary packages, then I don't understand > why this is not an option. The Go binary package must have included > compiled versions of the C code.
They do not. They have Go code and C code. They are installed with go get. Then I add a file to the package source code that marks it as binary package. After any upgrade of Go or the package, I remove the binary marker, and repeat the procedure. > Perhaps I completely misunderstand > what you want to do. I want to provide packages in a environment where not all resources are available in a standard location (because of access restrictions in the organisation), packages that can only be installed with options relevant to that environment. I want multiple users to be able to import those package without them having to worry about environment settings. In practice, this mostly means including into the final program the path to some C libraries (rpath). Also in our set-up, the command 'go' is a wrapper script that adds a non-standard location to the end of GOPATH. > > > > 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? > > If I understand you correctly, you can do this by setting the > CGO_CFLAGS and CGO_LDFLAGS environment variables when you run `go > get`. Yes, that used to work for older versions of Go. It doesn't work since Go a few versions back. Now building any program that imports the package, directly or indirectly, needs to set those same CGO_CFLAGS and CGO_LDFLAGS environment variables. -- Peter Kleiweg http://pkleiweg.home.xs4all.nl -- 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.
