ohh, then you can look into *windres* which comes with mingw. It can create a C object file (from a .rc file that then references the manifest) which you then should be able to link into using the apporiate flags through cgo
On Friday, 18 September 2020 at 6:19:02 am UTC+8 aro...@gmail.com wrote: > Thanks! I'll look more into that. Unfortunately, we're not building on a > windows machine. :-( Might still be able to make something work, though. > > On Thursday, September 17, 2020 at 9:26:25 AM UTC-6 Alex wrote: > >> Yeah looks like *mt.exe* would be the most painless method assuming it >> works. >> >> On Thursday, 17 September 2020 at 11:14:36 pm UTC+8 aro...@gmail.com >> wrote: >> >>> Thanks for the reply. Yes, I want to override the manifest for a >>> particular build of the binary. >>> >>> I have two modules: >>> 1. foo.com/repo1 which contains foo.com/repo1/cmd/the-binary >>> 2. foo.com/repo2 which will build and package the-binary with specific >>> version and manifest information. I'd like to generate a resource.syso file >>> in repo2 while building foo.com/repo1/cmd/the-binary. >>> >>> For various unfortunate reasons, repo1 cannot have a checked-in >>> resource.syso file that is consistent. It's possible that repo2 will want >>> to build with multiple distinct syso manifests during a single build. >>> >>> We can override version information in the binary itself using `*-ldflags >>> "-X main.version=$(VERSION)"*` in repo2, but I can't figure out a way >>> to do the same with the manifest contents. >>> >>> Existing workarounds are: >>> 1. We duplicate the main package in repo2, so that >>> foo.com/repo2/cmd/the-binary basically defers to >>> foo.com/repo1/cmd/the-binary/restOfMain. Then we can build the repo2 >>> main package. This is annoying but works. Unfortunately, it means potential >>> deviation from repo1 binaries. >>> 2. We modify foo.com/repo1/cmd/the-binary in the go mod cache, >>> overwriting the resource.syso file for each build. Nobody like making the >>> mod cache rw. >>> >>> I was hoping for some equivalent of the ldflags symbol modification for >>> the resource.syso file. >>> >>> On Tuesday, September 15, 2020 at 3:27:26 PM UTC-6 Alex wrote: >>> >>>> > Is there a way to force the go linker to include the local manifest >>>> file? >>>> A syso file *is* the way. >>>> >>>> > Or somehow inject the manifest into a built exe? >>>> Readup on *mt.exe*, I haven't used it on go programs but it might work. >>>> >>>> https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest-inside-a-c-cpp-application?view=vs-2019 >>>> >>>> Tho I'm not quite sure what you're trying to do and what the problem >>>> is. >>>> What do you mean by "locally-generated resource.syso" and how is it >>>> different from a syso file generated by goversioninfo? >>>> Do you have a package that contains a syso manifest file checked into >>>> version control and you want to override it's contents on your system >>>> somehow? >>>> >>>> On Tuesday, 15 September 2020 at 11:41:45 pm UTC+8 aro...@gmail.com >>>> wrote: >>>> >>>>> I’m trying to embed windows manifest information into an exe. I’ve >>>>> generated the resource.syso file using goversioninfo and it works fine >>>>> when >>>>> that file is in the target package. But now I want to do something >>>>> slightly >>>>> different: I want to use go build module/package/cmd/binary with a >>>>> locally-generated resource.syso. Is there a way to force the go linker to >>>>> include the local manifest file? Or somehow inject the manifest into a >>>>> built exe? Currently I have two workarounds that I’m trying to avoid: >>>>> >>>>> 1. The main package of the target binary is incredibly thin and I >>>>> duplicate the main package locally and compile with the generated syso >>>>> file. >>>>> 2. I can use modcacherw to allow modifications of the imported >>>>> module package and modify the source folder of the binary and inject >>>>> the >>>>> syso file. >>>>> >>>>> Any way to make go build just link in the file? >>>>> >>>>> - Augusto >>>>> >>>> -- 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/4d79a290-2510-42f0-9bc0-c36c1264bc68n%40googlegroups.com.
