. On Tue, 11 Dec 2018 at 14:44, Eli Schwartz via aur-general <aur-general@archlinux.org> wrote: > Do you mean they removed a pc rather than an echo target?
Yes, sorry for confusion. > If lua does not officially compile a C++ version, it is the job of > Debian to both provide their own pkg-config files, and modify lua to > build using C++. Lua supports either compiling with longjmp or C++ based exceptions. See "Error-recovery functions" near https://www.lua.org/source/5.3/ldo.c.html#errorstatus > If lua only provides a static library named liblua.a, then this will > conflict with any other version of lua, and thus, so will the pkg-config > file. Distributions which work around this using `mv` and `ln` on the > library can also `mv` and `ln` the pkg-config file. Also to patch the pkg-config file to provide the relevant suffixes on e.g. cflags. > If downstream lua applications wish to support versioned lua shared > libraries, I would recommend using something like > > LDLIBS += $(shell pkg-config --libs lua$(LUAVER)) > > and telling distros to compile with make LUAVER=5.2 to match their own > distro versioning, if they don't want to use the one, official, > canonical lua.pc that doesn't support dynamic linking at all. > > If LUAVER is not defined, then no loss! It does as intended and compiles > for the default version of lua, right? > > >> Admittedly, this target is > >> missing the Libs: keyword so that users can actually use the invocation > >> `pkg-config --libs lua` to find out the right flags for linking lua. > >> This would be helpful both to users wishing to statically link, and > >> those wishing to dynlink. Admittedly also, this pc target echoes to > >> stdout instead of like creating the actual file. > >> > >> Note: the Arch, Debian, and Fedora maintainers have *all* fixed the pc > >> file to provide proper Libs:, and while I wouldn't generally recommend > >> relying on downstream pkg-config files, the official sources do quite > >> plainly allow you to use in your Makefile: > >> > >> CFLAGS += $(shell pkg-config --variable includedir lua) > >> > >> since it is assumed lua distributors will run make pc > lua.pc and > >> install this file themselves. > > > > They do not. > > Then why do they have the target? For that matter, reading your links it > appears that the lua developers are quite insistent that distributions > *should* provide these pc files even if they write them themselves. > > I'd guess the assumption by lua devs is therefore that "yes, they will > either use: make pc > lua.pc, or they will write their own from scratch, > either way assume it exists". Maybe they should document this on their > installation guidelines to make it official. > > > The upstream lua makefile does not even support creating shared > > libraries; that is patched in (differently!) by each distro. > > This is such a huge misunderstanding of what pkg-config is, and it's > something I have zero opinion on. For the purposes of this discussion I > don't care if lua uses shared libraries either officially or > unofficially, and it has no bearing on anything I say. > > pkg-config is not about shared libraries. pkg-config does not care about > whether you use shared libraries. pkg-config is about telling you which > compiler flags to use, and compiler flags don't care whether you use > shared or static. > > There are primarily four types of flags pkg-config provides: > > Name: > Version: > Cflags: > Libs: > > 1) is documented to contain a name useful for naming the thing > > 2) is documented to contain a version that can be used for checking to > see if your system claims to support a given version of the named thing. > > 3) and 4) are documented to contain symbolic flags that are required by > an application that expects to consume the project provided by the > pkg-config file. It does not specify whether this project has any such > flags, but if it does have such flags, they need to be here. The flags > that the project needs are philosophically derived from whatever the > project that provides the pkg-config file believes is right and just > that should be used, and wish to unconditionally message to the entire > world that they should use. > > 3) should contain any -I/usr/include/ path to the location of the > headers, and any other compiler CFLAGS of note > > 4) should contain the -lfoo name of any compiler LDLIBS of note, paying > heed to the fact that statically linked applications use -lfoo to link > to libfoo.a just as surely as shared applications use -lfoo to link to > libfoo.so, and your compiler will in fact always check for both. > > In fact, GNU ld documents -lfoo as searching for libfoo.a, and adds as > an afternote that "on systems which support shared libraries, ld may > also search for files other than libnamespec.a" (and on ELF systems, it > will first search for *.so) > > You may also specify compiler LDLIBS like: > > Libs: -l:libfoo.a > > which is a pkg-config metadata specifier signaling a GNU ld flag that > looks for the exact filename "libfoo.a" and thus does not give the > option of auto-detecting shared libraries. > > ... > > Finally, pkg-config explicitly supports static linking via > > Libs.private: > Cflags.private: > > (The latter is ignored by freedesktop pkg-config, but used by pkgconf.) > > The .private variant means, this is the additional flags you use when > explicitly using `pkg-config --static --libs foo` to request the flags > that are fine-tuned to building your application with a static version > of the pkg-config symbolic system provider for "foo". > > The pkg-config specification authors would like the lua developers -- > and you -- to know that they are warmly welcoming to the needs of people > who provide static libraries. So some extra context may be required here. Lua needs to be used by two different types of code: 1. code that embeds lua 2. lua libraries written in C For most unix systems (this is *not* true on windows): Things in category 1 include the `lua` executable itself, as well as applications like mame, powerdns, vlc, etc. If they link against lua statically, then they should expose lua C symbols via e.g. -Wl,--export-dynamic If they link against lua dynamically then they are fine. Things in category 2 include libraries such as lua-filesystem. They expose an entrypoint of luaopen_mylibname, and use the lua C api. These should *not* link against liblua, and need to rely on symbols provided by the host application. However note that both categories of code need to find the lua headers.