[aur-general] How to pkg-config (Was: TU application: Daurnimator)

[Daurnimator]

On Tue, 11 Dec 2018 at 18:50, Eli Schwartz <eschwartz at archlinux.org> wrote:
> On 12/11/18 6:19 PM, Daurnimator wrote:
> >> 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
>
> Okay, that's fine. So how does this work, then, and why does it need a
> separate pkg-config file? Is it just a matter of renaming liblua.a to
> liblua-c++.a to prevent filename clashes and thereby permit parallel
> installation? So... why is this any different from renaming the
> versioned libraries?

It is not essentially a different ABI?
liblua.a uses longjmp for error handling, libluac++.a.so uses C++ exceptions.
If you want to specifically link against e.g. the C++ one, what should
a lua-using-project use?

> Downstream distros which patch lua to build shared libraries are also
> responsible to optimize their ecosystem symbol tables by patching out
> -Wl,--export-dynamic

This is where upstream turns around and says "if everyone is patching
it, why should we ship it at all?"

> In all cases, the pkg-config file by design should work as-is, with the
> assumption that it describes the project which is compiled using make &&
> sudo make install. It's a madness game to even pretend to also support
> the modifications which people make to the build system.

upstream lua has historically shipped with a "please create your own
build system".
For many years the recommended compilation instructions were "give the
.c files to your compiler of choice and hit build"
Such instructions are relatively timeless e.g. https://youtu.be/-jvLY5pUwic

Now I think we here agree that this isn't the best way forward, but
the upstream audience is diverse and can take time to convince.

> > 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.
>
> That's fine, it makes it even more convenient to reserve --libs for the
> exclusive use of -Wl,--export-dynamic

I just know that someone would reply to me with something like the
following if I proposed this, so I may as well see what your response
is:

package config's --libs output is meant for use with LDLIBS.
Flags for the linker should *not* be passed in LDLIBS and should only
be passed in LDFLAGS