orc @0.4.27: error: can't find a register in class ‘BREG’ while reloading ‘asm’

[Umo022 (alancom2@yahoo.com)]

When I'm upgrading wine, among the dependencies being rebuilt is orc (depended upon by gstreamer1-gst-plugins-base and pulseaudio, which in turn, wine eventually depends on). When orc is being built, it fails with the following error:

:info:build   CC       liborc_0.4_la-orccpu-x86.lo
:info:build   CC       generate_bytecode-generate-bytecode.o
:info:build orccpu-x86.c: In function ‘get_cpuid_ecx’:
:info:build orccpu-x86.c:99: error: can't find a register in class ‘BREG’ while 
reloading ‘asm’:info:build orccpu-x86.c:99: error: ‘asm’ operand has impossible constraints

with the associated code being:

#if defined(HAVE_I386)
  __asm__ (
      "  pushl %%ebx\n"
      "  cpuid\n"
      "  mov %%ebx, %%esi\n"
      "  popl %%ebx\n"
      : "+a" (*a), "=S" (*b), "+c" (*c), "=d" (*d));
#elif defined(HAVE_AMD64)

  /**** ERROR HAPPENS HERE ****/
  __asm__ (
      "  cpuid\n"
      : "+a" (*a), "=b" (*b), "+c" (*c), "=d" (*d));
#endif
}

Now, the thing being that I'm running MacOS 10.6 "Snow Leopard" on a MacBook, I don't have an AMD64 processor, but I do have an I386 (an Intel Core 2 Duo to be precise), so it looks to me that the wrong branch is being taken on that #elif. However, I haven't been able to figure out where the HAVE_AMD64 symbol is being defined. Maybe a build script error?

I thought that maybe my setup had been corrupted somehow, so I completely wiped my macports installation and macports and wine from scratch. I ended up with the same error.

Unfortunately, orc doesn't have a maintainer, so since this happened while I was trying to build wine, hopefully someone on this end can help ...

Thanks.

[Umo022 (alancom2@yahoo.com)]

orc 0.4.27 build failure session

[ryandesign (Ryan Carsten Schmidt)]

I don't know yet why it fails to build universal on Snow Leopard, but I can at least answer some of your questions.

The Intel Core 2 processor is a 64-bit processor using the x86_64 architecture and also compatible with running software made for the i386 architecture, as are all subsequent Intel processors used in Macs. Only the very first Intel Macs used the original Intel Core processor which is 32-bit and thus limited to using only the i386 architecture. The x86_64 architecture is also known as the amd64 architecture because it was created by AMD. Although you have a 64-bit processor, wine in MacPorts is 32-bit, so all its dependencies, including orc, must be built universal—that is, for both i386 (for the benefit of wine) and x86_64 (for any other 64-bit software you might install using MacPorts). Your log shows successful compilation of the x86_64 part, and a problem when building the i386 part, specifically some assembly code.

This problem did not manifest in the previous version of orc, 0.4.26. It also does not manifest with 0.4.27 on Lion or later. This suggests there was a change in the assembly code or the build system in 0.4.27 that was not tested on the older toolchain on Snow Leopard.

It looks like the separate 32-bit and 64-bit non-universal builds of orc 0.4.27 succeeded on our Snow Leopard buildbot workers, but the universal build did not; this may indicate that the build system is not providing the correct arch flags to all parts of the build (specifically the assembly part of the build) though that would not explain why it works on Lion and later.

[kencu (Ken)]

While I'd suggest compiling it with clang-3.9 instead, this <​https://stackoverflow.com/questions/4010069/problem-on-mac-cant-find-a-register-in-class-breg-while-reloading-asm> suggests a way to allow gcc-4.2 to work.

[ryandesign (Ryan Carsten Schmidt)]

Ken, I don't intend to change the compiler, when gcc-4.2 was able to compile the code before. I intend to fix the build system so that gcc-4.2 can once again compile it.

The reporter was right: the wrong path in the #if statement is being used. The HAVE_AMD64 path is being used even when the 32-bit part is being built and the HAVE_I386 path should be used. The code in question changed between 0.4.26 and 0.4.27 in the following way:

orc/orccpu-x86.c

@@ -88 +88 @@
 {
   *a = op;
   *c = init_ecx;
-#ifdef __i386__
+#if defined(HAVE_I386)
   __asm__ (
       "  pushl %%ebx\n"
       "  cpuid\n"
       "  mov %%ebx, %%esi\n"
       "  popl %%ebx\n"
       : "+a" (*a), "=S" (*b), "+c" (*c), "=d" (*d));
-#elif defined(__amd64__)
+#elif defined(HAVE_AMD64)
   __asm__ (
       "  cpuid\n"
       : "+a" (*a), "=b" (*b), "+c" (*c), "=d" (*d));

So the code changed from using reliable compiler-defined constants to using unreliable project-defined constants. The project-defined constants were already defined in previous versions and were used in other places.

The project-defined constants appear to be based on the --host configure parameter. We years ago came to the conclusion that relying on that parameter is unreliable and so MacPorts doesn't set it and we expect configure scripts not to care about it. But this configure script does, so we must set it correctly.

Since the configure script behaves incorrectly when --host has not been set, this means that even when it appeared to compile correctly on Lion and later, the result is most likely not correct, so I'll revbump to make sure everybody rebuilds it correctly.

[ryandesign (Ryan Carsten Schmidt)]

In aefa645892a30a1090a3344c1c2b0bf85ffaeabc/macports-ports:

orc: Specify --host to fix cross compiling issues

Closes: #54616