On Sun, Apr 11, 2021 at 07:48:06PM +0200, Helmut Grohne wrote: > Package: libncurses-dev > Version: 6.2+20201114-2 > File: /usr/bin/ncurses6-config > User: [email protected] > Usertags: rebootstrap > > Coinstalling libncurses-dev has another issue besides #720033. There is > another file conflict on /usr/bin/ncurses6-config. It results from > embedding LDFLAGS. For all release architectures, those are set up as > -Wl,-z,relro and due to hardening also -Wl,-z,now. Some architectures > such as avr32, hppa and ia64 do not implement them and thus the LDFLAGS > differ. Since they get embedded in /usr/bin/ncurses6-config, we get a > file conflict.
yes... it would be nice if the cross-compiling packages would install using a tool-prefix for these special cases (as the cross-compiling tools do themselves). Actually I do that for myself. Here's what I have (Debian 10) in /usr/bin: /usr/bin/i686-w64-mingw32-ncursesw6-config <-- mine /usr/bin/ncurses5-config /usr/bin/ncurses6-config /usr/bin/ncursestw6dev-config <-- mine /usr/bin/ncursesw5-config /usr/bin/ncursesw6-config /usr/bin/ncursesw6dev-config <-- mine /usr/bin/x86_64-w64-mingw32-ncursesw6-config <-- mine (I'm able to build my test-packages for ncurses-examples with those pc files) > Looking closer, these flags are actively filtered in ncurses6-config > such that they do not pose any behavioural difference. So actually > fixing this would be possible by fixing the generated > /usr/bin/ncurses6-config to not contain them. The filtering can either > happen inside the configure script or applied post build in a > Debian-specific fixup. > > In any case, I think that embedding the buildflags like this is a bad > idea and worth reporting. They've always been architecture-dependent and > it is not entirely unlikely that it'll hunt us at a later time for a > release architecture. > > Helmut > -- Thomas E. Dickey <[email protected]> https://invisible-island.net ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
