Closed Kleissner closed 3 years ago
After updating to the latest version v3.10.0 the init function of unipdf causes any executable to exit immediately with printing out this:
Build information missing - Exiting1
Since the code is obfuscated, best I can provide is IDA screenshot where it appears (github_com_unidoc_unipdf_model__gafcc):
github_com_unidoc_unipdf_model__gafcc
There is code in https://github.com/unidoc/unipdf/blob/master/model/model.go re _gafcc, which references ReadBuildInfo:
_gafcc
ReadBuildInfo
func _gafcc (){_dcdeed ,_ccaac :=_e .ReadBuildInfo ();
Looking up https://golang.org/pkg/runtime/debug/#ReadBuildInfo:
ReadBuildInfo returns the build information embedded in the running binary. The information is available only in binaries built with module support.
Why does it require module support? I use latest Go 1.15 on Windows 10 64-bit. I'm not using modules and I don't want to.
Is this issue now coming up because of the update to Go 1.15 and how it compiles binaries? Go 1.15 does promise smaller binaries.
Fixed in https://github.com/unidoc/unipdf/commit/e181b14be6110fca8cbc2a109a2dde6cafeb6c53
Kleissner
commented
3 years ago Kleissner
commented
3 years ago
Description
After updating to the latest version v3.10.0 the init function of unipdf causes any executable to exit immediately with printing out this:
Since the code is obfuscated, best I can provide is IDA screenshot where it appears (
github_com_unidoc_unipdf_model__gafcc):There is code in https://github.com/unidoc/unipdf/blob/master/model/model.go re
_gafcc, which referencesReadBuildInfo:Looking up https://golang.org/pkg/runtime/debug/#ReadBuildInfo:
Why does it require module support? I use latest Go 1.15 on Windows 10 64-bit. I'm not using modules and I don't want to.
Is this issue now coming up because of the update to Go 1.15 and how it compiles binaries? Go 1.15 does promise smaller binaries.