MSVC x64 build broken

[veroorzaker]

Summary of the bug:
Current git's master branch doesn't build with VS2013 here for the 64bit version; x86 is ok. I can't tell since when it is, couple of onths ago build was still fine.

How to reproduce:

• get msys environment, yasm, ... (attached msbuild file below)
• git clone ffmpeg
• open msys's bash shell, cd to ffmpeg dir
• ./configure --enable-shared --toolchain=msvc
• make

Results in the error:
./compat/windows/makedef libavutil/libavutil.ver libavutil/../compat/msvcrt/snprintf.o libavutil/../compat/strtod.o libavutil/adler32.o libavutil/aes.o libavutil/aes_ctr.o libavutil/audio_fifo.o libavutil/avstring.o libavutil/base64.o libavutil/blowfish.o libavutil/bprint.o libavutil/buffer.o libavutil/camellia.o libavutil/cast5.o libavutil/channel_layout.o libavutil/color_utils.o libavutil/cpu.o libavutil/crc.o libavutil/des.o libavutil/dict.o libavutil/display.o libavutil/downmix_info.o libavutil/error.o libavutil/eval.o libavutil/fifo.o libavutil/file.o libavutil/file_open.o libavutil/fixed_dsp.o libavutil/float_dsp.o libavutil/frame.o libavutil/hash.o libavutil/hmac.o libavutil/hwcontext.o libavutil/imgutils.o libavutil/integer.o libavutil/intmath.o libavutil/lfg.o libavutil/lls.o libavutil/log.o libavutil/log2_tab.o libavutil/lzo.o libavutil/mastering_display_metadata.o libavutil/mathematics.o libavutil/md5.o libavutil/mem.o libavutil/murmur3.o libavutil/opt.o libavutil/parseutils.o libavutil/pixdesc.o libavutil/pixelutils.o libavutil/random_seed.o libavutil/rational.o libavutil/rc4.o libavutil/reverse.o libavutil/ripemd.o libavutil/samplefmt.o libavutil/sha.o libavutil/sha512.o libavutil/stereo3d.o libavutil/tea.o libavutil/threadmessage.o libavutil/time.o libavutil/timecode.o libavutil/tree.o libavutil/twofish.o libavutil/utils.o libavutil/x86/cpu.o libavutil/x86/cpuid.o libavutil/x86/emms.o libavutil/x86/fixed_dsp.o libavutil/x86/fixed_dsp_init.o libavutil/x86/float_dsp.o libavutil/x86/float_dsp_init.o libavutil/x86/lls.o libavutil/x86/lls_init.o libavutil/x86/pixelutils.o libavutil/x86/pixelutils_init.o libavutil/xga_font_data.o libavutil/xtea.o > libavutil/avutil-55.def
Microsoft (R) Library Manager Version 12.00.40629.0
Copyright (C) Microsoft Corporation. All rights reserved.

libavutil/adler32.o : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
Could not create temporary library.
library.mak:97: recipe for target 'libavutil/avutil-55.dll' failed

[veroorzaker]

msbuild file used for building ffmpeg from scratch

[veroorzaker]

was checking this more in detail and made a mistake in the description, seems I cannot edit it; proper description:

Summary of the bug:
Current git's master branch doesn't build with VS2013 here for the 64bit version after building the x86 version or vice versae. I can't tell since when it is, couple of onths ago build was still fine. Root cause is probably something doesn't get cleaned/built properly for consecutive builds.

How to reproduce:

• get msys environment, yasm, ... (attached msbuild file below)
• git clone ffmpeg

now build x86 version:

• run visual studio x86 command prompt
• open msys's bash shell, cd to ffmpeg dir
• ./configure --enable-shared --toolchain=msvc
• make

now build x64 version:

• run visual studio x64 command prompt
• open msys's bash shell, cd to ffmpeg dir
• ./configure --enable-shared --toolchain=msvc
• make clean
• make

This results in the original error displayed above.
Doing it the other way around, i.e. clone, then build x64, make clean and then build x86 the error is "libavutil/adler32.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'"

[dbuitenh]

It's because you are not cleaning before building on the 2nd arch, and you are not setting the target arch and OS properly during configure.

e.g. configure --target-os=win64 --arch=x86_64 --toolchain=msvc

[Hendrik]

I followed the steps you outlined exactly and it works here with VS2015 (don't have 2013 installed, but that should make no difference)

Sounds to me like you may have indeed skipped the clean step. If you are re-configuring anyway, running "make distclean" before the configure is probably always a good thing to do.

[Carl Eugen Hoyos]

Your report is that make clean does not work. Can you confirm this? For example with a command line like make libavutil/adler.o && make clean && ls -l libavutil/adler.o

[veroorzaker]

Ok thanks guys, reading this I'm thinking it's probably a user error (e.g. didn't know arch flags had to be specified - never did it, also never had problems without them though), so I'll first carefully try everything out with different combinations, then report back.

Some results already:

• start VS x64 commandline
• cl

Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64

• git clone ​git://source.ffmpeg.org/ffmpeg.git
• cd ffmpeg
• ./configure --target-os=win64 --arch=x86_64 --toolchain=msvc
• make
• all fine, creates x64 executable

Then:

• start VS x86 commandline
• cl

Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x86

• make clean
• make distclean
• ls -l */*.o

-rw-r--r-- 1 None None 9461 May 12 17:59 compat/strtod.o

• ./configure --target-os=win32 --arch=x86 --toolchain=msvc
• make
• libavutil/adler32.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

Try again from scratch:

• cd ..
• rm -Rf ffmpeg
• git clone ​git://source.ffmpeg.org/ffmpeg.git
• cd ffmpeg
• ./configure --target-os=win32 --arch=x86 --toolchain=msvc
• make
• all fine, creates x86 executable

[Carl Eugen Hoyos]

Please test if make clean removes libavutil/adler.o on your system or not.

[veroorzaker]

Yes it does, see result of ls -l */*.o above

[veroorzaker]

Closed? I was just coming up with a fix :P

So after make clean, a bunch of files are not cleaned (as already shown in above comment):

• compat\msvcrt\snprintf.d
• compat\msvcrt\snprintf.o
• compat\strtod.d
• compat\strtod.o
• bunch of pdb and ilk files for ffmpeg_g, ffprobe_g

Removing the first 4 (snprintf.o/d and strod.o/d) fixes the problem, since they'll then be built again for the correct platform.

Your report is that make clean does not work. Can you confirm this?

seems so

@heleppkes could you check if these files do get removed on your machine?

[Hendrik]

Those files are not built for 2015, as they are unnecessary there, but it is certainly possible that they are not cleaned properly since they are rather special in the build system

[Carl Eugen Hoyos]

Replying to veroorzaker:

So after make clean, a bunch of files are not cleaned (as already shown in above comment):

• compat\msvcrt\snprintf.d
• compat\msvcrt\snprintf.o
• compat\strtod.d
• compat\strtod.o
• bunch of pdb and ilk files for ffmpeg_g, ffprobe_g

But this is not what you originally reported and it is not possible to trigger a build error because these files are not deleted by make clean or am I wrong?

[veroorzaker]

But this is not what you originally reported

you mean the libavutil/adler32.o : fatal error LNK1112 error? That is in fact triggered by snprintf.o/strod.o not being cleaned: when these files still exist after an x86 build, in makedef line 48 they are passed to lib followed by libavutil/adler32.o and the rest. So lib first sees two x86 object files followed by an x64 object file hence the error.

[Carl Eugen Hoyos]

Reproducible with make compat/getopt.o && make clean

[Carl Eugen Hoyos]

Should be fixed in d100dc6c9955af8b7a7a60a37a362a51c819222e

[veroorzaker]

Looks ok, thanks!