Different compiler flags with ninja and msvs GYP generators

[rchlo...@opera.com]

I have some problem with compiling ffmpegsumo target. This target will not link correctly with /O0 compiler flag in Release mode. That is fine, it's explained in the readme file. The thing is, with exactly the same gyp settings, this target compiles when using msvs generator but not when using ninja generator.

The key to reproducing this is to have this content in <user>/.gyp/include.gypi:

{

  'target_defaults': {

    'configurations': {

      'Release_Base': {

        'variables': {

          'buildtype': 'Official',

        },

      },

    },

  },

}

(Now, I'm not sure it's the correct way of setting the default "buildtype" value. It seems to produce different results than passing -Dbuildtype=Official to gyp_chromium. But that might be a topic for separate discussion, I'd like to focus on differences between generators now.)

With that settings in include.gypi, setting:

  set GYP_GENERATORS=msvs

and building ffmpegsumo in Release mode in VisualStudio will work fine.

But setting:

  set GYP_GENERATORS=ninja

and building:

  ninja -C out/Release ffmpegsumo

will fail at linking.

To me it seems like /O2 is the default optimization value that is not being used in .ninja files when no explicit optimization is set. Should it become default value for targets that don't override it?

But then I wonder why is /O2 not being used by default by the MS compiler if nothing is specified...

The whole resolving of variables in gyp is a bit of black magic to me. For example third_party/ffmpeg/ffmpeg.gyp sets:

  'release_optimize': '2'

so theoretically it should force /O2 but like I wrote, with given include.gypi it will not even appear in the final compilation options. When running gyp_chromium -Dbuildtype=Official on the other hand, /O1 will be used. So three different results.

These are the compilation flags for ffmpegsumo with included contents of the include.gypi (fails):

cflags = /wd4351 /wd4355 /wd4396 /wd4503 /wd4819 /wd4100 /wd4121 /wd4125 $

    /wd4127 /wd4130 /wd4131 /wd4189 /wd4201 /wd4238 /wd4244 /wd4245 /wd4310 $

    /wd4428 /wd4481 /wd4505 /wd4510 /wd4512 /wd4530 /wd4610 /wd4611 /wd4701 $

    /wd4702 /wd4706 /wd4996 /wd4018 /wd4090 /wd4305 /wd4133 /wd4146 /wd4554 $

    /wd4028 /wd4334 /wd4101 /wd4102 /wd4116 /wd4307 /wd4273 /wd4800 /Ob2 $

    /GF /GT /Oy- /Oi /W3 /WX /Zi /GR- /Gy /GS /MT /Oy-

and this is without it (works):

cflags = /wd4351 /wd4355 /wd4396 /wd4503 /wd4819 /wd4100 /wd4121 /wd4125 $

    /wd4127 /wd4130 /wd4131 /wd4189 /wd4201 /wd4238 /wd4244 /wd4245 /wd4310 $

    /wd4428 /wd4481 /wd4505 /wd4510 /wd4512 /wd4530 /wd4610 /wd4611 /wd4701 $

    /wd4702 /wd4706 /wd4996 /wd4018 /wd4090 /wd4305 /wd4133 /wd4146 /wd4554 $

    /wd4028 /wd4334 /wd4101 /wd4102 /wd4116 /wd4307 /wd4273 /wd4800 /wd4251 $

    /O2 /Ob2 /GF /Oy- /W3 /WX /Zi /GR- /Gy /GS /MD /EHsc /Oy-

[Scott Graham]

The different default between generators should be fixed in the gyp ninja generator. Please file a bug with this info (and you can CC me).

If you'd like to debug it, it's probably in tools/gyp/pylib/gyp/msvs_emulation.py, and tests for similar functionality are in tools/gyp/test/win/.

(I don't know how variables are turned into settings in ffmpeg.)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 

[Dale Curtis]

FFmpeg optimization should be frozen at O2. If it's not, it sounds like a bug:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg/ffmpeg.gyp&l=17

Do our official (Chrome) builds use msvs? If so, presumably branding=Chrome is pulling in a default for this from somewhere given that the official builders work.

- dale