Function names are not universally prefixed with jq_ or jv_

[jgarvin]

libpcap defines some of the same symbols declared inside compile.h, namely gen_and and gen_or. This complicates using jq as a library because you end up with multiple definition linker errors.

[jgarvin]

Note I have pull request for this here: #1726

[nicowilliams]

@jgarvin I'm not sure we should support static linking with libjq. Static linking has bad semantics.

[jgarvin]

@nicowilliams there are many different reasons for doing it -- there is a significant performance difference on some platforms, and last I checked it is required for LTO. It is also pretty common practice to use fully statically link libraries at a lot of companies nowadays, with the security concerns around binary updating handled by other means -- Google for example statically likes everything. I think it is better to let users exercise their discretion about how they want to link their libraries. If the change were really involved I could understand wanting to limit support for maintenance burden reasons, but the change is just a trivial rename.

[nicowilliams]

I do not care to support statically linking anything other than jq with libjq.a. Perhaps we should just make sure that we never even distribute (or even internally produce) libjq.a.

Static linking has terribly broken semantics. We must not expose our users to the poison that is static linking.

If Google wants to statically link everything then they should pay to teach the link-editor(s) how record in static link archives a) the library's dependencies (-l arguments), b) where to look for those at executable link-edit time (the -L arguments), and c) the mapfile / version script's symbol visibility controls and symbol version bindings (EDIT: added (c)). And, of course, the link-editor(s) need to look for this at executable link-edit time and use this metadata to resolve symbol conflicts. You know, almost exactly like how ELF works, only with the final outcome being a statically-linked executable.

I'll do two things: a) give @stedolan and @wtlangford a chance to comment, b) open an issue to never install (in make install) libjq.a.

EDIT: I might actually build half the tool I'm saying that Google ought to write: a wrapper around the link-editor that writes the missing metadata in a .o when producing ar archives and applies some of the symbol visibility rules by renaming symbols in the other .os on the fly, or when producing an executable, uses these .os accordingly (this latter is the really hard part; without actually modifying the link-editor there isn't enough good we can do in a wrapper).