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

[Eli Schwartz]

On 12/16/18 11:43 PM, Daurnimator wrote:
> 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?"

If everyone is patching it, why should lua ship a *Makefile*?

But I didn't say anyone should patch it. Micro-optimizations for things
that work either way aren't really relevant. What is relevant is that:

- people building their own unpatched liblua.a can use it without
  modifications
- people who build distro-patched lua can *also* use it without
  modifications

- people who build several historically versioned copies of their
  distro-patched lua have a canonical file with rigidly defined linker
  flags, which *also* can be used without modifications due to, if I
  read the Makefile correctly, defining LUA_A with a versioned name.
  This is already needing to be defined at install time due to the
  installation target directory.

- people who want to both build a distro-patched shared library for lua,
  *and* micro-optimize their symbol table that works fine either way,
  can do whatever they want.

...

You're right though, having a configuration system is way too
controversial if I cannot even convince you.

>> 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

My response would be:

If you take a closer look at the manual page for pkg-config, it actually
says the exact opposite, defining "--libs" as "linker flags". In fact,
there are even three dedicated *subvariants* to get, depending on your
highly customized needs,

--libs-only-L
--libs-only-l
--libs-only-other

This is clearly a case of libs-only-other.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181217/b51ceb29/attachment.asc>