#286 Detect ncurses flags using pkg-config with fallback

[James Le Cuirot]

This addresses bug #476. On some systems like Gentoo, simply using -lncurses isn't enough because the tinfo symbols are in a separate library. pkg-config allows the build to work out of the box even on some fairly exotic systems, assuming they have .pc files present, which many do these days. I have also included a fallback to the old mechanism and tidied up the logic a bit.

[Qbix]

This goes unfortunately wrong with my cross-compiler, as there the pkg-config of the host used to to find curses, ending up with the wrong file.

[Qbix]

should I specify some flag to not use pkg-config or is it a weird case that the cross-compiler doesn't have it while the host has.

[James Le Cuirot]

Cross-compile environments vary so I guess there is no standard approach for this but Gentoo installs a wrapper script such as /usr/bin/m68k-unknown-linux-gnu-pkg-config that sets environment variables before calling pkg-config. I believe this is script is searched for automatically by configure before falling back to plain pkg-config but you can also set the environment variables manually. For example:

PKG_CONFIG_SYSROOT_DIR=/path/to/cross/system
PKG_CONFIG_PATH=/path/to/cross/system/usr/lib/pkgconfig:/path/to/cross/system/usr/share/pkgconfig

You may also need to set PKG_CONFIG_SYSTEM_LIBRARY_PATH if your cross system has non-standard lib directory names such as /usr/lib64:/lib64.

I found that cross-compiling worked for me even without doing the above for a few reasons. pkg-config will not normally include flags for standard paths like /usr/include and /usr/lib. This is controlled by PKG_CONFIG_SYSTEM_LIBRARY_PATH. My ncurses.pc doesn't reference any other paths because curses.h and ncurses.so are in these standard paths. A cross toolchain will normally look under an alternative sysroot such as /path/to/cross/system rather than just / so it will find the right files anyway if there are no -I or -L flags to throw it off.

If your cross toolchain's default sysroot doesn't point to where your cross system is then you can override this with the --sysroot flag. I find this works most effectively when appended to CC and CXX. For example:

CC="m68k-unknown-linux-gnu-gcc --sysroot=/path/to/cross/system"
CXX="m68k-unknown-linux-gnu-g++ --sysroot=/path/to/cross/system"

Please let me know if you have any more questions. Cross-compiling is a hobby of mine.

[Qbix]

Under my cross-compiler the pkg-config stuff does not exist (the program itself doesn't). So it should not run pkg-config at all. the fallback finds the wrong library (name wise) and in the wrong place and of course the wrong OS.

[James Le Cuirot]

You don't need the pkg-config binary installed in the cross system. It's a native binary so it wouldn't run anyway. Ideally you would have .pc files present there as they really do help, despite some of the FUD I've read around this in the past.

It's not essential though. I'm not forcing you to use pkg-config here. If you set PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH as above, even if there are no .pc files present then that will prevent pkg-config prevent picking up the ones on your build system... almost. When trying this out, I found that you have to set PKG_CONFIG_LIBDIR to either the same value as PKG_CONFIG_PATH or the empty string. I'm not sure why pkg-config has two variables for this but hey, it works.

[James Le Cuirot]

Actually another even simpler alternative if you really don't want to use pkg-config at all is to simply set this when calling configure.

PKG_CONFIG=/bin/false

[Qbix]

You are not forcing me, but I do have to employ work arounds in order to be able to keep compiling dosbox. (which isn't that surprising in cross compilation setup). I don't know if pdcurses has pc files at all (as this is cross compiler on linux for windows)
I will give the variables a try, but it is a bit messy in case there are packages in my cross compiler that can be detected that way. (not that we use pkg-config anywhere else in dosbox, so for now it is not a real issue, but it is something to keep in mind when deciding if we want to add a package using it (and if we would be adding pkg-config at all))

[James Le Cuirot]

The patch above no longer applies to the latest trunk so here's a new one. Please take this so that we don't have to keep fixing it.