[bug #66143] build of current master (c9b3c99) fails on MacOS 14.6.1

[G. Branden Robinson]

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

At 2024-09-06T15:03:52-0400, Sven Schober wrote:
> Follow-up Comment #21, bug #66143 (group groff):
>
> So, me again: I found the problem! I called make with CPPFLAGS=-v,
> which displays the exact command line that is executed, in both my
> environments (homebrew and outside).
>
> Inside the homebrew environment, there is a single additional include
> path added: /opt/homebrew/include
>
> And lo and behold:
>
>
> ls -ahl /opt/homebrew/include/ | grep uchar
> lrwxr-xr-x    1 svenschober  admin    41B Feb 13  2023 uchardet ->
> ../Cellar/uchardet/0.0.8/include/uchardet

Aha!

> _That_ is a symlink to the other place, where uchardet is installed,
> and more importantly, _that_ is why an include of the form
> `<uchardet/uchardet.h>` is working:
> `/opt/homebrew/include/uchardet/uchardet.h` is existant.
>
> But not when that include path is missing.

Right.

> I can add that path via:
>
> ../configure --without-x --with-uchardet CPPFLAGS="-I/opt/homebrew/include"
>
>
> But, I ask myself, why this is not necessary in the homebrew env.
>
> I found the following:
>
>
> env | grep include
>
HOMEBREW_INCLUDE_PATHS=/opt/homebrew/opt/readline/include:/opt/homebrew/opt/sqlite/include
>
HOMEBREW_ISYSTEM_PATHS=/opt/homebrew/include:/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers
>
> It seems, they set a variable called HOMEBREW_ISYSTEM_PATHS. But how
configure
> gets to pick that up is still a riddle to me.

I'm assuming that Autoconf _doesn't_ pick it up, hence the failure on
macOS to find the _uchardet_ library's header file.

> But doesn't this mean, my point still stands: the whole pkg-config
> business is superfluous,

No, because what if a distribution puts the "uchardet" directory in a
weird place that isn't "/usr/include"?

> as long as the cpp source references
> `<uchardet/uchardet.h>`?

That just moves the problem.  "uchardet.h" or "uchardet/uchardet.h", if
the system doesn't supply it in /usr/include, odds are that _pkg-config_
will be necessary to locate it.  And nobody, as far as I know is so
prescriptivist about the Filesystem Hierarchy Standard (FHS) that they
require that .h files have names resolvable _only_ from that directory.

> 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.

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.

> one by one and append the inclusion path.

For just about anything that uses any library that isn't libc, the
specification of `-I` is somewhere from strongly encouraged to
mandatory.  /usr/include itself has been getting more crowded with plain
files for decades; as a result the name space collision problem
re-asserts itself.

> If there is no match, we get the error I am getting.  But I could be
> wrong.

I think you're mostly on track.

> I did some further digging and found another project using uchardet
> via uchardets website:
>
>
https://github.com/mpv-player/mpv/blob/0eb5e914d9699b6f7fb91ee383dedadc491b0d7d/misc/charset_conv.c#L67
>
> They also include it without the directory. In this old branch of
> another project the same:
>
>
https://gitlab.gnome.org/World/gedit/libgedit-tepl/-/blob/tepl-3-0/tepl/tepl-file-loader.c
>
> But, I also found counter examples (using the qualified form):
>
>
https://github.com/wang-bin/QtAV/blob/8bb780215bcd4a16d098a2a913d01f83b16193d7/config.tests/uchardet/main.cpp#L21
>
> and
>
>
https://github.com/eranif/codelite/blob/345332fca8ae6d29ca6615dccec81d92525bd6f1/LiteEditor/cl_editor.cpp#L102

Right.  The _uchardet_ authors/maintainers didn't document their API, so
people took guesses.  I suspect that users of that API selected whatever
happened to work on their system, if the first try didn't work, the
second usually did, so "must have been right".

> In summary, I don't know. I now know how to fix my build problem, but
> I have a hunch, that removing the directory prefix would be a
> portability win.

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.)

This unspecified status is common in the early stages of library
development.  The developers don't want to be wedded to mistaken
decisions or held responsible for support of aspects of the interface
that they had reason to reconsider.  They want to be free to delete
functions, change the arguments they take, rename data types, and even
merge or split header files.

Importantly, if the _uchardet_ developers had decided in early days to
split "uchardet.h" into multiple files--maybe they'd want a "uchar.h"
file too--it would be a pain in the butt to go and try to hunt up name
collisions to see if they could claim a particular name.

I reckon that at least some package maintainers, especially those with
hard experience in GNU/Linux distributions, appreciated that the API was
in flux, and so they gave _uchardet_'s header file a sandbox directory.

If someone were to ask:

"Why would you have a subdirectory of /usr/include for just one header
file with the same name (barring the .h suffix) as the directory
itself?"

That'd be why.  People downstream of the _uchardet_ developers had no
idea what the future would hold.

It appears that _uchardet_ began life as a paid development project of
employees of the Mozilla Corporation.  It's possible that these
developers were suddenly "made redundant" and thus "uchardet.h"
"stabilized"--by fossilizing as it was when the pink slips came down,
like the half-finished breakfasts and open newspapers on the kitchen
tables of Pripyat, Ukraine, in April 1986.

That's tech sector capitalism for you--destruction is creative and while
you can't turn a ship on a dime, you can fire people so fast that the
optical Doppler shift is visible to the naked eye.

> Otherwise, why use pkg-config then after all?

To an extent, _pkg-config_ insulates software dependent on a library
from disruptive changes to that library's interface at the coarsest
level (where the header files and library objects are, and what they are
named).

There was, and is, an alternative--writing Autoconf tests to figure
these things out.  But few people find that more reliable, or enjoyable.

Regards,
Branden



    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature