Problem building util-linux without a separate ncursesw include dir

Problem building util-linux without a separate ncursesw include dir

[Carlos Santos]

Hello,

Since commit 3947ca4ca (build-sys: ncurses headers cleanup), util-linux
assumes that ncursesw headers are in an "ncursesw" subdirectory. That's
valid on systems that have both ncurses variants but not on embedded
systems like Buildroot on which only one variant is build, with headers
always installed directly at /usr/include.

I added a patch to revert commit 3947ca4ca to the Buildroot recipe but
such a drastic solution can easily become incompatible with new versions
of util-linux. Would it be possible to make the location of ncursesw
headers configurable, instead?

Thanks in advance.

-- 
Carlos Santos (Casantos) - DATACOM, P&D
Rua América, 1000 - Eldorado do Sul, RS, Brasil - 92990-000
casantos@datacom.ind.br          +55 51 3933.3000 ext. 3627
http://www.datacom.ind.br

Re: Problem building util-linux without a separate ncursesw include dir

[Carlos Santos]

> From: "Carlos Santos" <casantos@datacom.ind.br>
> To: util-linux@vger.kernel.org
> Sent: Monday, July 31, 2017 9:12:03 PM
> Subject: Problem building util-linux without a separate ncursesw include dir

> of util-linux. Would it be possible to make the location of ncursesw
> headers configurable, instead?

I was thinking on something simple, like https://pastebin.com/VqM9G9yu

-- 
Carlos Santos (Casantos) - DATACOM, P&D
“The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.” — Christopher Hitchens

Re: Problem building util-linux without a separate ncursesw include dir

[Karel Zak]

On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
> > From: "Carlos Santos" <casantos@datacom.ind.br>
> > To: util-linux@vger.kernel.org
> > Sent: Monday, July 31, 2017 9:12:03 PM
> > Subject: Problem building util-linux without a separate ncursesw include dir
> 
> > of util-linux. Would it be possible to make the location of ncursesw
> > headers configurable, instead?

We test for alone ncurses.h and term.h in the for non-wide ncurses.
Can you send output from your configure from the current master
branch (or v2.30.1)?

> I was thinking on something simple, like https://pastebin.com/VqM9G9yu

Hmm, but you don't distinguish between wide and non-wide ncurses.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Problem building util-linux without a separate ncursesw include dir

[Carlos Santos]

> From: "Karel Zak" <kzak@redhat.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: util-linux@vger.kernel.org
> Sent: Tuesday, August 1, 2017 4:20:17 AM
> Subject: Re: Problem building util-linux without a separate ncursesw incl=
ude dir

> On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
>> > From: "Carlos Santos" <casantos@datacom.ind.br>
>> > To: util-linux@vger.kernel.org
>> > Sent: Monday, July 31, 2017 9:12:03 PM
>> > Subject: Problem building util-linux without a separate ncursesw inclu=
de dir
>>=20
>> > of util-linux. Would it be possible to make the location of ncursesw
>> > headers configurable, instead?
>=20
> We test for alone ncurses.h and term.h in the for non-wide ncurses.
> Can you send output from your configure from the current master
> branch (or v2.30.1)?

config.log: https://pastebin.com/DVAyx1Zb
defconfig for buildroot: https://pastebin.com/U3pz0hvm

>> I was thinking on something simple, like https://pastebin.com/VqM9G9yu
>=20
> Hmm, but you don't distinguish between wide and non-wide ncurses.

That's because on Buildroot only one of the variants can exist.

BTW I noticed that on Fedora each /usr/include/ncurses/<foo> is a
symlink to ../<foo>, so the situation is exactly the same.

--=20
Carlos Santos (Casantos) - DATACOM, P&D
=E2=80=9CThe greatest triumph that modern PR can offer is the transcendent=
=20
success of having your words and actions judged by your reputation,=20
rather than the other way about.=E2=80=9D =E2=80=94 Christopher Hitchens

Re: Problem building util-linux without a separate ncursesw include dir

[Karel Zak]

On Tue, Aug 01, 2017 at 09:09:22AM -0300, Carlos Santos wrote:
> > From: "Karel Zak" <kzak@redhat.com>
> > To: "Carlos Santos" <casantos@datacom.ind.br>
> > Cc: util-linux@vger.kernel.org
> > Sent: Tuesday, August 1, 2017 4:20:17 AM
> > Subject: Re: Problem building util-linux without a separate ncursesw include dir
> 
> > On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
> >> > From: "Carlos Santos" <casantos@datacom.ind.br>
> >> > To: util-linux@vger.kernel.org
> >> > Sent: Monday, July 31, 2017 9:12:03 PM
> >> > Subject: Problem building util-linux without a separate ncursesw include dir
> >> 
> >> > of util-linux. Would it be possible to make the location of ncursesw
> >> > headers configurable, instead?
> > 
> > We test for alone ncurses.h and term.h in the for non-wide ncurses.
> > Can you send output from your configure from the current master
> > branch (or v2.30.1)?
> 
> config.log: https://pastebin.com/DVAyx1Zb

I see --with-ncursesw, it means the configure.ac code where we check
for alone ncurses.h is not executed. Try it without this --with... I
guess it will work.

> defconfig for buildroot: https://pastebin.com/U3pz0hvm
> 
> >> I was thinking on something simple, like https://pastebin.com/VqM9G9yu
> > 
> > Hmm, but you don't distinguish between wide and non-wide ncurses.
> 
> That's because on Buildroot only one of the variants can exist.
> 
> BTW I noticed that on Fedora each /usr/include/ncurses/<foo> is a
> symlink to ../<foo>, so the situation is exactly the same.

Yes, but the symlink is good enough (f25):

        checking for ncursesw6-config... ncursesw6-config
        checking ncursesw/ncurses.h usability... yes
        checking ncursesw/ncurses.h presence... yes
        ...


Anyway, you're right with your suggested patch :-)

We don't have to distinguish between wide and non-wide ncurses when we
check for header files, because it's already done by
UL_NCURSES_CHECK() and AC_CHECK_HEADERS() is executed only if we
already have widechar lib.

Fixed... git-pull and try it. 

    Karel

> “The greatest triumph that modern PR can offer is the transcendent 
> success of having your words and actions judged by your reputation, 
> rather than the other way about.” — Christopher Hitchens

Nice ;-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Problem building util-linux without a separate ncursesw include dir

[Carlos Santos]

> From: "Karel Zak" <kzak@redhat.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: util-linux@vger.kernel.org
> Sent: Tuesday, August 1, 2017 9:44:05 AM
> Subject: Re: Problem building util-linux without a separate ncursesw include dir

[...]
> 
> We don't have to distinguish between wide and non-wide ncurses when we
> check for header files, because it's already done by
> UL_NCURSES_CHECK() and AC_CHECK_HEADERS() is executed only if we
> already have widechar lib.
> 
> Fixed... git-pull and try it.
> 
>    Karel

Works like a charm. Thanks!

-- 
Carlos Santos (Casantos) - DATACOM, P&D
“The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.” — Christopher Hitchens

Re: Problem building util-linux without a separate ncursesw include dir

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On 01 Aug 2017 09:20, Karel Zak wrote:
> On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
> > > From: "Carlos Santos" <casantos@datacom.ind.br>
> > > To: util-linux@vger.kernel.org
> > > Sent: Monday, July 31, 2017 9:12:03 PM
> > > Subject: Problem building util-linux without a separate ncursesw include dir
> > 
> > > of util-linux. Would it be possible to make the location of ncursesw
> > > headers configurable, instead?
> 
> We test for alone ncurses.h and term.h in the for non-wide ncurses.
> Can you send output from your configure from the current master
> branch (or v2.30.1)?
> 
> > I was thinking on something simple, like https://pastebin.com/VqM9G9yu
> 
> Hmm, but you don't distinguish between wide and non-wide ncurses.

why don't we just support ncurses's pkg-config files as the default ?
$ pkg-config --cflags ncurses
-D_GNU_SOURCE
$ pkg-config --cflags ncursesw
-D_GNU_SOURCE -I/usr/include/ncursesw
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Problem building util-linux without a separate ncursesw include dir

[Karel Zak]

On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
> On 01 Aug 2017 09:20, Karel Zak wrote:
> > On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
> > > > From: "Carlos Santos" <casantos@datacom.ind.br>
> > > > To: util-linux@vger.kernel.org
> > > > Sent: Monday, July 31, 2017 9:12:03 PM
> > > > Subject: Problem building util-linux without a separate ncursesw include dir
> > > 
> > > > of util-linux. Would it be possible to make the location of ncursesw
> > > > headers configurable, instead?
> > 
> > We test for alone ncurses.h and term.h in the for non-wide ncurses.
> > Can you send output from your configure from the current master
> > branch (or v2.30.1)?
> > 
> > > I was thinking on something simple, like https://pastebin.com/VqM9G9yu
> > 
> > Hmm, but you don't distinguish between wide and non-wide ncurses.
> 
> why don't we just support ncurses's pkg-config files as the default ?
> $ pkg-config --cflags ncurses
> -D_GNU_SOURCE
> $ pkg-config --cflags ncursesw
> -D_GNU_SOURCE -I/usr/include/ncursesw
> -mike

because pkg-config is not supported by ncurses upstream by default and
it's not always the best solution. See commit
4c12a334dc4104d16dc06edf51904b08b08fcdfa.

The ncurses detection and variability in distros is horrible. We
already tried all possible combinations and always someone complains
about the way how we detect ncurses. See mailing list archive for more
information.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Problem building util-linux without a separate ncursesw include dir

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

On 19 Jan 2018 10:40, Karel Zak wrote:
> On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
> > On 01 Aug 2017 09:20, Karel Zak wrote:
> > > On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
> > > > > From: "Carlos Santos" <casantos@datacom.ind.br>
> > > > > To: util-linux@vger.kernel.org
> > > > > Sent: Monday, July 31, 2017 9:12:03 PM
> > > > > Subject: Problem building util-linux without a separate ncursesw include dir
> > > > 
> > > > > of util-linux. Would it be possible to make the location of ncursesw
> > > > > headers configurable, instead?
> > > 
> > > We test for alone ncurses.h and term.h in the for non-wide ncurses.
> > > Can you send output from your configure from the current master
> > > branch (or v2.30.1)?
> > > 
> > > > I was thinking on something simple, like https://pastebin.com/VqM9G9yu
> > > 
> > > Hmm, but you don't distinguish between wide and non-wide ncurses.
> > 
> > why don't we just support ncurses's pkg-config files as the default ?
> > $ pkg-config --cflags ncurses
> > -D_GNU_SOURCE
> > $ pkg-config --cflags ncursesw
> > -D_GNU_SOURCE -I/usr/include/ncursesw
> 
> because pkg-config is not supported by ncurses upstream by default and
> it's not always the best solution.

you mean upstream's configure script doesn't default it to on.  distros
can (and many do) simply pass --enable-pc-files to get them.  but i don't
see how that's relevant to preference when it comes to detection.

> See commit 4c12a334dc4104d16dc06edf51904b08b08fcdfa.

seems like that's trivial to resolve with a compile test rather than
throwing it all out.  xxx-config scripts provide bad defaults when you
cross-compile because now the user has to make sure the build's copy
of ncurses-config don't get used.

> The ncurses detection and variability in distros is horrible. We
> already tried all possible combinations and always someone complains
> about the way how we detect ncurses. See mailing list archive for more
> information.

that's the point of pkg-config.  if someone is having problems because
they're doing something weird/non-standard, tell them to sort out their
pkg-config installs.  that's a lot easier than trying to cater to all
the stupid ways people try to set up their build environments.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Problem building util-linux without a separate ncursesw include dir

[Rüdiger Meier]

On 01/19/2018 07:21 PM, Mike Frysinger wrote:
> On 19 Jan 2018 10:40, Karel Zak wrote:
>> On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
>>> On 01 Aug 2017 09:20, Karel Zak wrote:
>>>> On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
>>>>>> From: "Carlos Santos" <casantos@datacom.ind.br>
>>>>>> To: util-linux@vger.kernel.org
>>>>>> Sent: Monday, July 31, 2017 9:12:03 PM
>>>>>> Subject: Problem building util-linux without a separate ncursesw include dir
>>>>>
>>>>>> of util-linux. Would it be possible to make the location of ncursesw4c12a334dc4104d16dc06edf51904b08b08fcdfa
>>>>>> headers configurable, instead?
>>>>
>>>> We test for alone ncurses.h and term.h in the for non-wide ncurses.
>>>> Can you send output from your configure from the current master
>>>> branch (or v2.30.1)?
>>>>
>>>>> I was thinking on something simple, like https://pastebin.com/VqM9G9yu
>>>>
>>>> Hmm, but you don't distinguish between wide and non-wide ncurses.
>>>
>>> why don't we just support ncurses's pkg-config files as the default ?
>>> $ pkg-config --cflags ncurses
>>> -D_GNU_SOURCE
>>> $ pkg-config --cflags ncursesw
>>> -D_GNU_SOURCE -I/usr/include/ncursesw
>>
>> because pkg-config is not supported by ncurses upstream by default and
>> it's not always the best solution.
> 
> you mean upstream's configure script doesn't default it to on.  distros
> can (and many do) simply pass --enable-pc-files to get them.  but i don't
> see how that's relevant to preference when it comes to detection.
> 
>> See commit 4c12a334dc4104d16dc06edf51904b08b08fcdfa.
> 
> seems like that's trivial to resolve with a compile test rather than
> throwing it all out.  xxx-config scripts provide bad defaults when you
> cross-compile because now the user has to make sure the build's copy
> of ncurses-config don't get used.
> 
>> The ncurses detection and variability in distros is horrible. We
>> already tried all possible combinations and always someone complains
>> about the way how we detect ncurses. See mailing list archive for more
>> information.
> 
> that's the point of pkg-config.  if someone is having problems because
> they're doing something weird/non-standard, tell them to sort out their
> pkg-config installs.

non-standard is to have ncurses.pc installed. Also cross-compiling is
certainly more "weird" than not cross-compiling. Regarding "tell them",
Have you tried yet to ask ncurses upstream about installing *.pc files
by default?

However I agree that pkg-config should be checked *before* ncurses-config
otherwise it doesn't make much sense to support pc-files at all. The case
that *.pc or ncurses-config files are installed without the headers is
really a packaging bug made by distros. We don't need to handle this case.

BTW we need to fix our usage of environment vars NCURSESW_CFLAGS,
NCURSESW_LIBS, NCURSES_CFLAGS, NCURSES_LIBS. They don't seem to work as
expected although documented in configure --help. These vars should skip
pkg-config and ncurses-config too. Probably this would work automatically
again when doing pkg-config before ncurses-config.

I still think we should evaluate autoconf_archive's ncurses detection. It's
using pkg-config first and then fallback even without ncurses-config. Could
be that even cross-compiling would work without *.pc files.
https://www.gnu.org/software/autoconf-archive/ax_with_curses.html
Though I'm too lazy for testing this ;)

> that's a lot easier than trying to cater to all
> the stupid ways people try to set up their build environments.

Installing ncurses via './configure && make install' is not the most
stupid thing IMO ... Maybe just remove your ncurses-config system wide
if you don't like it or use it correctly. Could be easier than telling
all other people on the planet that they have to install ncurses in a way
you like ...

cu,
Rudi

Re: Problem building util-linux without a separate ncursesw include dir

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]

On 20 Jan 2018 18:50, Rüdiger Meier wrote:
> On 01/19/2018 07:21 PM, Mike Frysinger wrote:
> > On 19 Jan 2018 10:40, Karel Zak wrote:
> >> On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
> >>> On 01 Aug 2017 09:20, Karel Zak wrote:
> >>>> On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
> >>>>>> From: "Carlos Santos" <casantos@datacom.ind.br>
> >>>>>> To: util-linux@vger.kernel.org
> >>>>>> Sent: Monday, July 31, 2017 9:12:03 PM
> >>>>>> Subject: Problem building util-linux without a separate ncursesw include dir
> >>>>>
> >>>>>> of util-linux. Would it be possible to make the location of ncursesw4c12a334dc4104d16dc06edf51904b08b08fcdfa
> >>>>>> headers configurable, instead?
> >>>>
> >>>> We test for alone ncurses.h and term.h in the for non-wide ncurses.
> >>>> Can you send output from your configure from the current master
> >>>> branch (or v2.30.1)?
> >>>>
> >>>>> I was thinking on something simple, like https://pastebin.com/VqM9G9yu
> >>>>
> >>>> Hmm, but you don't distinguish between wide and non-wide ncurses.
> >>>
> >>> why don't we just support ncurses's pkg-config files as the default ?
> >>> $ pkg-config --cflags ncurses
> >>> -D_GNU_SOURCE
> >>> $ pkg-config --cflags ncursesw
> >>> -D_GNU_SOURCE -I/usr/include/ncursesw
> >>
> >> because pkg-config is not supported by ncurses upstream by default and
> >> it's not always the best solution.
> > 
> > you mean upstream's configure script doesn't default it to on.  distros
> > can (and many do) simply pass --enable-pc-files to get them.  but i don't
> > see how that's relevant to preference when it comes to detection.
> > 
> >> See commit 4c12a334dc4104d16dc06edf51904b08b08fcdfa.
> > 
> > seems like that's trivial to resolve with a compile test rather than
> > throwing it all out.  xxx-config scripts provide bad defaults when you
> > cross-compile because now the user has to make sure the build's copy
> > of ncurses-config don't get used.
> > 
> >> The ncurses detection and variability in distros is horrible. We
> >> already tried all possible combinations and always someone complains
> >> about the way how we detect ncurses. See mailing list archive for more
> >> information.
> > 
> > that's the point of pkg-config.  if someone is having problems because
> > they're doing something weird/non-standard, tell them to sort out their
> > pkg-config installs.
> 
> non-standard is to have ncurses.pc installed.

that's a silly position to try to take.  you're claiming anything that isn't
turned on by default in `./configure` is non-standard ?  have you ever actually
tried building ncurses before and see what its defaults are ?  ncursesw isn't
the default, neither is installing into a subdir like /usr/include/ncursesw.
neither is libtinfo nor libtinfow.

> Also cross-compiling is certainly more "weird" than not cross-compiling.

you are aware that multilib is cross-compiling right ?  so people are doing
it every day on all the mainstream distros.

> Regarding "tell them",
> Have you tried yet to ask ncurses upstream about installing *.pc files
> by default?

i can send them an e-mail, but Thomas often leans towards not changing things
from how they've always been done, so i'm not exactly hopeful.

> > that's a lot easier than trying to cater to all
> > the stupid ways people try to set up their build environments.
> 
> Installing ncurses via './configure && make install' is not the most
> stupid thing IMO ... Maybe just remove your ncurses-config system wide
> if you don't like it or use it correctly. Could be easier than telling
> all other people on the planet that they have to install ncurses in a way
> you like ...

telling people to mess with their build system (actively breaking it), 
especially when they might be on a shared system or where they don't have
admin access, doesn't sound like a great idea to me.  especially when it's
trivial for them to resolve with --enable-pc-files.  then again, the number
of people who are building & installing ncurses by hand seems significantly
lower than those who get it from distros, so catering to their choices (that
then break things) doesn't seem worth it when they can simply adjust to do
what everyone else is doing.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Problem building util-linux without a separate ncursesw include dir

[Rüdiger Meier]

On 01/20/2018 07:14 PM, Mike Frysinger wrote:
> On 20 Jan 2018 18:50, Rüdiger Meier wrote:
>> On 01/19/2018 07:21 PM, Mike Frysinger wrote:
>>> On 19 Jan 2018 10:40, Karel Zak wrote:
>>>> On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
>>>>> On 01 Aug 2017 09:20, Karel Zak wrote:
>>>>>> On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
>>>>>>>> From: "Carlos Santos" <casantos@datacom.ind.br>
>>>>>>>> To: util-linux@vger.kernel.org
>>>>>>>> Sent: Monday, July 31, 2017 9:12:03 PM
>>>>>>>> Subject: Problem building util-linux without a separate ncursesw include dir
>>>>>>>
>>>>>>>> of util-linux. Would it be possible to make the location of ncursesw4c12a334dc4104d16dc06edf51904b08b08fcdfa
>>>>>>>> headers configurable, instead?
>>>>>>
>>>>>> We test for alone ncurses.h and term.h in the for non-wide ncurses.
>>>>>> Can you send output from your configure from the current master
>>>>>> branch (or v2.30.1)?
>>>>>>
>>>>>>> I was thinking on something simple, like https://pastebin.com/VqM9G9yu
>>>>>>
>>>>>> Hmm, but you don't distinguish between wide and non-wide ncurses.
>>>>>
>>>>> why don't we just support ncurses's pkg-config files as the default ?
>>>>> $ pkg-config --cflags ncurses
>>>>> -D_GNU_SOURCE
>>>>> $ pkg-config --cflags ncursesw
>>>>> -D_GNU_SOURCE -I/usr/include/ncursesw
>>>>
>>>> because pkg-config is not supported by ncurses upstream by default and
>>>> it's not always the best solution.
>>>
>>> you mean upstream's configure script doesn't default it to on.  distros
>>> can (and many do) simply pass --enable-pc-files to get them.  but i don't
>>> see how that's relevant to preference when it comes to detection.
>>>
>>>> See commit 4c12a334dc4104d16dc06edf51904b08b08fcdfa.
>>>
>>> seems like that's trivial to resolve with a compile test rather than
>>> throwing it all out.  xxx-config scripts provide bad defaults when you
>>> cross-compile because now the user has to make sure the build's copy
>>> of ncurses-config don't get used.
>>>
>>>> The ncurses detection and variability in distros is horrible. We
>>>> already tried all possible combinations and always someone complains
>>>> about the way how we detect ncurses. See mailing list archive for more
>>>> information.
>>>
>>> that's the point of pkg-config.  if someone is having problems because
>>> they're doing something weird/non-standard, tell them to sort out their
>>> pkg-config installs.
>>
>> non-standard is to have ncurses.pc installed.
> 
> that's a silly position to try to take.  you're claiming anything that isn't
> turned on by default in `./configure` is non-standard ?

No, as you could have read I'm talking only about --enable-pc-files being non
standard. Many distros and users are not using it and you can't just call them
all stupid. We have to support this case first.

> have you ever actually
> tried building ncurses before and see what its defaults are ?

Yes, and I install it into $HOME/usr and don't what to get it overridden by
/usr/lib64/pkgconfig/ although my $HOME/usr/bin/ncurses-config
comes first in my PATH. Especially since this worked since always and would
stop now when upgrading SLE-12 to SLE-15 (where they added --enable-pc-files),
just as an example.

   ncursesw isn't
> the default, neither is installing into a subdir like /usr/include/ncursesw.
> neither is libtinfo nor libtinfow.
> 
>> Also cross-compiling is certainly more "weird" than not cross-compiling.
> 
> you are aware that multilib is cross-compiling right ?  so people are doing
> it every day on all the mainstream distros.

I'm regularly building ul for i386 on x86_64 for testing. Just to see whether
our code works for 32bit. And it works. It's still absolutely unusual that any
real user would do that. And beside that I have no other use case for multilib
support at all.

>> Regarding "tell them",
>> Have you tried yet to ask ncurses upstream about installing *.pc files
>> by default?
> 
> i can send them an e-mail, but Thomas often leans towards not changing things
> from how they've always been done, so i'm not exactly hopeful.
> 
>>> that's a lot easier than trying to cater to all
>>> the stupid ways people try to set up their build environments.
>>enable
>> Installing ncurses via './configure && make install' is not the most
>> stupid thing IMO ... Maybe just remove your ncurses-config system wide
>> if you don't like it or use it correctly. Could be easier than telling
>> all other people on the planet that they havnote to install ncurses in a way
>> you like ...
> 
> telling people to mess with their build system (actively breaking it),
> especially when they might be on a shared system or where they don't have
> admin access, doesn't sound like a great idea to me.  especially when it's
> trivial for them to resolve with --enable-pc-files.  then again, the number
> of people who are building & installing ncurses by hand seems significantly
> lower than those who get it from distros, so catering to their choices (that
> then break things) doesn't seem worth it when they can simply adjust to do
> what everyone else is doing.

I do not think that the number of people who are building util-linux by hand
is significantly lower than the ones who would build ncurses.

Anyways I don't want to argue. My point is only that any project like UL should
respect upstream's default regarding pkg-config. There are even worse cases where
distros add/patch *.pc files to projects which don't even have --enable-pc-files
(e.g. libev on openSUSE). That's annoying if other projects would start requiring
these *.pc files although no user could provide them unless using distro packages.

cu,
Rudi

Re: Problem building util-linux without a separate ncursesw include dir

[Bruce Dubbs]

Rüdiger Meier wrote:
> On 01/19/2018 07:21 PM, Mike Frysinger wrote:
>> On 19 Jan 2018 10:40, Karel Zak wrote:
>>> On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
>>>> On 01 Aug 2017 09:20, Karel Zak wrote:
>>>>> On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:

[trim]

>>> The ncurses detection and variability in distros is horrible. We
>>> already tried all possible combinations and always someone complains
>>> about the way how we detect ncurses. See mailing list archive for more
>>> information.
>>
>> that's the point of pkg-config.  if someone is having problems because
>> they're doing something weird/non-standard, tell them to sort out their
>> pkg-config installs.
> 
> non-standard is to have ncurses.pc installed. Also cross-compiling is
> certainly more "weird" than not cross-compiling. Regarding "tell them",
> Have you tried yet to ask ncurses upstream about installing *.pc files
> by default?

In linuxfromscratch we build ncurses with the --enable-widec switch.  We 
then add

ln -sfv ncursesw.pc    /usr/lib/pkgconfig/ncurses.pc
ln -sfv libncurses.so  /usr/lib/libcurses.so

We have never had a problem with util-linux.  I'm not sure how other 
distros do it, but the above may give some clues about the original problem.

We do some other things too (we support a separate /usr partition) but the 
ncurses build is at

http://www.linuxfromscratch.org/lfs/view/stable/chapter06/ncurses.html

   -- Bruce

Re: Problem building util-linux without a separate ncursesw include dir

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

On 20 Jan 2018 20:31, Rüdiger Meier wrote:
> On 01/20/2018 07:14 PM, Mike Frysinger wrote:
> > On 20 Jan 2018 18:50, Rüdiger Meier wrote:
> >> On 01/19/2018 07:21 PM, Mike Frysinger wrote:
> >>> On 19 Jan 2018 10:40, Karel Zak wrote:
> >>>> On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
> >>>>> why don't we just support ncurses's pkg-config files as the default ?
> >>>>> $ pkg-config --cflags ncurses
> >>>>> -D_GNU_SOURCE
> >>>>> $ pkg-config --cflags ncursesw
> >>>>> -D_GNU_SOURCE -I/usr/include/ncursesw
> >>>>
> >>>> because pkg-config is not supported by ncurses upstream by default and
> >>>> it's not always the best solution.
> >>>
> >>> you mean upstream's configure script doesn't default it to on.  distros
> >>> can (and many do) simply pass --enable-pc-files to get them.  but i don't
> >>> see how that's relevant to preference when it comes to detection.
> >>>
> >>>> See commit 4c12a334dc4104d16dc06edf51904b08b08fcdfa.
> >>>
> >>> seems like that's trivial to resolve with a compile test rather than
> >>> throwing it all out.  xxx-config scripts provide bad defaults when you
> >>> cross-compile because now the user has to make sure the build's copy
> >>> of ncurses-config don't get used.
> >>>
> >>>> The ncurses detection and variability in distros is horrible. We
> >>>> already tried all possible combinations and always someone complains
> >>>> about the way how we detect ncurses. See mailing list archive for more
> >>>> information.
> >>>
> >>> that's the point of pkg-config.  if someone is having problems because
> >>> they're doing something weird/non-standard, tell them to sort out their
> >>> pkg-config installs.
> >>
> >> non-standard is to have ncurses.pc installed.
> > 
> > that's a silly position to try to take.  you're claiming anything that isn't
> > turned on by default in `./configure` is non-standard ?
> 
> No, as you could have read I'm talking only about --enable-pc-files being non
> standard. Many distros and users are not using it

most distros are enabling it.  Debian & Fedora & openSUSE & Gentoo & ArchLinux
& OpenEmbedded OE and everything based on it are enabling them.  so it's the
common case now, and if that's what it requires for you define something
"standard", then it is standard now.

> and you can't just call them all stupid.

i didn't call anyone stupid.  don't put words in my mouth.

> We have to support this case first.

i didn't say to drop xxx-config usage.  i said it shouldn't come first.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Problem building util-linux without a separate ncursesw include dir

[Karel Zak]

On Thu, Jan 18, 2018 at 09:47:17PM -0500, Mike Frysinger wrote:
> On 01 Aug 2017 09:20, Karel Zak wrote:
> > On Mon, Jul 31, 2017 at 09:46:39PM -0300, Carlos Santos wrote:
> > > > From: "Carlos Santos" <casantos@datacom.ind.br>
> > > > To: util-linux@vger.kernel.org
> > > > Sent: Monday, July 31, 2017 9:12:03 PM
> > > > Subject: Problem building util-linux without a separate ncursesw include dir
> > > 
> > > > of util-linux. Would it be possible to make the location of ncursesw
> > > > headers configurable, instead?
> > 
> > We test for alone ncurses.h and term.h in the for non-wide ncurses.
> > Can you send output from your configure from the current master
> > branch (or v2.30.1)?
> > 
> > > I was thinking on something simple, like https://pastebin.com/VqM9G9yu
> > 
> > Hmm, but you don't distinguish between wide and non-wide ncurses.
> 
> why don't we just support ncurses's pkg-config files as the default ?
> $ pkg-config --cflags ncurses
> -D_GNU_SOURCE
> $ pkg-config --cflags ncursesw
> -D_GNU_SOURCE -I/usr/include/ncursesw
> -mike

BTW, why we have this discussion now (6 months after the change)? Do
have a problem to build util-linux?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com