On Wed, May 15, 2013 at 5:00 PM, William Orr <w...@worrbase.com> wrote: > Even with the OpenBSD libtool, the problem persists. If I rerun the command > that it outputted with the -lc flag passed on the command line, it works > perfectly. Both libtools strip it out, as I discovered in this mailing list > post[1]. I'm not sure why I need to pass in -lc, as I don't most other times > when building software.
OpenBSD does not, in general, support shared-library dependencies on libc or libpthread. Doing so requires either a) every library change is a flag day, with significant ordering issues during the build, OR b) symbol versioning hell. This is from bitter experience. We tried it briefly and the ordering issues broke builds and left build machines hosed until they had their /usr/lib directories scrubbed from single-user mode. Bad Mojo. As for symbol versioning, it's a nasty slope of backwards compat (== bug compat) and attack surfaces that we do not have the desire to provide, much less the time to do so. Note also that it would kill all static-only platforms, as static linking doesn't support symbol versioning. With that background, it should perhaps make sense why the -lc option is vanishing. So, why does your link break? Because you're passing it the -Wl,-z,defs option (using its GNU spelling, -Wl,--no-undefined). I understand why you are doing that, but given the constraints of the above, it ain't gonna work. Philip Guenther
