Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

5.21.8 fails compiling with icc #14503

Open
p5pRT opened this issue Feb 14, 2015 · 22 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Feb 14, 2015

Migrated from rt.perl.org#123831 (status was 'open')

Searchable as RT123831$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 14, 2015

From rehsack@gmail.com

Created by rehsack@gmail.com

To prove my XS code with additional compilers, I retry compiling dev-perl using icc.
I hoped get improved results since 44b62df ...

Unfortunately, I got​:
icc -c -DPERL_CORE -fno-common -DPERL_DARWIN -O3 util.c
util.c(4556)​: warning #69​: integer conversion resulted in truncation
  u += SEED_C5 * (U32)PTR2UV(&when);
  ^

icc -c -DPERL_CORE -fno-common -DPERL_DARWIN -O3 sv.c
sv.c(3162)​: error​: expression must be an integral constant expression
  SNPRINTF_G(SvNVX(sv), s, SvLEN(sv), NV_DIG);
  ^

sv.c(11300)​: error​: expression must be an integral constant expression
  SNPRINTF_G(nv, ebuf, size, digits);
  ^

sv.c(12284)​: error​: expression must be an integral constant expression
  SNPRINTF_G(fv, PL_efloatbuf, PL_efloatsize, precis);
  ^

compilation aborted for sv.c (code 2)

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.20.1:

Configured by sno at Mon Dec  8 12:39:24 CET 2014.

Summary of my perl5 (revision 5 version 20 subversion 1) configuration:
   
  Platform:
    osname=darwin, osvers=13.4.0, archname=darwin-2level
    uname='darwin ernie.muppets.liwing.de 13.4.0 darwin kernel version 13.4.0: sun aug 17 19:50:11 pdt 2014; root:xnu-2422.115.4~1release_x86_64 x86_64 '
    config_args='-de -Dprefix=/Users/sno/perl5/perlbrew/perls/perl-5.20.1 -Aeval:scriptdir=/Users/sno/perl5/perlbrew/perls/perl-5.20.1/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector',
    optimize='-O3',
    cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector'
    ccversion='', gccversion='4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector'
    libpth=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib /usr/lib
    libs=-ldbm -ldl -lm -lutil -lc
    perllibs=-ldl -lm -lutil -lc
    libc=, so=dylib, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -fstack-protector'



@INC for perl 5.20.1:
    /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1/darwin-2level
    /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/site_perl/5.20.1
    /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.1/darwin-2level
    /Users/sno/perl5/perlbrew/perls/perl-5.20.1/lib/5.20.1
    .


Environment for perl 5.20.1:
    DYLD_LIBRARY_PATH (unset)
    HOME=/Users/sno
    LANG=de_DE.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/Users/sno/perl5/perlbrew/bin:/Users/sno/perl5/perlbrew/perls/perl-5.20.1/bin:/Users/sno/bin:/opt/pkg/bin:/opt/pkg/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
    PERLBREW_BASHRC_VERSION=0.54
    PERLBREW_HOME=/Users/sno/.perlbrew
    PERLBREW_MANPATH=/Users/sno/perl5/perlbrew/perls/perl-5.20.1/man
    PERLBREW_PATH=/Users/sno/perl5/perlbrew/bin:/Users/sno/perl5/perlbrew/perls/perl-5.20.1/bin
    PERLBREW_PERL=perl-5.20.1
    PERLBREW_ROOT=/Users/sno/perl5/perlbrew
    PERLBREW_VERSION=0.64
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 14, 2015

From rehsack@gmail.com

Following patch solves the issue locally​:

$ git diff

Inline Patch
diff --git a/perl.h b/perl.h
index 9976f86..0b2dfa8 100644
--- a/perl.h
+++ b/perl.h
@@ -378,7 +378,7 @@
  * __typeof__ and nothing else.
  */
 #ifndef PERL_UNUSED_RESULT
-#  if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+#  if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
 #    define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v); (void)sizeof(z); } STMT_END
 #  else
 #    define PERL_UNUSED_RESULT(v) ((void)(v))

It is very likely that xlc in GNU mode has same issues - Tux, can you verify that?

Cheers,
Jens

Am 14.02.2015 um 12​:05 schrieb perlbug-followup@​perl.org​:

Greetings,

This message has been automatically generated in response to the
creation of a perl bug report regarding​:
"5.21.8 fails compiling with icc".

There is no need to reply to this message right now. Your ticket has been
assigned an ID of [perl #123831].

You can view your ticket at
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=123831

Within the next 24 to 72 hours, your message will be posted to the Perl 5 Porters mailing list. Please be patient!

Please include the string​:

[perl #123831]

in the subject line of all future correspondence about this issue. To do so,
you may reply to this message (please delete unnecessary quotes and text.)

Thank you,
perlbug-followup@​perl.org

-------------------------------------------------------------------------
Return-Path​: <rehsack@​gmail.com>
Reply-To​: rehsack@​gmail.com
From rehsack@​gmail.com Sat Feb 14 11​:05​:43 2015
Subject​: 5.21.8 fails compiling with icc
Date​: Sat, 14 Feb 2015 12​:05​:31 +0100 (CET)
Message-ID​: <5.20.1_21867_1423911577@​ernie.muppets.liwing.de>
Delivered-To​: rt-perl5@​rt.perl.org
Delivered-To​: perlbug@​perl.org
To​: perlbug@​perl.org
Received​: (qmail 4350 invoked by uid 225); 14 Feb 2015 11​:05​:41 -0000
Received​: (qmail 4346 invoked by alias); 14 Feb 2015 11​:05​:41 -0000
Received​: from p578b540c.dip0.t-ipconnect.de (HELO ernie.muppets.liwing.de) (87.139.84.12) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sat, 14 Feb 2015 03​:05​:37 -0800
Received​: by ernie.muppets.liwing.de (Postfix, from userid 501) id 6F6747132CF7; Sat, 14 Feb 2015 12​:05​:31 +0100 (CET)
CC​: rehsack@​gmail.com
From​: rehsack@​gmail.com
X-Spam-Status​: No, hits=-4.3 required=8.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,PERLBUG_CONF,SPF_SOFTFAIL
X-Spam-Check-BY​: la.mx.develooper.com
X-RT-Original-Encoding​: ascii
content-type​: text/plain; charset="utf-8"
X-RT-Interface​: Email

--
Jens Rehsack
rehsack@​gmail.com

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 14, 2015

From @jkeenan

On Sat Feb 14 03​:05​:51 2015, rehsack@​gmail.com wrote​:

This is a bug report for perl from rehsack@​gmail.com,
generated with the help of perlbug 1.40 running under perl 5.20.1.

-----------------------------------------------------------------
[Please describe your issue here]

To prove my XS code with additional compilers, I retry compiling dev-
perl using icc.
I hoped get improved results since 44b62df ...

Were you able to compile perl with the ICC compiler on this platform *before* 44b62df?

In other words, was 44b62df a breaking commit for a compiler-platform combination on which you previously were successful?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 14, 2015

The RT System itself - Status changed from 'new' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 15, 2015

From rehsack@gmail.com

Am 15.02.2015 um 00​:30 schrieb James E Keenan via RT <perlbug-followup@​perl.org>​:

On Sat Feb 14 03​:05​:51 2015, rehsack@​gmail.com wrote​:

This is a bug report for perl from rehsack@​gmail.com,
generated with the help of perlbug 1.40 running under perl 5.20.1.

-----------------------------------------------------------------
[Please describe your issue here]

To prove my XS code with additional compilers, I retry compiling dev-
perl using icc.
I hoped get improved results since 44b62df ...

Were you able to compile perl with the ICC compiler on this platform *before* 44b62df?

In other words, was 44b62df a breaking commit for a compiler-platform combination on which you previously were successful?

Thank you very much.

I'm able _since_ 44b62df compiling perl using icc.
But compared to earlier attempts, b469f1e break it.

That's why my follow-up saying

git diff

Inline Patch
diff --git a/perl.h b/perl.h
index 9976f86..0b2dfa8 100644
--- a/perl.h
+++ b/perl.h
@@ -378,7 +378,7 @@
  * __typeof__ and nothing else.
  */
 #ifndef PERL_UNUSED_RESULT
-#  if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+#  if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
 #    define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v); (void)sizeof(z); } STMT_END
 #  else
 #    define PERL_UNUSED_RESULT(v) ((void)(v))

fixes the compile issue.

You have to compile perl using

./Configure -de -Dcc=icc -Doptimize="-O3 -xHost" -Dld="env MACOSX_DEPLOYMENT_TARGET=10.9 icc -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib" -Dusedevel -Dprefix=...

The handling of ld is kind-of unfortunate (Configure determines "env MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..."

Cheers
--
Jens Rehsack
rehsack@​gmail.com

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 15, 2015

From @Leont

On Sun, Feb 15, 2015 at 10​:18 AM, Jens Rehsack <rehsack@​gmail.com> wrote​:

The handling of ld is kind-of unfortunate (Configure determines "env
MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..."

Yeah, that whole logic stinks, it really should be replaced by a more
sensible default :-/

Leon

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 17, 2015

From @tonycoz

On Sat Feb 14 03​:40​:51 2015, rehsack@​gmail.com wrote​:

Following patch solves the issue locally​:

$ git diff
diff --git a/perl.h b/perl.h
index 9976f86..0b2dfa8 100644
--- a/perl.h
+++ b/perl.h
@​@​ -378,7 +378,7 @​@​
* __typeof__ and nothing else.
*/
#ifndef PERL_UNUSED_RESULT
-# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+# if defined(__GNUC__) && !defined(__INTEL_COMPILER) &&
defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
# define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v);
(void)sizeof(z); } STMT_END
# else
# define PERL_UNUSED_RESULT(v) ((void)(v))

The linux hints pass -no-gcc to ICC, does that help here?

Tony

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 21, 2015

From greg@blekko.com

On Sun, Feb 15, 2015 at 10​:18​:09AM +0100, Jens Rehsack wrote​:

-# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)

Did you consider reporting it as a bug? If a compiler defines __GNUC__
and then doesn't behave like it, they'll probably fix it as a bug.

-- greg

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 21, 2015

From greg@blekko.com

On Fri, Feb 20, 2015 at 08​:53​:44PM -0800, Greg Lindahl wrote​:

On Sun, Feb 15, 2015 at 10​:18​:09AM +0100, Jens Rehsack wrote​:

-# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)

Did you consider reporting it as a bug? If a compiler defines __GNUC__
and then doesn't behave like it, they'll probably fix it as a bug.

To Intel, I mean.

-- greg

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 22, 2015

From rehsack@gmail.com

Am 17.02.2015 um 01​:49 schrieb Tony Cook via RT <perlbug-followup@​perl.org>​:

On Sat Feb 14 03​:40​:51 2015, rehsack@​gmail.com wrote​:

Following patch solves the issue locally​:

$ git diff
diff --git a/perl.h b/perl.h
index 9976f86..0b2dfa8 100644
--- a/perl.h
+++ b/perl.h
@​@​ -378,7 +378,7 @​@​
* __typeof__ and nothing else.
*/
#ifndef PERL_UNUSED_RESULT
-# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+# if defined(__GNUC__) && !defined(__INTEL_COMPILER) &&
defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
# define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v);
(void)sizeof(z); } STMT_END
# else
# define PERL_UNUSED_RESULT(v) ((void)(v))

The linux hints pass -no-gcc to ICC, does that help here?

I gave it a shot​:

$ sh Configure -de -Dusedevel -Dprefix=$PERLBREW_ROOT/perls/perl-5.21.8 -Dcc="icc -no-gcc" -Dld="icc" -Doptimize="-O3 -xHost"
Checking to see how big your file offsets are...
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/types.h(75),
  from try.c(1)​:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/cdefs.h(81)​: warning #1224​: #warning directive​: "Unsupported compiler detected"
  #warning "Unsupported compiler detected"
  ^
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/_endian.h(130),
  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/i386/endian.h(99),
  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/machine/endian.h(35),
  from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/sys/types.h(81),
  from try.c(3)​:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/libkern/_OSByteOrder.h(113)​: error​: identifier "uint64_t" is undefined
  uint64_t
  ^

So no, I don't think it'll help here ;)

--
Jens Rehsack
rehsack@​gmail.com

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 22, 2015

From rehsack@gmail.com

Am 21.02.2015 um 05​:54 schrieb greg@​blekko.com via RT <perlbug-followup@​perl.org>​:

On Fri, Feb 20, 2015 at 08​:53​:44PM -0800, Greg Lindahl wrote​:

On Sun, Feb 15, 2015 at 10​:18​:09AM +0100, Jens Rehsack wrote​:

-# if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+# if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)

Did you consider reporting it as a bug? If a compiler defines __GNUC__
and then doesn't behave like it, they'll probably fix it as a bug.

To Intel, I mean.

And how does this position helps out getting Perl compiled on OS X using icc?

My position is very easy​: even two gcc's might support different extensions.
Wanna use an extension, probe for it.

So yes, when I file the feedback to Intel and ask for renewal of the noncom-license
for continuing work, eg. for MoarVM to improve Perl6, I will definitively name this
issue.

Cheers
--
Jens Rehsack
rehsack@​gmail.com

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 22, 2015

From rehsack@gmail.com

Am 15.02.2015 um 12​:26 schrieb Leon Timmermans <fawaka@​gmail.com>​:

On Sun, Feb 15, 2015 at 10​:18 AM, Jens Rehsack <rehsack@​gmail.com> wrote​:
The handling of ld is kind-of unfortunate (Configure determines "env MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..."

Yeah, that whole logic stinks, it really should be replaced by a more sensible default :-/

Following https://software.intel.com/en-us/articles/performance-tools-for-software-developers-compatibility-of-intel-compiler-for-mac-os-x-and-xcode I updated my icc to 2015 Update 2, which reduces a lot of extra parameters. So now, with both attached patches, it'll compiles and tests fine using​:

$ sh Configure -de -Dusedevel -Dprefix=$PERLBREW_ROOT/perls/... -Dcc=icc -Dld=icc -Doptimize="-O3 -xHost"

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 22, 2015

From rehsack@gmail.com

0001-Explicitely-exclude-icc-from-unused-result-improve.patch
From b525b197136240b9c8d62196a7f75998d8afade3 Mon Sep 17 00:00:00 2001
From: Jens Rehsack <sno@netbsd.org>
Date: Sun, 22 Feb 2015 14:08:28 +0100
Subject: [PATCH 1/2] Explicitely exclude icc from unused result improve

Since Apple designed the system includes and libraries working with CLang
and special versions of gcc > 4 (see quote in $SDK_PATH/usr/include/sys/cdefs.h
line 78 ff), it is eager a workaround and should result in testing for the
availablity of the __typeof__ extension (mind the big base of platform
specific gcc's out there, eg. Caium's gcc suite for Octeon Processors or
here found Apple's patchsets to their own gcc).

Signed-off-by: Jens Rehsack <sno@netbsd.org>
---
 perl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl.h b/perl.h
index b3b77ba..9c2629c 100644
--- a/perl.h
+++ b/perl.h
@@ -378,7 +378,7 @@
  * __typeof__ and nothing else.
  */
 #ifndef PERL_UNUSED_RESULT
-#  if defined(__GNUC__) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
+#  if defined(__GNUC__) && !defined(__INTEL_COMPILER) && defined(HASATTRIBUTE_WARN_UNUSED_RESULT)
 #    define PERL_UNUSED_RESULT(v) STMT_START { __typeof__(v) z = (v); (void)sizeof(z); } STMT_END
 #  else
 #    define PERL_UNUSED_RESULT(v) ((void)(v))
-- 
1.9.3 (Apple Git-50)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 22, 2015

From rehsack@gmail.com

0002-very-first-step-to-tidy-up-mess-around-sdk-to-use.patch
From 832beb9955b992afa044daafc502f790bb49f874 Mon Sep 17 00:00:00 2001
From: Jens Rehsack <sno@netbsd.org>
Date: Sun, 22 Feb 2015 14:23:33 +0100
Subject: [PATCH 2/2] very first step to tidy up mess around sdk to use

According to [1] and how Perl and most XS modules are implemented, none of
them are using conditionals to prove API availability. Therefore, it's
reasonable to rely on the sdk available for the system.

For future improvements, this hint's file should distinguish between SDKROOT
for the base-sdk to use and MACOSX_DEPLOYMENT_SDK for weak linking following
[2]. But it's important to add appropriate environment variables to $cc
invocation, either.

1) https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
2) http://stackoverflow.com/questions/13964742/sdkroot-path-for-latest-sdk

Signed-off-by: Jens Rehsack <sno@netbsd.org>
---
 hints/darwin.sh | 37 +++++++++++++++++++++++++++++++++++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/hints/darwin.sh b/hints/darwin.sh
index fec05fd..9437fc2 100644
--- a/hints/darwin.sh
+++ b/hints/darwin.sh
@@ -3,6 +3,26 @@
 # Wilfredo Sanchez <wsanchez@wsanchez.net>
 ##
 
+# table from pkgsrc/mk/platform/Darwin.mk
+# OS, Kernel, Xcode Version
+# Note that Xcode gets updates on older systems sometimes.
+# pkgsrc generally expects that the most up-to-date xcode available for
+# an OS version is installed
+#
+# Codename	OS	Kernel	Xcode
+# Cheetah	10.0.x	1.3.1
+# Puma		10.1	1.4.1
+#		10.1.x	5.x.y
+# Jaguar	10.2.x	6.x.y
+# Panther	10.3.x	7.x.y
+# Tiger		10.4.x	8.x.y	2.x (gcc 4.0, 4.0.1 from 2.2)
+# Leopard	10.5.x	9.x.y	3.x (gcc 4.0.1, 4.0.1 and 4.2.1 from 3.1)
+# Snow Leopard	10.6.x	10.x.y	3.2+ (gcc 4.0.1 and 4.2.1)
+# Lion		10.7.x	11.x.y	4.1 (llvm gcc 4.2.1)
+# Mountain Lion	10.8.x	12.x.y	4.5 (llvm gcc 4.2.1)
+# Mavericks	10.9.x	13.x.y	6 (llvm clang 6.0)
+# Yosemite	10.10.x	14.x.y	6 (llvm clang 6.0)
+
 ##
 # Paths
 ##
@@ -205,8 +225,21 @@ case "$osvers" in
    # https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
    lddlflags="${ldflags} -bundle -undefined dynamic_lookup"
    case "$ld" in
-       *MACOSX_DEVELOPMENT_TARGET*) ;;
-       *) ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;;
+       *MACOSX_DEPLOYMENT_TARGET*) ;;
+       *)
+           if test -x /usr/bin/xcrun; then
+               SDK_VERSION="`/usr/bin/xcrun --show-sdk-version 2>/dev/null`"
+           else
+               # one with ppc mac and/or *Leopard x86 should add patterns for both
+               # if ccflags/ldflags contain "-m32", appropriate fallback should be chosen either
+               # otherwise: packaging people could provide suitable ld command
+               case "`uname -m`" in
+                   *x86_64*) SDK_VERSION="10.7" ;;
+                   *) SDK_VERSION="10.3" ;;
+               esac
+           fi
+           ld="env MACOSX_DEPLOYMENT_TARGET=${SDK_VERSION} ${ld}"
+           ;;
    esac
    ;;
 esac
-- 
1.9.3 (Apple Git-50)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Feb 22, 2015

From rehsack@gmail.com

$ make
$ make test
Failed 1 test out of 2265, 99.96% okay.
  opbasic/arith.t

Since on Linux a lot more compilers are jumping around, I strongly suggest adding a probe whether __typeof__(x) is supported by compiler or not (Config​::AutoConf provides a compile_if_else() for that ;))

--
Jens Rehsack
rehsack@​gmail.com

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 8, 2015

From @jhi

Firslyt, regarding the ICC vs __typeof__ part​:

As Tony said, proper Configure scan for a correctly working __typeof__ would be the right fix. (Because the problem is that icc claims to be gcc-like, but doesn't seem to have similarly functioning __typeof__.) However, there are two snags in that plan​: (1) what constitutes a correctly working __typeof__? I quickly tried basic use of __typeof__ in couple of iccs I could get my hands into and they worked as expected. So there are degrees to workingness. (2) the closeness of 5.22 makes me dubious to starting to iterate on Configure, in general, and in particular for __typeof__ since there seems to be degrees of functionality (see the previous item), and because there seems to be many releases of ICC to test (not to mention other compilers on other platforms).

Summary​: in short term, I would support applying the not-ICC test for the use of __typeof__. However, since that doesn't seem to fully resolve the problems with ICC on *

Secondly, regarding the darwin hints part of this change.

Disclaimer​: I'm not really an OSX programmer either, except in the role of compiling opensource UNIXy stuff on it... but after re-reading

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html (mentioned in hints/darwin.sh)
http​://stackoverflow.com/questions/2923502/what-does-macosx-version-min-imply
http​://stackoverflow.com/questions/25352389/difference-between-macosx-deployment-target-and-mmacosx-version-min-compiler-op

I would say the choice is between

(1) backward compatibility​: building a binary that will work in all the releases since 10.x
(2) new shininess​: building a binary that will work with the currently installed SDK, and releases thereafter

I would lean towards the keeping existing state of things, backward compatibility, for the default. If packagers / people building their own want the new shiny, they can specify a different OS level.

That being said, the suggested patch for this looks like a nice start for automatically doing the "new shiny". It just needs to be made somehow optional.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Mar 8, 2015

From rehsack@gmail.com

Am 08.03.2015 um 15​:00 schrieb Jarkko Hietaniemi via RT <perlbug-followup@​perl.org>​:

Firslyt, regarding the ICC vs __typeof__ part​:

As Tony said, proper Configure scan for a correctly working __typeof__ would be the right fix. (Because the problem is that icc claims to be gcc-like, but doesn't seem to have similarly functioning __typeof__.) However, there are two snags in that plan​: (1) what constitutes a correctly working __typeof__? I quickly tried basic use of __typeof__ in couple of iccs I could get my hands into and they worked as expected. So there are degrees to workingness. (2) the closeness of 5.22 makes me dubious to starting to iterate on Configure, in general, and in particular for __typeof__ since there seems to be degrees of functionality (see the previous item), and because there seems to be many releases of ICC to test (not to mention other compilers on other platforms).

Summary​: in short term, I would support applying the not-ICC test for the use of __typeof__. However, since that doesn't seem to fully resolve the problems with ICC on *

I agree a prove for __typeof__ is the right way to do it. But likely for 5.24 :(

Secondly, regarding the darwin hints part of this change.

Disclaimer​: I'm not really an OSX programmer either, except in the role of compiling opensource UNIXy stuff on it... but after re-reading

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html (mentioned in hints/darwin.sh)
http​://stackoverflow.com/questions/2923502/what-does-macosx-version-min-imply
http​://stackoverflow.com/questions/25352389/difference-between-macosx-deployment-target-and-mmacosx-version-min-compiler-op

I would say the choice is between

(1) backward compatibility​: building a binary that will work in all the releases since 10.x
(2) new shininess​: building a binary that will work with the currently installed SDK, and releases thereafter

I would lean towards the keeping existing state of things, backward compatibility, for the default. If packagers / people building their own want the new shiny, they can specify a different OS level.

That being said, the suggested patch for this looks like a nice start for automatically doing the "new shiny". It just needs to be made somehow optional.

It is "optional" when one who want (1) simply defines MACOSX_DEPLOYMENT_TARGET=10.3 and the really correct -arch values in ccflags and ldflags.
I fear, (1) is much farther away than it looks like ;)

Cheers
--
Jens Rehsack
rehsack@​gmail.com

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 2, 2015

From @tonycoz

On Sun Mar 08 10​:20​:11 2015, rehsack@​gmail.com wrote​:

Am 08.03.2015 um 15​:00 schrieb Jarkko Hietaniemi via RT <perlbug-
followup@​perl.org>​:

Firslyt, regarding the ICC vs __typeof__ part​:

As Tony said, proper Configure scan for a correctly working
__typeof__ would be the right fix. (Because the problem is that icc
claims to be gcc-like, but doesn't seem to have similarly functioning
__typeof__.) However, there are two snags in that plan​: (1) what
constitutes a correctly working __typeof__? I quickly tried basic
use of __typeof__ in couple of iccs I could get my hands into and
they worked as expected. So there are degrees to workingness. (2)
the closeness of 5.22 makes me dubious to starting to iterate on
Configure, in general, and in particular for __typeof__ since there
seems to be degrees of functionality (see the previous item), and
because there seems to be many releases of ICC to test (not to
mention other compilers on other platforms).

Summary​: in short term, I would support applying the not-ICC test for
the use of __typeof__. However, since that doesn't seem to fully
resolve the problems with ICC on *

I agree a prove for __typeof__ is the right way to do it. But likely
for 5.24 :(

Do you have simple sample __typeof__ code that fails for Intel C but succeeds for gcc?

From Jarkko's comment above basic use of __typeof__ seems to work ok in the icc he tried, so I suspect we need more than just a basic __typeof__ test.

Tony

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 2, 2015

From rehsack@gmail.com

Am 02.09.2015 um 04​:05 schrieb Tony Cook via RT <perlbug-followup@​perl.org>​:

On Sun Mar 08 10​:20​:11 2015, rehsack@​gmail.com wrote​:

Am 08.03.2015 um 15​:00 schrieb Jarkko Hietaniemi via RT <perlbug-
followup@​perl.org>​:

Firslyt, regarding the ICC vs __typeof__ part​:

As Tony said, proper Configure scan for a correctly working
__typeof__ would be the right fix. (Because the problem is that icc
claims to be gcc-like, but doesn't seem to have similarly functioning
__typeof__.) However, there are two snags in that plan​: (1) what
constitutes a correctly working __typeof__? I quickly tried basic
use of __typeof__ in couple of iccs I could get my hands into and
they worked as expected. So there are degrees to workingness. (2)
the closeness of 5.22 makes me dubious to starting to iterate on
Configure, in general, and in particular for __typeof__ since there
seems to be degrees of functionality (see the previous item), and
because there seems to be many releases of ICC to test (not to
mention other compilers on other platforms).

Summary​: in short term, I would support applying the not-ICC test for
the use of __typeof__. However, since that doesn't seem to fully
resolve the problems with ICC on *

I agree a prove for __typeof__ is the right way to do it. But likely
for 5.24 :(

Do you have simple sample __typeof__ code that fails for Intel C but succeeds for gcc?

From Jarkko's comment above basic use of __typeof__ seems to work ok in the icc he tried, so I suspect we need more than just a basic __typeof__ test.

Intel's documentation says, it doesn't work at all. My tests confirm that.
But I didn't retry with most recent update and my license ends.

A simple __typeof__ test in Configure.sh should prove whether the compiler
is able to support __typeof__ - and the #ifdef should distinguish
between HAVE__TYPEOF_ and don't.

Cheers
--
Jens Rehsack - rehsack@​gmail.com

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 14, 2015

From @jkeenan

Last night Tony C. asked me on IRC to try out the second of the two patches in this ticket on my older Darwin system. Perl built successfully and passed all tests with this patch EXCEPT t/porting/authors.t

Thank you very much.
Jim Keenan

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 23, 2016

From @jkeenan

On Wed Oct 14 04​:51​:32 2015, jkeenan wrote​:

Last night Tony C. asked me on IRC to try out the second of the two
patches in this ticket on my older Darwin system. Perl built
successfully and passed all tests with this patch EXCEPT
t/porting/authors.t

Thank you very much.
Jim Keenan

TonyC et al​: Would it be possible to get an update on the status of this RT?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 7, 2018

From rehsack@gmail.com

With the recent update of xcode - maybe the p5p are willing to rethink their decision wrt. attached patches ...

Am 22.02.2015 um 14​:34 schrieb Jens Rehsack <rehsack@​gmail.com>​:

Am 15.02.2015 um 12​:26 schrieb Leon Timmermans <fawaka@​gmail.com>​:

On Sun, Feb 15, 2015 at 10​:18 AM, Jens Rehsack <rehsack@​gmail.com> wrote​:
The handling of ld is kind-of unfortunate (Configure determines "env MACOSX_DEPLOYMENT_TARGET=10.3 env MACOSX_DEPLOYMENT_TARGET=10.9 icc ..."

Yeah, that whole logic stinks, it really should be replaced by a more sensible default :-/

Following https://software.intel.com/en-us/articles/performance-tools-for-software-developers-compatibility-of-intel-compiler-for-mac-os-x-and-xcode I updated my icc to 2015 Update 2, which reduces a lot of extra parameters. So now, with both attached patches, it'll compiles and tests fine using​:

$ sh Configure -de -Dusedevel -Dprefix=$PERLBREW_ROOT/perls/... -Dcc=icc -Dld=icc -Doptimize="-O3 -xHost"

<0001-Explicitely-exclude-icc-from-unused-result-improve.patch><0002-very-first-step-to-tidy-up-mess-around-sdk-to-use.patch>
$ make
$ make test
Failed 1 test out of 2265, 99.96% okay.
opbasic/arith.t

Since on Linux a lot more compilers are jumping around, I strongly suggest adding a probe whether __typeof__(x) is supported by compiler or not (Config​::AutoConf provides a compile_if_else() for that ;))

--
Jens Rehsack
rehsack@​gmail.com

--
Jens Rehsack - rehsack@​gmail.com

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.