Re: [aur-general] How to pkg-config (Was: TU application: Daurnimator)
On 12/18/18 3:28 AM, Daurnimator wrote: > --libs-only-other seems to be missing from > https://linux.die.net/man/1/pkg-config linux.die.net has been extremely out of date for ages, fwiw -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: OpenPGP digital signature
Re: [aur-general] How to pkg-config (Was: TU application: Daurnimator)
On Mon, 17 Dec 2018 at 16:40, Eli Schwartz wrote:
> 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.
Ah ha! I didn't know about these.
--libs-only-other seems to be missing from
https://linux.die.net/man/1/pkg-config
However according to
https://bz.apache.org/bugzilla/show_bug.cgi?id=46168 they're available
since 2003
--
Does this sound like a reasonable proposal then?:
The .pc should contain:
```
V=5.3
R=${V}.5
prefix=/usr
INSTALL_BIN=${prefix}/bin
INSTALL_INC=${prefix}/include
INSTALL_LIB=${prefix}/lib
INSTALL_MAN=${prefix}/man/man1
INSTALL_LMOD=${prefix}/share/lua/${V}
INSTALL_CMOD=${prefix}/lib/lua/${V}
LIB=lua
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: Lua
Description: An Extensible Extension Language
Version: ${R}
Requires:
Cflags: -I${includedir}
Libs: -L${libdir} -l${LIB}
Libs.private: -lm -Wl,-E
```
If you're compiling a application that dynamically embeds lua then you'd use:
CFLAGS="$(pkgconf lua --cflags)" LDFLAGS="$(pkgconf lua --libs)"
If you're compiling a application that statically embeds lua then you'd use:
CFLAGS="$(pkgconf lua --cflags --static)" LDFLAGS="$(pkgconf lua
--libs --static)"
If you're compiling a lua library dynamically then your makefile would use
CFLAGS+="$(shell pkgconf lua --cflags)"
Your .so file should be installed to
$(DESTDIR)/$(shell pkgconf lua --variable=INSTALL_CMOD)
If you're compiling a lua library statically then your makefile would use
CFLAGS+="$(shell pkgconf lua --cflags --static)"
Your .so file should be installed to
$(DESTDIR)/$(libdir)
With no use of LDFLAGS for the last two cases.
Now to come up with a migration story:
- existing distributions do not currently supply
-Wl,--export-dynamic in their pkg-config files
- existing projects do not know to use pkg-config with lua in this manner.
If upstream started shipping an adjusted pkg-config file, best case it
would only be available for the 5.4 release.
Re: [aur-general] How to pkg-config (Was: TU application: Daurnimator)
On 12/16/18 11:43 PM, Daurnimator wrote: > On Tue, 11 Dec 2018 at 18:50, Eli Schwartz 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 signature.asc Description: OpenPGP digital signature
Re: [aur-general] How to pkg-config (Was: TU application: Daurnimator)
On Tue, 11 Dec 2018 at 18:50, Eli Schwartz 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
Re: [aur-general] How to pkg-config (Was: TU application: Daurnimator)
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?
Once again: for anyone wishing to provide a different version of the lua
library, interpreter, and/or pkg-config file should presumably modify
the same names in all three as a set. This does not detract from the
logic of supporting pkg-config via a pkg-config file meant to describe
the project itself.
> 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.
I don't get how that argues against pkg-config...
That sounds like the job of the application to use, that they know they
absolutely need to expose all symbols just in case and don't want to
mess with linker scripts for upstream symbols.
What's the cost of doing that in your embedded application that links
against liblua and finds a system-provided dynamic lib? The failure to
optimize your symbol table, when you didn't expect to be able to dynlink
at all?
But let's imagine instead, lua devs who support static only, and wish to
support pkg-config discovery.
This is lua.pc, no versions
Name: Lua
Version: 5.3.5
Description: An Extensible Extension Language
Cflags: -I${includedir}
Libs: -L${libdir} -Wl,--export-dynamic -llua -lm
Applications which desire to embed lua can link using:
CFLAGS += $(shell pkg-config --cflags lua)
LDLIBS += $(shell pkg-config --libs lua)
Applications which wish to build modules for lua can skip the LDLIBS
since they don't link to lua, and coincidentally also don't need to
--export-dynamic.
Downstream distros which patch lua to build shared libraries are also
responsible to optimize their ecosystem symbol tables by patching out
-Wl,--export-dynamic
Downstream distros that provide both dynamic and static libs can instead
move it to Libs.private, and pkg-config will only emit it when using:
pkg-config --static --libs lua
...
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.
> 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
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
