search

UltraStar-Deluxe / USDX

The free and open source karaoke singing game UltraStar Deluxe, inspired by Sony SingStar™
https://usdx.eu
GNU General Public License v2.0
832 stars 160 forks source link

Use pkg-config to link against lua #462

Closed teto closed 4 years ago

teto commented 5 years ago

Please, do not create duplicate issues

Actual behaviour

Compilation fails on master with:

/home/teto/USDX/src/media/UAudioDecoder_FFmpeg.pas(325,3) Note: Local variable "TestFrame" not used
Compiling media/UMedia_dummy.pas
Compiling menu/UMenuStaticList.pas
Linking ../game/ultrastardx
Warning: "crti.o" not found, this will probably cause a linking failure
Warning: "crtn.o" not found, this will probably cause a linking failure
/nix/store/2dfjlvp38xzkyylwpavnh61azi0d168b-binutils-2.31.1/bin/ld : avertissement : ../game/link.res contient des sections de sortie; avez-vous oublié -T?
/nix/store/2dfjlvp38xzkyylwpavnh61azi0d168b-binutils-2.31.1/bin/ld : ne peut trouver -llua5.2
Error: Error while linking
Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /nix/store/6y49zi0s1s7fwirv4yd3835khnmh0wl0-fpc-3.0.0/bin/ppcx64 returned an error exitcode
make[1]: *** [Makefile:233: ../game/ultrastardx] Error 1
make[1] : on quitte le répertoire « /home/teto/USDX/src »
make: *** [Makefile:115: all] Error 2

This is the result of the configure

configure:4913: checking for lua5.3
configure:4921: $PKG_CONFIG --exists --print-errors "lua5.3"
Package lua5.3 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.3.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.3' found
configure:4924: $? = 1
configure:4952: result: no
configure:5056: checking for lua5.2
configure:5064: $PKG_CONFIG --exists --print-errors "lua5.2"
configure:5067: $? = 0
configure:5087: result: yes (-L/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/lib)
configure:5119: checking version of lua
configure:5128: $PKG_CONFIG --exists --print-errors "lua5.2"
configure:5131: $? = 0
configure:5154: result: [5.2.4]
configure:5485: checking size of lua_Integer
configure:5494: $PKG_CONFIG --exists --print-errors "$lua_LIB_NAME"
configure:5497: $? = 0
configure:5523: gcc -o conftest -g -O2 -I/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/include   conftest.c  -L/nix/store/5rhyabiwij29b3lqmgxzx5fiqcrwjkcd-SDL2-2.0.9/lib -L/nix/store/5rhyabiwij29b3lqmgxzx5fiqcrwjkcd-SDL2-2.0.9/lib -L/nix/store/c15bk2sc3djw3w4fzdkbb3l2hahkh5b8-SDL2_image-2.0.4/lib -L/nix/store/zxdnpb673bf27hcqzvssv5629m4x5bjv-freetype-2.10.0/lib -L/nix/store/ap4sr1n0wlgmybxbw3pvq8klh8snc3n8-sqlite-3.28.0/lib -L/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/lib >&5
configure:5523: $? = 0
configure:5523: ./conftest
configure:5523: $? = 0
configure:5529: result: 64 bits

Expected behaviour

I believe rather than guessing what to link, if pkg-config is available then the softwaure should just use pkg-config --libs lua to get the LDFLAGS. For instance on my system, the content of lua5.2.pc is:

prefix=/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4
libdir=/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/lib
includedir=/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/include
INSTALL_BIN=/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/bin
INSTALL_INC=/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/include
INSTALL_LIB=/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/lib
INSTALL_MAN=/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/man/man1

Name: Lua
Description: An Extensible Extension Language
Version: 5.2.4
Requires:
Libs: -L/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/lib -llua -lm
Cflags: -I/nix/store/05hwxyizx7bc4p01jgf21vwlk2k7prri-lua-5.2.4/include
s09bQ5 commented 5 years ago

Your case is a beautiful example of why it is difficult to do this right with Free Pascal. pkg-config --libs-only-l Lua will output -llua -lm. We can't simply pass that to the compiler. The language expects that we name the library each time we declare a function from that library. So we put the name of the library into the autoconf variable lua_LIB_NAME that is substituted in src/config.inc.in. But if all we have is -llua -lm, which is the correct library? lua or m? If we don't want to guess based on the name, we would have to check the exported symbols of both libraries. But what is the full name of the library? liblua.so? liblua.a? liblua.dylib? ... And in which directory can we find it? We would need to search all directories returned by pkg-config --libs-only-L Lua and the default directories compiled into the compiler/linker. Is it a shared library so we can use nm -Dg or do we have to use nm -g to list the relevant symbols? It might even be a linker script disguised as a library, like it is usually done for libc and libpthread from Glibc. And what about -lm? There must be a reason why it is listed in lua5.2.pc. Do we really have to explicitly link to the math library? Also note #188.

teto commented 5 years ago

don't know about free pascal:

The language expects that we name the library each time we declare a function from that library.

you mean the soname ? Is there a way to force the value of lua_LIB_NAME ? In worst case, we might patch the installer.

vcunat commented 5 years ago

I see we did patch it for pcre already, so I just extended that and it seems to work: NixOS/NixPkgs@fbda7ca802b. Of course, feel free to improve here in upstream and/or the expression in nixpkgs.