[aur-general] TU application: Daurnimator

[Daurnimator]

. On Tue, 11 Dec 2018 at 14:44, Eli Schwartz via aur-general
<aur-general at 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.