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/35a7f3cd-e898-444f-b7d9-c4dffde7b998n%40googlegroups.com.
