Opened 15 months ago

Closed 5 months ago

Last modified 5 months 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 15 months ago.
msbuild file used for building ffmpeg from scratch

Download all attachments as: .zip

Change History (17)

Changed 15 months ago by veroorzaker

msbuild file used for building ffmpeg from scratch

comment:1 Changed 15 months ago by 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'"

comment:2 Changed 15 months ago by 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

comment:3 Changed 15 months ago by heleppkes

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 Changed 15 months ago by cehoyos

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 Changed 15 months ago by 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

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 Changed 15 months ago by cehoyos

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

comment:7 Changed 15 months ago by veroorzaker

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

comment:8 Changed 15 months ago by cehoyos

  • Resolution set to worksforme
  • Status changed from new to closed

comment:9 follow-up: Changed 15 months ago by 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?

Last edited 15 months ago by veroorzaker (previous) (diff)

comment:10 Changed 15 months ago by heleppkes

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

comment:11 in reply to: ↑ 9 Changed 15 months ago by cehoyos

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 Changed 15 months ago by 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.

comment:13 Changed 15 months ago by cehoyos

  • Component changed from undetermined to build system
  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:14 Changed 15 months ago by cehoyos

  • Reproduced by developer set

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

comment:15 Changed 5 months ago by cehoyos

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:16 Changed 5 months ago by veroorzaker

Looks ok, thanks!

Note: See TracTickets for help on using tickets.