Configure: use a better method to identify gcc and derivates [1.0.2] #4755

levitte · 2017-11-18T17:03:43Z

Looking for 'gcc' and 'clang' in the output from the C compiler is
uncertain. Some versions report argv[0], which might be /usr/bin/cc
(for example), and others might mention gcc without being gcc or a
derivate.

Better then to fetch predefined macros and checking if __GNUC__ and
__clang__ are defined.

This is an alternative to #1524

levitte · 2017-11-18T17:04:30Z

Configure

Note that on (new) line 1679, there already is an exact string comparison for clang...

dot-asm · 2017-11-19T10:00:41Z

Configure

On side note this can't actually happen, there is no such thing as icc cross-compiler. But for consistent view...

dot-asm · 2017-11-19T10:11:49Z

Configure

On side note it was pointed out that gcc compiler driver reports basename of argv[0] in --version output. How is it a problem? Customarily you'd have /usr/bin/cc that is gcc in disguise, but this check won't recognize it as gcc as it will report cc 3.2.1. Also note that archaic gcc versions print just version number, e.g. 2.25.3, i.e. don't identify themselves the expected way. None of this applies to clang, so that check for presence of "clang" in --version output is reliable. Unlike gcc that is.

It should be noted however that as far as MAKEDEPPROG goes that thing that archaic gcc versions print just version number incidentally works out. This is because archaic versions don't support generation of dependencies, and you don't "want" to recognize it as gcc :-)

Another problem with check for gcc in --version output is ... IBM compiler. When it doesn't recognize command line option, such as --version here, it emits manual page, which mentions gcc, so that the check ~~should~~ does come out successful...

EDIT: "should" -> "does"

Looking for 'gcc' and 'clang' in the output from the C compiler is uncertain. Some versions report argv[0], which might be /usr/bin/cc (for example), and others might mention gcc without being gcc or a derivate. Better then to fetch predefined macros and checking if __GNUC__ and __clang__ are defined.

levitte · 2017-12-06T17:57:16Z

I remade this entirely, using the same check of predefined macros as in master.

mattcaswell · 2017-12-08T15:06:56Z

What is the status of this?

Looking for 'gcc' and 'clang' in the output from the C compiler is uncertain. Some versions report argv[0], which might be /usr/bin/cc (for example), and others might mention gcc without being gcc or a derivate. Better then to fetch predefined macros and checking if __GNUC__ and __clang__ are defined. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from #4755)

levitte · 2017-12-10T09:32:37Z

Merged. 78e9e3f

tmshort · 2018-04-17T18:41:31Z

This commit appears to break Mac OS X 10.7 (when cross-compiling for iOS or 10.5).
It used to be:
MAKEDEPPROG=makedepend
Now it's:
MAKEDEPPROG=cc

cc doesn't work well for Mac for making dependencies

$predefined{__GNUC__} = 4

levitte · 2018-04-17T18:59:49Z

Ah, it should probably become this in that case:

MAKEDEPPROG=$(CROSS_COMPILE)cc

tmshort · 2018-04-17T19:01:28Z

Let us try it and see if it works...

tmshort · 2018-04-17T20:22:04Z

This is not true cross-compiling, so $(CROSS_COMPILE) is not defined, and it's the same non-functional behavior.

The cc compiler on 10.7 reports:

$ cc --version
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Which doesn't contain "clang", thus$cc = "cc", and $ecc = "" in Configure. So, the previous tests that changed $MAKEDEPROG from the default of "makedepend" to "cc" did not do anything, whereas the new tests do, because $predefined{__GNUC__} = 4

Mac OS X 10.11 does't experience this problem; it's with older versions of Mac OS X.

levitte · 2018-04-17T20:41:12Z

That basically tells me that cc on 10.7 falsely declares itself compatible with some newer gcc version...

tmshort · 2018-04-17T21:09:49Z

At the very least, it's that cc can't behave as makedepend before Mac OS X 10.8 (where makedepend disappeared); cc doesn't support -M. Starting with 10.8, cc -M works as expected.

dot-asm · 2018-04-18T14:58:56Z

That just sucks. In either case, if so desired, it would be appropriate to check even for $predefined{__APPLE_CC__} in order to decide if cc is suitable as makedepend replacement. I suppose $predefined{__APPLE_CC__} && predefined{__clang__} would be accurate enough.

tmshort · 2018-04-19T12:36:16Z

The 10.8 compiler cc -dM -E -x c partial output (I have a complete list available):

#define __GNUC__ 4
#define __APPLE__ 1
#define __APPLE_CC__ 5658
#define __llvm__ 1

It does not define __clang__. Would it suffice to just check __llvm__?

dot-asm · 2018-04-19T14:33:59Z

Would it suffice to just check __llvm__?

It seems that I've expressed myself a bit unfortunate. It should have been "reliable enough" instead of "accurate enough". I mean reliability over accuracy in sense that it would be safer to misinterpret conditions in favour of makedepend than vice versa. In other words even if specific compiler version is capable of handling dependencies, we don't have to "feel bad" about ending up with makedepend. As long as makedepend works that is. It all boils down to question whether or not you can confirm that first version of Apple compiler that defines __llvm__ supports -M. If you can, then go for it, but if not, then it might be more appropriate to settle for more conservative __clang__ anyway...

tmshort · 2018-04-19T14:37:38Z

Actually, it appears that if the Apple compiler defines __llvm__ it DOES NOT support -M, so the __llvm__ identifier would be used to maintain the value as makedepend. The Apple compiler that supports cc -M appears to define __clang__. However, I don't have all versions available to confirm this.

dot-asm · 2018-04-19T14:53:19Z

if the Apple compiler defines __llvm__ it DOES NOT support -M,

You probably meant that __llvm__ does not guarantee -M support. All clangs, Apple or not, do define both __clang__ and __llvm__, so you can't actually say that you can use __llvm__ to make decision about choosing makedepend. As for identifying exact version. One can take a chance of using __clang__ as marker, or one can take the least __APPLE_CC__ value you happen to have that works...

tmshort · 2018-04-19T14:54:37Z

Right, unfortunately, I don't have a proper sample of compilers.

misery · 2018-04-24T14:25:49Z

This also broke our mingw environment.

   making depend in crypto...
    ../util/domd: line 33: makedepend: command not found
     mv: cannot stat `Makefile.new': No such file or directory
     Makefile:136: recipe for target 'local_depend' failed
     mingw32-make[5]: *** [local_depend] Error 127

levitte added the branch: 1.0.2 Applies to OpenSSL_1_0_2-stable branch (EOL) label Nov 18, 2017

levitte commented Nov 18, 2017

View reviewed changes

Configure Outdated

Copy link

Member Author

levitte Nov 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that on (new) line 1679, there already is an exact string comparison for clang...

levitte mentioned this pull request Nov 18, 2017

Configure: use sub-string matching instead of string equality of $cc. #1524

Closed

dot-asm reviewed Nov 19, 2017

View reviewed changes

dot-asm mentioned this pull request Dec 4, 2017

Getting rid of Makefile.shared #4840

Closed

1 task

levitte force-pushed the Configure-ecc-consistency branch from 2a2c026 to 86b02cf Compare December 6, 2017 17:55

levitte changed the title ~~Configure: $ecc consistency and a little more [1.0.2]~~ Configure: use a better method to identify gcc and derivates [1.0.2] Dec 6, 2017

dot-asm approved these changes Dec 9, 2017

View reviewed changes

dot-asm added the approval: done This pull request has the required number of approvals label Dec 9, 2017

levitte closed this Dec 10, 2017

tmshort mentioned this pull request Apr 24, 2018

Fix older Mac build that still use makedepend [1.0.2] #6073

Closed

2 tasks

This was referenced May 3, 2018

Fix Mac OS X builds that still require makedepend [1.1.0] #6167

Closed

Fix Mac OS X builds that still require makedepend [1.1.1] [master] #6169

Closed

Uh oh!

Configure: use a better method to identify gcc and derivates [1.0.2] #4755

Configure: use a better method to identify gcc and derivates [1.0.2] #4755

Uh oh!

Conversation

levitte commented Nov 18, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

levitte Nov 18, 2017

Choose a reason for hiding this comment

Uh oh!

dot-asm Nov 19, 2017

Choose a reason for hiding this comment

Uh oh!

dot-asm Nov 19, 2017

Choose a reason for hiding this comment

Uh oh!

dot-asm Nov 19, 2017

Choose a reason for hiding this comment

Uh oh!

dot-asm Nov 19, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

levitte commented Dec 6, 2017

Uh oh!

mattcaswell commented Dec 8, 2017

Uh oh!

levitte commented Dec 10, 2017

Uh oh!

tmshort commented Apr 17, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

levitte commented Apr 17, 2018

Uh oh!

tmshort commented Apr 17, 2018

Uh oh!

tmshort commented Apr 17, 2018

Uh oh!

levitte commented Apr 17, 2018

Uh oh!

tmshort commented Apr 17, 2018

Uh oh!

dot-asm commented Apr 18, 2018

Uh oh!

tmshort commented Apr 19, 2018

Uh oh!

dot-asm commented Apr 19, 2018

Uh oh!

tmshort commented Apr 19, 2018

Uh oh!

dot-asm commented Apr 19, 2018

Uh oh!

tmshort commented Apr 19, 2018

Uh oh!

misery commented Apr 24, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

levitte commented Nov 18, 2017 •

edited

Loading

dot-asm Nov 19, 2017 •

edited

Loading

tmshort commented Apr 17, 2018 •

edited

Loading