There are mingw-w64 builds for hosts: win32, win64 and linux64 containing 2 compilers

Support of MinGW-w64 (wo multilib) for 2 separate compilers: i686 and x86_64 about libwdi HOT 6 CLOSED

pbatard commented on July 17, 2024

Support of MinGW-w64 (wo multilib) for 2 separate compilers: i686 and x86_64

from libwdi.

Comments (6)

pbatard commented on July 17, 2024

Hi Andrey,

libwdi should already support what you suggest (using a non multilib MinGW32 as well as cross compiling). I am encouraging the use of multilib as it's a lot more convenient if you want to produce libwdi binaries that can target BOTH 32 bit Windows and 64 bit Windows with the same executable, else it will add a lot of complexity to fetch the right compiler. But if you only want to target one platform, then using a non multilib should be fine, though most people tend to use MinGW32 rather than MinGW-w64/32 bit for 32 bit targets.

Also see: https://github.com/pbatard/libwdi/wiki/FAQ#wiki-Is_it_possible_to_crosscompile_libwdi

Are you experiencing an issue with the mingw-w64 builds mentioned above?

from libwdi.

andreygursky commented on July 17, 2024

Hi Pete,

thanks for dealing with the issue! Yes, I saw the FAQ, that's why I wanted to ask you, whether it could be improved, because I haven't seen any binary builds of multilib compilers for linux, but there are at least 2 with separate compilers (debian native and Ruben's one).

Here is the output on my Debian Wheezy 32bit:

pbatard-libwdi-3f31212$ ./configure --host=i686-w64-mingw32 --with-libusb0="../libusb-win32-bin-1.2.6.0"
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for i686-w64-mingw32-strip... i686-w64-mingw32-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-w64-mingw32-gcc accepts -g... yes
checking for i686-w64-mingw32-gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of i686-w64-mingw32-gcc... gcc3
checking build system type... i686-pc-linux-gnu
checking host system type... i686-w64-mingw32
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by i686-w64-mingw32-gcc... /usr/bin/i686-w64-mingw32-ld
checking if the linker (/usr/bin/i686-w64-mingw32-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/i686-w64-mingw32-nm -B
checking the name lister (/usr/bin/i686-w64-mingw32-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-linux-gnu file names to i686-w64-mingw32 format... func_convert_file_nix_to_w32
checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/i686-w64-mingw32-ld option to reload object files... -r
checking for i686-w64-mingw32-objdump... i686-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for i686-w64-mingw32-dlltool... i686-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for i686-w64-mingw32-ar... i686-w64-mingw32-ar
checking for archiver @FILE support... @
checking for i686-w64-mingw32-strip... (cached) i686-w64-mingw32-strip
checking for i686-w64-mingw32-ranlib... i686-w64-mingw32-ranlib
checking command to parse /usr/bin/i686-w64-mingw32-nm -B output from i686-w64-mingw32-gcc object... ok
checking for sysroot... no
checking for i686-w64-mingw32-mt... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... i686-w64-mingw32-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for objdir... .libs
checking if i686-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for i686-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if i686-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if i686-w64-mingw32-gcc static flag -static works... yes
checking if i686-w64-mingw32-gcc supports -c -o file.o... yes
checking if i686-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the i686-w64-mingw32-gcc linker (/usr/bin/i686-w64-mingw32-ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for i686-w64-mingw32-windres... i686-w64-mingw32-windres
checking for inline... inline
checking whether i686-w64-mingw32-gcc and cc understand -c and -o together... yes
checking development environment... MinGW
checking whether the build compiler can produce executables that run on this host... yes
checking whether the compiler can produce 32 bit binaries... yes
checking whether the compiler can produce 64 bit binaries... no
configure: WARNING: compiler cannot produce 64 bit binaries - disabling 64 bit support
configure: WARNING: will produce a 32 bit library that is INCOMPATIBLE with 64 bit platforms
checking for ../libusb-win32-bin-1.2.6.0/bin/x86/libusb0.sys... yes
checking for ../libusb-win32-bin-1.2.6.0/bin/x86/libusb0_x86.dll... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libwdi/Makefile
config.status: creating libwdi/libwdi.pc
config.status: creating examples/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
pbatard-libwdi-3f31212$

Interesting:

checking whether we are cross compiling... no
...
checking whether the build compiler can produce executables that run on this host... yes

This is possible due to installed wine?

And that's what the issue is about:

checking whether the compiler can produce 32 bit binaries... yes
checking whether the compiler can produce 64 bit binaries... no
configure: WARNING: compiler cannot produce 64 bit binaries - disabling 64 bit support
configure: WARNING: will produce a 32 bit library that is INCOMPATIBLE with 64 bit platforms

But there is a compiler to produce 64 bit code in Debian: x86_64-w64-mingw32-gcc. So instead of calling "i686-w64-mingw32-gcc -m64" the x86_64-w64-mingw32-gcc should be used. Is this just a constraint of a build system (autotools/automake)?

from libwdi.

pbatard commented on July 17, 2024

Hmm, the checking we are cross compiling failing is usually not a good sign, but if you're running from Wine, it might be OK. Especially the rest of the detection seems to behave as expected. What happens when you run make.

Now I don't think I'll ever support calling 2 separate compilers to produce a 32+64 binary when cross compiling because:

too complex, too many points of failure, too little time to do that (more pressing matters), too few people likely to use it (no offence, but this is also something I have to consider when prioritizing features) plus I doubt I'll ever be able to test that it still works on each release
multilib is the smarter approach here, as it avoids having to deal with headers that are out of sync and other annoying issues. Multilib has been stable for a long time, so I'd rather see users request multilib binaries from the MinGW developers than continue pretending multilib doesn't exist.

Now in terms of implementation, two compilers i686-w64-mingw32-gcc (that produces 32 bit Windows binaries ONLY) and x86_64-w64-mingw32-gcc (that produces 64 bit Windows binaries only) would have to be invoked from autotools for libwdi to know that both 32 and 64 bit are available. This is just not possible through the standard autotools mechanisms of providing a single --host parameter, so I'd have to rewrite part of autotools to accept two --host options, and then add the logic to make them play well together. And really, having to specify --host, which is necessary when cross compiling, is the reason why you get 32 bit = yes, 64 bit = no. Autotools will only ever test one compiler: the one provided with --host. It does not try to search your system to see if, maybe, there might be a similar compiler for a different arch that could be used. And since the one your referenced through the --host parameter is 32 bit, you cannot get 64 bit. Unless I were to rewrite autotools altogether to accept two --host parameters (which is really not worth the effort), the only solution I see would be to ask users to run configure and make twice, with a 32 or 64 bit --host each time, and even that would be too complex and time consuming to implement

Therefore, the only paths of compilation I will support for autotools in libwdi are:

32+64 bit when using a compiler that supports -m32 and -m64 (multilib)
32 bit ONLY when referencing a 32 bit compiler with --host, regardless of whether a 64 bit compiler is available or not
64 bit ONLY when referencing a 64 bit compiler with --host, regardless of whether a 32 bit compiler is available or not

So, to sum things up, if you want to cross compile a libwdi application that works on both 32 and 64 bit Windows hosts, you will have to get a multilib MinGW-w64 compiler.
For the record, this is how I built the one I use:
http://pete.akeo.ie/2010/07/compiling-mingw-w64-with-multilib-on.html

As to checking whether the build compiler can produce executables that run on this host... yes
This is normal. We need to compile the embedder for the cross compiling host, so we need to be able to produce executable there, and that is what the check is about

from libwdi.

andreygursky commented on July 17, 2024

Thanks for your detailed explanations!
Dealing with 2 compilers is of course a general problem, not the goal of this project. It'd be worse to email this as wishlist to autoconf. I'm wondering whether cmake would be better in such case.

As to checking whether the build compiler can produce executables that run on this host... yes This is normal.

It was just confusing in the cross-compiling case. So the "build compiler" is a auxiliary compiler, used only for embedder. Maybe call this CC_FOR_EMBEDDER_EXEC and "embedder executable compiler" or yet better something like this:

checking whether the build compiler can produce executables that run on this host... no
checking whether the additionally supplied host compiler can produce executables that run on this host... yes

So it is always clear, that for cross-compilation CC_FOR_... should be explicit set.

from libwdi.

pbatard commented on July 17, 2024

Hi Andrey. I've evaluated CMake for libusb/libusbx but the result is that I don't think it's worth the switch. The one aspect I would really be interested in having CMake sort is the support for MSVC and WDK from a single set of options (like a configure.ac) and without a requirement to have the Visual Studio target installed before generating the files (so that one could tell CMake to generate VS2005 solution files from a Linux environment for instance), but that doesn't seem to be something CMake can provide. I also didn't find CMake that intuitive, and I tend to like the much decried autotools approach a lot better. I'm also suspicious about CMake making it more easy than autotools to handle 2 separate compilers at once.

As to CC_FOR_EMBEDDED, I'm already using CC_FOR_BUILD which seems to be the standard way of referencing the host compiler as per http://sources.redhat.com/autobook/autobook/autobook_270.html. According to this link, this is the established convention, so that's the one I prefer following.

from libwdi.

pbatard commented on July 17, 2024

I think this issue can be closed.

from libwdi.

Support of MinGW-w64 (wo multilib) for 2 separate compilers: i686 and x86_64 about libwdi HOT 6 CLOSED

Comments (6)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent