Re: [MacPorts] #71294: p5.34-ffi-platypus @2.90.0 tests using perl5.34 @5.34.3_1 with /usr/bin/cc – shouldn't it use the same tools as MacPorts does?

[MacPorts]

#71294: p5.34-ffi-platypus @2.90.0 tests using perl5.34 @5.34.3_1 with /usr/bin/cc
– shouldn't it use the same tools as MacPorts does?
---------------------------------+------------------------
  Reporter:  ballapete           |      Owner:  (none)
      Type:  defect              |     Status:  new
  Priority:  Normal              |  Milestone:
 Component:  ports               |    Version:  2.10.2
Resolution:                      |   Keywords:  highsierra
      Port:  p5.34-ffi-platypus  |
---------------------------------+------------------------
Changes (by ryandesign):

 * cc: devans@… (removed)
 * cc: dbevans (added)
 * type:  request => defect


Comment:

 perl is designed to keep track of what compiler was used when perl was
 compiled and to use that same compiler when compiling perl modules.

 In MacPorts we consider that aspect of perl's build system to be a design
 flaw and we take steps to circumvent it. We want ports to be
 [wiki:UsingTheRightCompiler using the compiler MacPorts tells them to
 use], not one that one of its dependencies tells it to use.

 Perl still records in its config files what compiler and flags were used
 when compiling perl, but code in the perl5 portgroup tells ports to use
 the compiler MacPorts selected instead of the one that's in the config
 files. And the perl5 portfile replaces the compiler paths in the config
 files with /usr/bin/cc and /usr/bin/c++ so that, in the unlikely event
 that some module build still manages to use the system compiler, it will
 at least find a compiler that exists, even if it is not exactly the one we
 wanted.

 Replying to [ticket:71294 ballapete]:
 > Test passes, but seems to use inadequate means, the system's default C
 compiler, while `port` uses `Clang` to build:
 >
 > {{{
 >   335 :debug:configure CC='/usr/bin/clang'
 >   341 :debug:configure CXX='/usr/bin/clang++'
 > }}}

 How do you know that it has used the system's default C compiler instead
 of clang? The above are the environment variables MacPorts has set, and
 the ones the perl5 portgroup should be shoving into the build.

 With Xcode 5 and later, /usr/bin/cc ''is'' clang and /usr/bin/c++ ''is''
 clang++ so even if the default compilers are inadvertently used by some
 module, it often works. But you are correct when you point out later that
 sometimes perl or modules might need to be built with a newer compiler
 than the system compiler so it's important that the build uses right
 compiler MacPorts tells it to.

 > {{{
 > CC t/ffi/align.c
 > CC t/ffi/align_array.c
 > CC t/ffi/align_fixed.c
 > CC t/ffi/align_string.c
 > CC t/ffi/basic.c
 > CC t/ffi/closure.c
 > CC t/ffi/color.c
 > CC t/ffi/complex_double.c
 > CC t/ffi/complex_float.c
 > CC t/ffi/double.c
 > CC t/ffi/float.c
 > CC t/ffi/gh117.c
 > CC t/ffi/gh174.c
 > CC t/ffi/longdouble.c
 > CC t/ffi/memcmp4.c
 > CC t/ffi/meta.c
 > CC t/ffi/pointer.c
 > CC t/ffi/record.c
 > CC t/ffi/sint16.c
 > CC t/ffi/sint32.c
 > CC t/ffi/sint64.c
 > CC t/ffi/sint8.c
 > CC t/ffi/string.c
 > CC t/ffi/string_array.c
 > CC t/ffi/uint16.c
 > CC t/ffi/uint32.c
 > CC t/ffi/uint64.c
 > CC t/ffi/uint8.c
 > CC t/ffi/variadic.c
 > LD t/ffi/libtest.dylib
 > }}}

 These lines show that these files were compiled and linked but because
 they are "silent rules" they don't show what compiler was used. For this
 reason, we would like ports to use "verbose rules" when building instead.
 This could be something specific to this port, or it could be a general
 problem in the perl5 portgroup when building additional files for the test
 phase.

 > {{{
 > # [PLATFORM]
 > # osname            : darwin
 > # cc                : /usr/bin/cc
 > # cxx               : c++
 > # cxxld             : /usr/bin/cc
 > # for               : gfortran
 > # ld                : /usr/bin/cc
 > # ccflags           : -fno-common -DPERL_DARWIN -pipe -Os -fno-strict-
 aliasing -fstack-protector-strong -I/opt/local/include
 -DPERL_USE_SAFE_PUTENV -O3
 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_perl_p5
 -ffi-platypus/p5.34-ffi-platypus/work/FFI-
 Platypus-2.09/blib/lib/auto/share/dist/FFI-Platypus/include
 > # ldflags           : -dynamiclib -undefined dynamic_lookup
 -L/opt/local/lib -Wl,-headerpad_max_install_names -fstack-protector-strong
 > }}}

 The value of `cc` here looks like the value from the config file that this
 build is printing for your information. (It doesn't necessarily mean it
 actually used that compiler to compile anything.) The value of `cxx` look
 wrong, not having a full path. The value of `cxxld` looks wrong, being a C
 compiler and not a C++ compiler.

 > There are also differences in other flags used:
 >
 > {{{
 >   338 :debug:configure CFLAGS='-pipe -Os -arch x86_64'
 >   342 :debug:configure CXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'
 >   344 :debug:configure F90FLAGS='-pipe -Os -m64'
 >   345 :debug:configure FCFLAGS='-pipe -Os -m64'
 >   346 :debug:configure FFLAGS='-pipe -Os -m64'
 >   349 :debug:configure LDFLAGS='-L/opt/local/lib
 -Wl,-headerpad_max_install_names -arch x86_64'
 > }}}

 Differences between these flags (which MacPorts sets in the environment
 variables and wants ports to use) and what?

 > There are more `Perl modules` that a require a C compiler and use "some"
 flags, options, switches… (need to investigate today/tomorrow) Shouldn't
 all these modules use the same tools and setups/configurtions as Perl
 itself?

 The developers of perl say yes, while we say no. The perl5 portgroup
 arranges what flags should be used by module builds. It is possible that
 some module builds are ignoring this and getting compiler or flags from
 the config file; if so, that would be a bug to be fixed in those modules.

-- 
Ticket URL: <https://trac.macports.org/ticket/71294#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS