config.sh: let user override pkg-config by setting PKG_CONFIG

[X-Ryl669]

I guess adding pkg-config for ncurses should work too:

TMP_CFLAGS="-I/usr/local/include -I/usr/include/ncurses -I/usr/include/ncursesw"
TMP_LDFLAGS="-L/usr/local/lib -lncursesw"

should read

TMP_CFLAGS="$(${PKG_CONFIG} --cflags  ncurses)"
TMP_LDFLAGS="$(${PKG_CONFIG} --libs ncurses)"

But, I don't know if it's the same for you, but on my system:

$ pkg-config -libs ncurses
-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -lncursesw

which is really disturbing, I don't expect a library flag to change the optimization level.

[rofl0r]

should read TMP_CFLAGS="$(${PKG_CONFIG} --cflags ncurses)" TMP_LDFLAGS="$(${PKG_CONFIG} --libs ncurses)"

yes, i left this out for the next step/PR. also imo ncursesw should be tested before ncurses, as widechar support seems to be one of the things angel really cares about.

-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -lncursesw

that's indeed disturbing. looks like a bug to me. at least you have a pkg-config file at all, ncurses 5.9 used to default to having a configure option for that which was off, and instead provided its own proprietary ncurses5-config script.

[rofl0r]

-Wl,-O1,--sort-common

actually, this is a linker flag, so it won't affect your optimization level. i wonder what it's supposed to do...

[ttcdt]

ncurses[w] cannot be detected with pkg-config in Debian nor OpenBSD.

10/11/20 18:13, X-Ryl669:

I guess adding pkg-config for ncurses should work too:

|TMP_CFLAGS="-I/usr/local/include -I/usr/include/ncurses -I/usr/include/ncursesw" TMP_LDFLAGS="-L/usr/local/lib -lncursesw" |

should read

|TMP_CFLAGS="$(${PKG_CONFIG} --cflags ncurses)" TMP_LDFLAGS="$(${PKG_CONFIG} --libs ncurses)" |

But, I don't know if it's the same for you, but on my system:

|$ pkg-config -libs ncurses -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -lncursesw |

which is really disturbing, I don't expect a library flag to change the optimization level.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ttcdt/mp-5.x/pull/7#issuecomment-724841551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP4PJ2NYM3REDXAWDAFTGGDSPFYCBANCNFSM4TQ5DOHA.

[rofl0r]

ncurses[w] cannot be detected with pkg-config in Debian nor OpenBSD.

yes, probably because as i mentioned before that ncurses 5.9's configuration defaulted to not write a pkgconfig file but prefer its own proprietary ncurses5-config script. however once ncurses 6 gets adopted by those they will eventually follow suit. sanely configured systems do provide the script already, that's why we should test first pkgconfig ncursesw, then ncurses, then adding the -lncursesw/-lncurses manually, and if even that fails fall back to ncurses5-config.

[X-Ryl669]

I'm running on arch with ncurses version 6.2. Here, pkg-config answer the same for ncursesw or ncurses (see above output), and I have unicode char in pipes so I'm pretty sure it's the widechar version that's built.

So, it's not clear what to do here.

Should we drop support for very old debian oddities, and instead try pkg-config then "wild guess" like I did in my patch (that is add another sequence to the test: pkg-config, else ncursesw else ncurses) ?

[X-Ryl669]

BTW, ncursesw6-config answers the same as pkg-config on my system. Yet, it's different than ncurses5-config, so it will not help making a small code if we need to guess the autoconfig program name.

[rofl0r]

BTW, ncursesw6-config answers the same as pkg-config on my system. Yet, it's different than ncurses5-config, so it will not help making a small code if we need to guess the autoconfig program name.

generally, on any system which has the toolchain correctly configured , adding -lncursesw should be sufficient, but when it isn't, it's cheap to call first which ncurses6w-config (or more posixly_correct, type ncurses6w-config) followed by which ncurses5-config.

Should we drop support for very old debian oddities, and instead try pkg-config then "wild guess" like I did in my patch

no, we really shouldn't "wild guess" and add random pathnames. if all of the above fails due to a heavily misconfigured system, then i'd say it's reasonable to force the user to supply a configure flag like --with-ncurses-cflags or similar.