https://bugs.winehq.org/show_bug.cgi?id=53539
Bug ID: 53539 Summary: maybe a --with-wine-64 build should call widl with -win32 option Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs@winehq.org Reporter: j-r@online.de Distribution: ---
Using just --with-wine-64 results in a Makefile calling widl from the win64 build directory without any target architecture specified resulting in early build failure:
... WIDL dlls/actxprxy/actxprxy_activscp_p.c WIDL dlls/actxprxy/actxprxy_activscp.h CC dlls/actxprxy/actxprxy_activscp_p.cross.o dlls/actxprxy/actxprxy_activscp_p.c:9084:2: error: #error Invalid build platform for this proxy. 9084 | #error Invalid build platform for this proxy. | ^~~~~
Hacking Makefile to add -win32 to the widl invocation works around this. I have no clue whether that is the right solution, though.
https://bugs.winehq.org/show_bug.cgi?id=53539
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- We do pass -m32 to widl invocations for i386 platforms. How are you invoking configure? Can you attach config.log, and also the full makedep generated widl command rather than the silent rules?
https://bugs.winehq.org/show_bug.cgi?id=53539
--- Comment #2 from j-r@online.de --- (In reply to Zeb Figura from comment #1)
We do pass -m32 to widl invocations for i386 platforms. How are you invoking configure? Can you attach config.log, and also the full makedep generated widl command rather than the silent rules?
Thanks for the hint! Looks like it adds -m32 if uname -m is x64_64. Mine wasn't in this case, because my userland is still mostly 32 bit - even though kernel and tool chain are 64 bit - and I run in the 32 bit personality by default (i only switched for the wine64 build, which works fine) as to not confuse anything, which I inadvertently just did here. Sorry, my fault, obviously.
(Actually my reason for using the linux32 personality was that it's a i686 build and the generated Makefile picks up entries for gcc, g++, ar, ranlib etc. and I was too lazy to override them individually with the appropriate i686 targeted version or make sure that they are irrelevant. My /usr/bin/gcc and friends select the appropriate variant at runtime, so that it still looks like a normal 32 bit userland when run with linux32 personality. I only have this one system and quite a lot of legacy crap on it:-)
I'm wondering if it would be the right thing to pass -m32 (or TARGETFLAGS?) independent of build host, since the --with-wine64=... provided tools will always default to -m64, I think?
Anyway, it's fine for me either way. Thanks again for the quick response!
https://bugs.winehq.org/show_bug.cgi?id=53539
--- Comment #3 from j-r@online.de --- (In reply to j-r from comment #2)
I'm wondering if it would be the right thing to pass -m32 (or TARGETFLAGS?) independent of build host, since the --with-wine64=... provided tools will always default to -m64, I think?
I mean without --with-wine-tools=, but even with --with-wine-tools= they may be defaulting to 64 bit. AFAICT the only thing the build cares about is that they can be executed on the build host.
https://bugs.winehq.org/show_bug.cgi?id=53539
--- Comment #4 from j-r@online.de --- (In reply to j-r from comment #3)
(In reply to j-r from comment #2)
I'm wondering if it would be the right thing to pass -m32 (or TARGETFLAGS?) independent of build host, since the --with-wine64=... provided tools will always default to -m64, I think?
I mean without --with-wine-tools=, but even with --with-wine-tools= they may be defaulting to 64 bit. AFAICT the only thing the build cares about is that they can be executed on the build host.
Looking at the TARGETFLAGS section of configure.ac, it's not clear to me
- why x86_32 build hosts are handled differently form x86_64 at all. Are there supported toolchains for the wine32 build that don't support -m32/-m64?
- why cross building enters into the consideration for x86_64 build hosts. At least on Debian stable it seems that passing -m32 to the default X86_64 gcc is not enough to build a 32 bit executable (because it cannot find a suitable libgcc) and installing i686-linux-gnu-gcc is the easiest way out; while just passing CC=i686-linux-gnu-gcc to configure is enough for the build to succeed, technically it's a cross build and using --host=i686-linux-gnu doesn't seem less correct and shouldn't be blocked
- why the ms_va_list test build is done without -m64.
I'll try a few test builds with the above points changed and debian's gcc packages.
https://bugs.winehq.org/show_bug.cgi?id=53539
--- Comment #5 from Zeb Figura z.figura12@gmail.com --- I think the intent is that any unrecognized targets shouldn't receive any extra flags (which may not even be valid). We don't know whether an arbitrary target is a 32-bit or 64-bit. This is compounded by the fact that WoW64 is only really supported for ARM and x86 targets, and doesn't exactly make sense for anything else.
If you're doing a wow64 build in the first place, we arguably know that the 32-bit side should have -m32, but I don't think cases like this have ever come up, and it's not really clear to me what the "correct" thing to do is.
(In reply to j-r from comment #4)
Looking at the TARGETFLAGS section of configure.ac, it's not clear to me
- why x86_32 build hosts are handled differently form x86_64 at all. Are
there supported toolchains for the wine32 build that don't support -m32/-m64?
Not at the moment, but I think there have been in the past.
- why cross building enters into the consideration for x86_64 build hosts.
At least on Debian stable it seems that passing -m32 to the default X86_64 gcc is not enough to build a 32 bit executable (because it cannot find a suitable libgcc) and installing i686-linux-gnu-gcc is the easiest way out; while just passing CC=i686-linux-gnu-gcc to configure is enough for the build to succeed, technically it's a cross build and using --host=i686-linux-gnu doesn't seem less correct and shouldn't be blocked
"$host" is the user-specified host and not (necessarily) the build machine, so unless I'm misreading that, the point there is that if someone passes --host=x86_64-linux-gnu but not --enable-win64, we want to respect the --host argument and do a 64-bit build. (But if they don't pass any options, we want to build a 32-bit tree, because that is categorically more useful than a 64-bit tree for Windows programs.)
- why the ms_va_list test build is done without -m64.
It probably wasn't *intentionally* done without -m64, but rather there's no need; -m64 is effectively the default on x86_64 platforms.
https://bugs.winehq.org/show_bug.cgi?id=53539
--- Comment #6 from j-r@online.de --- I'm not sure where the recent work on multi arch building will lead, but it seems to me that it should address most of what this bug is about, i.e. calling widl with the right options for the target architecture independent of the build host architecture (which isn't necessarily a good predictor of the widl default target). If that is the case this report should be closed.
https://bugs.winehq.org/show_bug.cgi?id=53539
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #7 from Zeb Figura z.figura12@gmail.com --- Yeah, I don't think it's clear there's a bug here, resolving INVALID then.
https://bugs.winehq.org/show_bug.cgi?id=53539
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Gijs Vermeulen gijsvrm@gmail.com --- Closing INVALID.
-
WineHQ Bugzilla