New to wxWidgets - problem building samples with x64 config

[bi...@philomellsoftware.com]

Hello,

wxWidgets installed and built for 32 and 64 bit, debug and release. With 32 bit, all is well. With 64 bit, building the image sample either debug or release, I get these errors:

E1256 __w64 can only be specified on int, long, and pointer types image g:\dev\wxWidgets-3.1.1\include\wx\types.h 387

LNK1112 module machine type 'x86' conflicts with target machine type 'x64' image G:\dev\wxWidgets-3.1.1\samples\image\wxmsw31u_core.lib(corelib_event.obj) 1

This happens with all samples. What is going wrong?

TIA for any help,

Bill

[bi...@philomellsoftware.com]

Sorry, should have specified: Windows 7, Visual Studio 2017.

[Igor Korot]

Hi,

On Sat, Mar 10, 2018 at 7:04 PM, <bi...@philomellsoftware.com> wrote:
> Sorry, should have specified: Windows 7, Visual Studio 2017.
>
>
> On Saturday, March 10, 2018 at 4:47:42 PM UTC-8, bi...@philomellsoftware.com
> wrote:
>>
>> Hello,
>>
>> wxWidgets installed and built for 32 and 64 bit, debug and release. With
>> 32 bit, all is well. With 64 bit, building the image sample either debug or
>> release, I get these errors:
>>
>> E1256 __w64 can only be specified on int, long, and pointer types image
>> g:\dev\wxWidgets-3.1.1\include\wx\types.h 387
>> LNK1112 module machine type 'x86' conflicts with target machine type 'x64'
>> image
>> G:\dev\wxWidgets-3.1.1\samples\image\wxmsw31u_core.lib(corelib_event.obj) 1

Are you sure you are linking against 64-bit libraries?

Thank you.

>>
>> This happens with all samples. What is going wrong?
>>
>> TIA for any help,
>> Bill
>>

> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users

[Vadim Zeitlin]

When building samples from the command line, you need to pass
TARGET_CPU=x64 on nmake command line (see docs/msw/install.txt) and you're
probably not doing this.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[bi...@philomellsoftware.com]

I am giving the command line

nmake /f makefile.vc TARGET_CPU=X64

as specified in install.txt. This generates the two errors, with or without BUILD=release. I also get the same errors if I use any of the supplied ..._vc9.sln files with a 64 bit configuration. This happens on all of the samples, including minimal.

[bi...@philomellsoftware.com]

I was able to get a working build, but not through nmake, only through the .sln files.

My command line for the build of wxWidgets (release, static libs throughout) was:

nmake /f makefile.vc TARGET_CPU=X64 BUILD=release SHARED=0 RUNTIME_LIBS=static

This was producing 32 bit libs, as confirmed by running dumpbin.

I then loaded the wx_vc15.sln file. I had to change all of the projects to use static runtime libraries. But the Release x64 configuration built successfully and generated 64 bit libs.

I then switched to the samples/image folder and ran the same command line:

nmake /f makefile.vc TARGET_CPU=X64 BUILD=release SHARED=0 RUNTIME_LIBS=static

This produced the link error about mismatched machine types. 

Next I loaded image_vc9.vcproj (which converted automatically), and changed the runtime libs to static. The Release x64 configuration built successfully. (I have not tried Debug yet.)

It looks like the TARGET_CPU=X64 on the command line is not being observed properly in the make file - the libs go in a folder with x64 in the name, but they are not 64 bit.

[PB]

Hello,

if the TARGET_CPU is not working as expected, as a workaround you can set the architecture yourself.

For example, you would build 64-bit wxWidgets in static debug configuration with CRT linked statically like this with MSVC 2017 nmake (assumes the WXWIN environment variable is set properly) like this:

set "VSCMD_START_DIR=%WXWIN%\build\MSW"
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\WDExpress\VC\Auxiliary\Build\vcvarsx86_amd64.bat"

nmake -f makefile.vc BUILD=debug COMPILER_PREFIX=vc15_x64 RUNTIME_LIBS=static

Make sure to adjust the MSVS path as needed, including the edition part - e.g., replace WDExpress with Community if you are using the Community Edition and not Express Edition.

To build a sample, go to its folder and again, run the same commands except for setting the start dir to the current one:

set "VSCMD_START_DIR=%cd%"
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\WDExpress\VC\Auxiliary\Build\vcvarsx86_amd64.bat"

nmake -f makefile.vc BUILD=debug COMPILER_PREFIX=vc15_x64 RUNTIME_LIBS=static

Regards,
PB

[bi...@philomellsoftware.com]

Yes, that works - thank you! Much appreciated.

Bill

[Vadim Zeitlin]

On Sun, 11 Mar 2018 12:10:54 -0700 (PDT) wrote:

> My command line for the build of wxWidgets (release, static libs
> throughout) was:
>
> nmake /f makefile.vc TARGET_CPU=X64 BUILD=release SHARED=0
> RUNTIME_LIBS=static
>
> This was producing 32 bit libs, as confirmed by running dumpbin.

This means that you ran this command from a 32 bit "Developer Command
Prompt" window, i.e. using the 32 bit compiler. You need to run it from the
64 bit one.

> It looks like the TARGET_CPU=X64 on the command line is not being observed
> properly in the make file - the libs go in a folder with x64 in the name,
> but they are not 64 bit.

The makefile does what it can -- i.e. names the files correctly -- but it
can't build 64 bit binaries with 32 bit compiler.

It would be nice if we could detect the mismatch somehow, but I don't know
of any way to do it, unfortunately.

[Steve Barnes]

It would be nice if the MS 32 bit compiler produced an error when called with the 64 bit target flag - it may be possible to cause one with a conditional something like #if target_cpu="X64" #if arch="X86" #error but the MS documentation is not very helpful on this point (as usual).

There may be some help at https://stackoverflow.com/questions/39258250/how-to-detect-if-64-bit-msvc-with-cmake  

[Vadim Zeitlin]

On Sun, 11 Mar 2018 23:12:17 -0700 (PDT) Steve Barnes wrote:

SB> It would be nice if the MS 32 bit compiler produced an error when called
SB> with the 64 bit target flag - it may be possible to cause one with a
SB> conditional something like #if target_cpu="X64" #if arch="X86" #error but
SB> the MS documentation is not very helpful on this point (as usual).

We could indeed define TARGET_CPU in CPPFLAGS (we currently don't, it's
only a make variable) and then we'd be able to test it like this. It could
be worth doing if such errors are common...

SB> There may be some help at
SB> https://stackoverflow.com/questions/39258250/how-to-detect-if-64-bit-msvc-with-cmake

CMake performs tests that can't be done from a normal makefile (it's more
like a configure+make rather than just make).

[PB]

It appears that when the batch file for the MSVS build environment for 64-bit architecture (x86_amd64) is called, it sets the environment variable Platform to x64, while the environments for 32-bit architecture do not seem to set this variable at all. I tested with MSVC 2008, 2015, and 2017 (2017 also sets VSCMD_ARG_TGT_ARCH appropriatelly to either x86 or x64).

Therefore, it should be possible to do something like this (briefly tested with appending these commands at the end of config.vc) in the MSVC makefile:

!IF "$(TARGET_CPU)" == "X64" && "$(PLATFORM)" != "x64"
!ERROR When targetting X64 CPU, MSVS build environment must be set for x64 platform before calling nmake!
!ENDIF

But I wonder whether doing it would be worth the effort...

[Gunter Königsmann]

Most beginners questions are caused by not using exactly the same flags when building the library and the application especially as many build systems for commercial OS aren't really helpful in this aspect...

--

Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 

To unsubscribe, send email to wx-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wx-users