should emconfigure adjust CXXFLAGS?
skierpage
`emconfigure ./configure` doesn't do anything to these, so it remains
CXXFLAGS = -g -O2
in all generated Makefiles. Meanwhile emconfigure sets CFLAGS to the
complicated
CFLAGS = -m32 -U__i386__ -U__x86_64__ -U__i386 -U__x86_64 -U__SSE__ -
U__SSE2__ -U__MMX__ -UX87_DOUBLE_ROUNDING -UHAVE_GCC_ASM_FOR_X87 -
DEMSCRIPTEN -U__STRICT_ANSI__ -U__CYGWIN__ -D__STDC__ -nostdinc -I/opt/
download/emscripten/system/include -I/opt/download/emscripten/system/
include/bsd -I/opt/download/emscripten/system/include/libc -I/opt/
download/emscripten/system/include/libcxx -I/opt/download/emscripten/
system/include/gfx -I/opt/download/emscripten/system/include/net -I/
opt/download/emscripten/system/include/SDL -U__APPLE__
I changed emscripten's tools/shared.py to set CXXFLAGS as well.
- env['CFLAGS'] = env['EMMAKEN_CFLAGS'] = ' '.join(COMPILER_OPTS +
Building.COMPILER_TEST_OPTS) # Normal CFLAGS is ignored by some
configure's.
+ ## CXXFLAGS needed by some configures, e.g. DOSBox.
+ env['CXXFLAGS'] = env['CFLAGS'] = env['EMMAKEN_CFLAGS'] = '
'.join(COMPILER_OPTS + Building.COMPILER_TEST_OPTS) # Normal CFLAGS is
ignored by some configure's.
(Should I file this and my sdl-config woes in the issue tracker?)
--
=S Page
Alon Zakai
This definitely looks like a bug, we should modify CXXFLAGS (I wonder
why we haven't hit this before..?). Please file a github issue or even
better a pull request :)
- azakai
David Claughton
FWIW, I have noticed that emcc adds the above options to the clang
command line manually as well - which means (for me at least) because
these are also put in CFLAGS they end up being added twice! For this
reason I've been meaning to make the suggestion that maybe CFLAGS should
*not* be modified by emconfigure, much less that CXXFLAGS should be ;-)
Were these options not being added in the dosbox builds without the
changes to CXXFLAGS?
I suppose it's hardly the end of the world if the options are repeated
on the command line, it just seems to me that probably they should only
be in one place, and IMHO emcc is the correct place as it allows for the
occasional build process which ignores or modifies CFLAGS.
Cheers,
David.
Alon Zakai
David, I'm not sure what you mean by the options showing up twice -
can you give an example command, and the output you get, where that
happens?
- azakai
David Claughton
Yes, here is a sample of the output of compiling pixman ... running
'EMCC_DEBUG=1 make' after first doing 'emconfigure ./configure'
I've added some blank lines for clarity.
CC pixman.lo
emcc: /home/david/src/git/emscripten/emcc -DHAVE_CONFIG_H -I. -I.. -m32
-U__i386__ -U__x86_64__ -U__i386 -U__x86_64 -U__SSE__ -U__SSE2__
-U__MMX__ -UX87_DOUBLE_ROUNDING -UHAVE_GCC_ASM_FOR_X87 -DEMSCRIPTEN
-U__STRICT_ANSI__ -U__CYGWIN__ -D__STDC__ -nostdinc
-I/home/david/src/git/emscripten/system/include
-I/home/david/src/git/emscripten/system/include/bsd
-I/home/david/src/git/emscripten/system/include/libc
-I/home/david/src/git/emscripten/system/include/libcxx
-I/home/david/src/git/emscripten/system/include/gfx
-I/home/david/src/git/emscripten/system/include/net
-I/home/david/src/git/emscripten/system/include/SDL -U__APPLE__ -Wall
-fno-strict-aliasing -fvisibility=hidden -MT pixman.lo -MD -MP -MF
.deps/pixman.Tpo -c pixman.c -fPIC -DPIC -o .libs/pixman.o
emcc: compiling to bitcode
emcc: compiling source file: pixman.c
emcc running: /home/david/src/git/llvm/build/bin/clang -DHAVE_CONFIG_H
-I. -I.. -m32 -U__i386__ -U__x86_64__ -U__i386 -U__x86_64 -U__SSE__
-U__SSE2__ -U__MMX__ -UX87_DOUBLE_ROUNDING -UHAVE_GCC_ASM_FOR_X87
-DEMSCRIPTEN -U__STRICT_ANSI__ -U__CYGWIN__ -D__STDC__ -nostdinc
-I/home/david/src/git/emscripten/system/include
-I/home/david/src/git/emscripten/system/include/bsd
-I/home/david/src/git/emscripten/system/include/libc
-I/home/david/src/git/emscripten/system/include/libcxx
-I/home/david/src/git/emscripten/system/include/gfx
-I/home/david/src/git/emscripten/system/include/net
-I/home/david/src/git/emscripten/system/include/SDL -U__APPLE__ -Wall
-fno-strict-aliasing -fvisibility=hidden -MT pixman.lo -MD -MP -c -fPIC
-DPIC -m32 -U__i386__ -U__x86_64__ -U__i386 -U__x86_64 -U__SSE__
-U__SSE2__ -U__MMX__ -UX87_DOUBLE_ROUNDING -UHAVE_GCC_ASM_FOR_X87
-DEMSCRIPTEN -U__STRICT_ANSI__ -U__CYGWIN__ -D__STDC__ -nostdinc
-I/home/david/src/git/emscripten/system/include
-I/home/david/src/git/emscripten/system/include/bsd
-I/home/david/src/git/emscripten/system/include/libc
-I/home/david/src/git/emscripten/system/include/libcxx
-I/home/david/src/git/emscripten/system/include/gfx
-I/home/david/src/git/emscripten/system/include/net
-I/home/david/src/git/emscripten/system/include/SDL -U__APPLE__
-emit-llvm -c pixman.c -o /tmp/tmpE9zcrM/pixman.o
As you can see, the first command has everything from -m32 through to
-U__APPLE__ added, which is due to the expansion of CFLAGS in the
Makefile. Emcc then translates this into a clang command line and
inserts a second set of the same options just prior to the -emit-llvm
option.
Cheers
David.
skierpage
> FWIW, I have noticed that emcc adds the above options to the clang
> command line manually as well - which means (for me at least) because
> these are also put in CFLAGS they end up being added twice!
clang++ command line. All I needed to do was set the CXXFLAGS
environment variable to override the project's default "-g -O2",
there's no need to monkey with tools/shared.py to add all the options
to CXXFLAGS.
The reason this child played with the loaded gun in the first place is
the simple steps in the Building-Projects wiki page immediately failed
with "emcc: fatal: Closure compiler...", because I have not configured
Closure yet the project's -O2 setting makes emscripten run it. (The
problem is masked for projects that use CFLAGS because emconfigure
overrides their default.)
It would be more robust if emcc instead warned something like "-02
optimize level set, but Closure compiler not found, so not
optimizing", and kept going. I'll attempt a patch.
Thanks indeed,
--
=S Page
Alon Zakai
Thanks! I had not noticed this.
I am not sure what the fix is, though. Right now we set CFLAGS in both
make and configure (emmake and emconfigure), because
1. Some projects notice CFLAGS during configure, but not make
(configure bakes the CFLAGS into the makefiles, for example)
2. Some projects notice CFLAGS during make, but not configure (they
might not have a configure step at all, for example)
It looks like pixman both notices CFLAGS in configure, *and* in make.
But removing one of them would break other projects, it seems, unless
I am missing something?
- azakai
David Claughton
> But removing one of them would break other projects, it seems, unless
> I am missing something?
>
No, I don't think this is it. The options in question (defined in
settings.EMSDK_OPTS) are not only exported in CFLAGS - they also get
added to CC_ADDITIONAL_ARGS in emcc and used directly in building the
clang command.
Since this means they are always in the command regardless, I don't see
any reason for adding these options to CFLAGS at all.
Cheers,
David.
Alon Zakai
I see now, yes, you are totally right. I will stop adding them to CFLAGS.
Thanks!
- azakai