Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#5546 closed defect (fixed)

MSVC x64 build broken

Reported by: veroorzaker Owned by:
Priority: normal Component: build system
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Attachments (1)

ffmpeg.targets (5.3 KB ) - added by veroorzaker 8 years ago.
msbuild file used for building ffmpeg from scratch

Download all attachments as: .zip

Change History (17)

by veroorzaker, 8 years ago

Attachment: ffmpeg.targets added

msbuild file used for building ffmpeg from scratch

comment:1 by veroorzaker, 8 years ago

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'"

comment:2 by dbuitenh, 8 years ago

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

comment:3 by Hendrik, 8 years ago

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.

comment:4 by Carl Eugen Hoyos, 8 years ago

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

comment:5 by veroorzaker, 8 years ago

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

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:

comment:6 by Carl Eugen Hoyos, 8 years ago

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

comment:7 by veroorzaker, 8 years ago

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

comment:8 by Carl Eugen Hoyos, 8 years ago

Resolution: worksforme
Status: newclosed

comment:9 by veroorzaker, 8 years ago

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?

Last edited 8 years ago by veroorzaker (previous) (diff)

comment:10 by Hendrik, 8 years ago

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

in reply to:  9 comment:11 by Carl Eugen Hoyos, 8 years ago

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?

comment:12 by veroorzaker, 8 years ago

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.

comment:13 by Carl Eugen Hoyos, 8 years ago

Component: undeterminedbuild system
Resolution: worksforme
Status: closedreopened

comment:14 by Carl Eugen Hoyos, 8 years ago

Reproduced by developer: set

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

comment:15 by Carl Eugen Hoyos, 7 years ago

Resolution: fixed
Status: reopenedclosed

comment:16 by veroorzaker, 7 years ago

Looks ok, thanks!

Note: See TracTickets for help on using tickets.