[bug #66143] build doesn't find Homebrew uchardet on MacOS 14.6.1

[G. Branden Robinson]

Follow-up Comment #24, bug #66143 (group groff):

Well, within a day of my publicly singing the praises of Savannah's
email-based ticket reply feature, it broke.

I've tried twice to update this ticket by that means and nothing happens.

en,

At 2024-09-07T05:06:11-0400, Sven Schober wrote:
> Follow-up Comment #23, bug #66143 (group groff):
> Thanks again for your very long and elaborate answer!

Can't really help myself!  😅

> > I'm assuming that Autoconf doesn't pick it up, hence the failure on
> > macOS to find the uchardet library's header file.
> 
> I did not express myself clear enough: I was talking about the
> homebrew build environment. I can enter it via `brew reinstall -i
> groff`. And it was in that env, that I saw these env variables. And
> there-in I saw that /opt/homebrew/include was "put onto the include
> paths list", meaning, a -I/opt/homebrew/include was appended to the
> clang invocation.
> 
> I just followed up on the question how this homebrew specific variable
> is creating any effect:
> 
> 
> …/tmp/groff-20240905-40241-pj7zgj/groff-1.23.0
> $ grep -i 'HOMEBREW_ISYSTEM_PATHS' -R .
> $
> 
> 
> Nothing. Ok, I'd half expected that. Why would Autoconf consider such
> a homebrew specific variable? But the question remained...

As far as I know, Autoconf _doesn't_ consider it.

It certainly doesn't show up in the Autoconf-generated files on my
system, including "configure", which contains all the feature tests for
the groff build.

> So, homebrew sets HOMEBREW_ISYSTEM_PATHS in its build env and the shim
> puts it onto the include path list. (Btw. googling for
> HOMEBREW_ISYSTEM_PATHS yields exactly two hits for me, none of which
> are documentation, and none of which were helpful to me.)

My hunch is that HOMEBREW_ISYSTEM_PATHS is a blind alley.

> > No, because what if a distribution puts the "uchardet" directory in
> > a weird place that isn't "/usr/include"?
> 
> Yes, like, exactly what homebrew does. :) I was speaking only in the
> context of groff/preconv and it's dependency on uchardet (the "whole
> business" wording was unfortunate). (I would not question the
> motivation and legitimacy of pkg-config in general.)
> 
> I am slowly getting the impression, that /usr/include could be
> considered as a distribution managed include path.

That meshes with my understanding.

> (And homebrew is trying to emulate that with /opt/homebrew/include.)

Seems likely, given that if they mess around with /usr/include, they
risk their stuff being stomped on by Apple.

> I read up in the FHS [1] on /usr/include:
> 
> > This is where all of the system's general-use include files for the
> > C programming language should be placed.
> 
> Mhm, by whom? How is general-use defined?

Don't expect too much of FHS.  It was largely put together by
volunteers.  Standards-writing seems to work best as a compensated
activity.  Which is why tech companies avoid underwriting it.  "How is
this going to make us money?"

Neither is it something the Linux Foundation has elected to spend money
on.

> >> I always understood the c/c++ inclusion mechanism to be simply a
> >> matter of trying all include dirs,
> >
> > Where "all" is probably only "/usr/include", yes.  I don't know off
> > the top of my head how strictly ISO C prescribes this.
> 
> I was including (haha) in my head also stuff given via -I on the
> command-line here.

That describes a typical compilation just fine.

Standardized processes are typically a very small subset of what one
encounters in practice.  A standard is the intersection of the
relatively small number of things that practitioners can agree upon.

> > One thing I do know about that standard is that libc header files,
> > meaning those specified by the standard and locatable via "#include
> > <whatever.h>", do not actually have to exist as files.
> 
> > The compiler is free to interpret such standard header inclusions in
> > a way that they supply some equivalent to the text of such files.
> > This matters for embedded systems, and is in part a consequence of
> > the fact that ISO C does not take on the responsibility of
> > specifying what a file system is.
> 
> Ugh. This, eh, ..., I am having a hard time imagining, what this could
> mean in this context. Probably, this concerns stuff like <stdio.h>,
> <string.h> or such, right?

Right.  I said, "libc header files, meaning those specified by the [ISO
C] standard"...

> But for <uchardet.h> it would probably be safe to assume it is a file?

...which "uchardet.h" is not, so yes, I'd expect it to exist as a plain
file.

I said what I did to avoid saying something so general that it would be
false.

> > I reach the opposite conclusion.  It's pretty obvious that the
> > uchardet library API is wholly unspecified, including the location
> > of its header file.  (I do not say undefined--once you do locate
> > "uchardet.h", it has valid C language declarations.)
> 
> My problem would not have arisen at least, but that is surely a very
> limited perspective. But also on other distributions, it would have
> worked, as pkg-config would have found uchardet and put the correct
> path on the include path list. That was my thinking.

In my opinion, Homebrew should alter its "uchardet.pc" file to support
groff's expectation about where "uchardet.h" is located, because as your
research showed, other projects share that expectation.

An alternative is for the uchardet project to document _their_
expectations, thereby establishing a _specified_ API.  If that then
means that groff needs to change (and to be fair, since as I said,
uchardet's de facto API seems to be fossilized, there seems to be little
prospect of it splitting out a new header file soon), then we can do
adapt.

If they need advice in writing a uchardet(3) man page, I'm prepared to
offer it.

> I have to admit, I often have to read your answers multiple times to
> extract all your meaning from it. :) I will do that. And I will try to
> think about a proposal on what to do. (I mean, after all, it could
> boil down to a INSTALL.REPO sentence: "Beware, when on macos and using
> homebrew, do not > forget to set HOMEBREW_ISYSTEM_PATHS during
> configure.")

It would be more an issue for the "PROBLEMS" file, but yes.  We can
document our way around it.

Regards,
Branden

> {savane: user = 108747; tracker = bugs; item = 66143}


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66143>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature