#55884: mandoc @1.14.3: not using the right compiler
Rainer Müller
raimue at macports.org
Wed Feb 28 16:36:38 UTC 2018
On 2018-02-28 08:52, Jan Stary wrote:
> The ticket is closed, so I will continue here.
>
>> Actually it's not specific to the universal variant. Rather, the problem
>> is that the port is not UsingTheRightCompiler.
>
> mandoc's ./configure sets CC to whatever make(1) thinks CC is:
> CC=`printf "all:\\n\\t at echo \\\$(CC)\\n" | env -i make -sf -`
> Why exactly is it "not the right compiler"?
As env -i clears the environment, how is this supposed to work at all?
This does not respect CC in the environment, which is what MacPorts
usually does.
$ export CC=foo
$ printf "all:\\n\\t at echo \\\$(CC)\\n" | env -i make -sf -
cc
> Maybe I don't get the whole premise:
>
> If not instructed otherwise, most software builds C code using "cc" or
> "gcc". But "/usr/bin/cc" and "/usr/bin/gcc" are not specific
> compilers; they're symlinks to some suitable default compiler, but it
> varies based on Xcode version. Users might also have created
> a "/opt/local/bin/gcc" symlink, pointing to any installed compiler, by
> using "port select --set gcc". So we cannot rely on "cc" oc "gcc"
> being any particular compiler.
>
> Yes, we cannot, and that's OK because we should not, _by_default_.
> This is a UNIX system compiling C code. Call 'cc'. Duh.
>
> It's true that /usr/bin/cc is a symlink to some suitable default compiler.
> So call that, thus calling a suitable default compiler, _by_default_.
You are already assuming that 'cc' is /usr/bin/cc. If anyone has a
/opt/local/bin/cc, it might be a different compiler.
In general, we do not want to use what the user selected as their
preferred compiler, but what MacPorts selected to compile this port.
This is more important for binary names such as cpp or c++, which are
actually modified by 'port select gcc'.
> Yes, there are ports that do need to call some particular compiler,
> but it's those ports' job then to find and use that.
Unfortunately, it is not that easy. Ports need to respect what is set in
the environment. Using the right compiler is especially important when
compiling C++, as that also controls which standard library will be
linked. Historically, Apple used to ship gcc, llvm-gcc, and clang and on
some macOS version.
>> I had my MacPorts configured to error out if `cc` is used
>> using the method described at UsingTheRightCompiler#testing.
>
> Why would you do that?
>
> Mandoc is extremely portable. I have yet to see a UNIX system where
> it does not build. Except here: of course it "breaks" if you explicitly
> make it impossible to run 'cc', which is the right compiler.
This setup is a good idea for developers to catch ports that are not
respecting the environment variables for compiler selection.
> BTW, this is how configure.cc is described in the guide:
>
> configure.cc
> Set CC compiler flags for selecting a C compiler.
> Default: ???
> Example:
>
> "compiler flags for selecting a compiler"?
Looks like an old copy & paste mistake to me. I committed a fix. [1]
Ryan was even faster to notice than me typing this mail. :-)
>> Perhaps the portfile code that set `CC`
>> that was removed in [14f7de9e9ad521cce6389678675706e8593b9834/macports-
>> ports] was needed after all.
>
> It is only "needed" if you make it artificially impossible
> to call 'cc' (or whatever the port ./configures to be CC).
>
> So: because ports must not call 'cc' on your system,
> let's complicate the mandoc Portfile for everyone.
Build systems are supposed to follow CC in the environment. The whole
point of options like configure.cc is that they are respected when
building the port.
As an alternative to pass compiler in environment variables would be
generating wrapper scripts that use the right compiler as selected by
MacPorts. This is the way other projects like Fink do it. Then the usual
names cc/gcc/clang/... will always end up at the intended binary by
putting them to the front of PATH. However, this is a long-standing
issue and I am not aware anyone was working on this. Therefore, build
systems still need to be patched to honor CC from the environment.
Rainer
[1]
https://github.com/macports/macports-guide/commit/5a6f3a7f7ca016f22f8ac7aa0f497860680302de
More information about the macports-dev
mailing list