Tags: kyocheng/zgrab
Tags
Change conflicting cgo name with TLS package I'm not sure how I figured out this bug as quickly as I did, so I'm going to document this because this is stupid and symbolic of everything that is wrong with Golang. Whenever ztls was imported on a project that also import the regular TLS Golang library (h/t Adam), the build would fail because of duplicate symbols. I thought this was a naming issue on the part of our forked X.509 library (we kept the name x509), but it turns out this was due to a damn cgo function inside of the x509 library. On OS X, at least, the offending file was root_cgo_darwin. I didn't find this symbol earlier, because cgo works by embedding C code as a COMMENT in the source code of a Golang file. Fuck that. Anyway, the cgo names are not namespaced, so since the same cgo bullshit existed in the x509 library itself, this would result in a duplicate symbol error at the linking stage. I fixed this by prepending our package name to the cgo function (in the comment of the Go source code). Now the names are unique, and everything links again. This is 100% indicative of how Golang is 80% of a good idea implemented 100% of the way. It's not like it's a half-assed solution---Rob Pike et. al clearly have done a good job putting an ecosystem that works together. The problem is, the ecosystem they decided they should build is 80% of what's actually needed, and doesn't solve some of the fundamental problems facing systems programming langauges that it could have. So what we end up instead is a strong toolchain that doesn't do package versioning, a bunch of directives implemented as comments that aren't parsed correctly, and well-tested but poor solutions to the problems that pop up because Google didn't finish designing Go---they reached an arbitrary point in the languague development, and decided to start implementing. Golang is a version of C that has similar performance for IO-intensive code, with decreased development time for comparable projects. That's an incredibly good thing, but not necessarily a high bar if you're designing a modern systems programming language from scratch. You have less of the toolchain bullshit that comes with large cross-platform (network-code heavy) C projects, but it's still there. How many times have you had to clear $GOPATH/pkg despite the fact "Go doesn't need a make clean"? Go is still so much better than C in many ways. But if you'll excuse me, I'll be spending my time fighting with the 80% of my Go code that is error handling.