vmware
Build break on x86/32 bit sysroot (but x86_64 kernel) (dual-arch)
Describe the bug
Guessing the host machine by looking at uname is wrong. We need to ask the compiler. (Possibly actually autoconf bug.)
this wrong guessing leads to the wrong arch specific source to be compiled, which fails:
backdoorGcc64.c: In function ‘Backdoor_InOut’: backdoorGcc64.c:78:4: error: inconsistent operand constraints in an ‘asm’ 78 | asm volatile( | ^~~~~~~ make[2]: *** [Makefile:538: backdoorGcc64.lo] Fehler 1
Reproduction steps
...
Expected behavior
./configure should detect 32 bit x86, thus compiling backdoorGcc32.c, instead of backdoorGcc64.c
Additional context
No response
Would you care to provide some information about what Linux version and release on which you are encountering this problem? And also, what version of open-vm-tools you are trying to build and whether you are building from a git clone or a source tar bundle?
The GNU autoconf tools have always used the output of config/config.guess to determine the default architecture of the target build. I do not know if autoconf would change the architecture when working in a 32-bit sysroot on a 64-bit kernel. Your reported failure suggests not.
I am assuming the since the build selected backdoorGcc64.c, it is not aware of that environment differences.
After first running "autoreconf -fi", check the output of config/config.guess.
This sounce like something akin to cross-compilation. See https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html for details.
I believe that adding something like "--build=i686-pc-linux-gnu" to the ./configure command will select the backdoorGcc32.c. Actually, I have confirmed that with that option backdoorGcc32.c is selected. And if your compiler and assembler are reunning as 32-bit compiles, you should be good.
Would you care to provide some information about what Linux version and release on which you are encountering this problem?
devuan chimaera
And also, what version of open-vm-tools you are trying to build and whether you are building from a git clone or a source tar bundle?
git master.
The GNU autoconf tools have always used the output of config/config.guess to determine the default architecture of the target build. I do not know if autoconf would change the architecture when working in a 32-bit sysroot on a 64-bit kernel. Your reported failure suggests not.
Yes, it seems the actual evil is config.guess, which is calling uname, that obviously doesnt care about what userland is actually running. It's ignored when explicitly passing --host=<...>
I am assuming the since the build selected backdoorGcc64.c, it is not aware of that environment differences.
Yes, it's trying to build for the cpu instead of the corresponding userland.
This sounce like something akin to cross-compilation. See https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html for details.
Indeed that would work. Just pretty ugly having to do that for just plain non-cross compiling :(
I believe that adding something like "--build=i686-pc-linux-gnu" to the ./configure command will select the backdoorGcc32.c. Actually, I have confirmed that with that option backdoorGcc32.c is selected. And if your compiler and assembler are reunning as 32-bit compiles, you should be good.
More precisely: the knob is --host (the one we're compiling for, not we're compiling on), but just telling --build will implicitly setting --host and --target to the same value (yes, autoconf can be a bit confusing) ;-)
--mtx