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

[Sven Schober]

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

Hi Branden!

Thanks again for your very long and elaborate answer!

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

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


$ which clang++
/opt/homebrew/Library/Homebrew/shims/mac/super/clang++


Aha! A shim! A mac super shim. :) 


grep -i 'ISYSTEM_PATHS' /opt/homebrew/Library/Homebrew/shims/mac/super/clang++
-C5
    end
  end

  def refurbished_args
    @lset = Set.new(library_paths + system_library_paths)
    @iset = Set.new(isystem_paths + include_paths)

    args = []
    enum = @args.each

    loop do
--
    args
  end

  def cppflags
    args = []
    args += path_flags("-isystem", isystem_paths) + path_flags("-I",
include_paths)
    # Add -nostdinc when building against glibc@2.13 to avoid mixing system
and brewed glibc headers.
    args << "-nostdinc" if @deps.include?("glibc@2.13")
    # Ideally this would be -ffile-prefix-map, but that requires a minimum of
GCC 8, LLVM Clang 10 or Apple Clang 12
    # and detecting the version dynamically based on what `HOMEBREW_CC` may
have been rewritten to point to is awkward
    args << "-fdebug-prefix-map=#{formula_buildpath}=." if formula_buildpath
--
    else
      args
    end
  end

  def isystem_paths
    path_split("HOMEBREW_ISYSTEM_PATHS")
  end

  def include_paths
    path_split("HOMEBREW_INCLUDE_PATHS")
  end


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

>> 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"?

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. (And homebrew is trying to emulate that
with /opt/homebrew/include.) 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?

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

> 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? But for <uchardet.h> it would probably be safe to assume it is a
file?

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

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.

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

[1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s05.html


    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature