pcre2 @10.42: no such instruction: `lzcnt %eax, %eax'

[kencu (Ken)]

pcre2 build fails on Leopard Intel with this assembler error.

one option is forcing clang-N as the compiler.

pcre is in the bootstrap chain to build macports-clang, but pcre2 is not.

:info:build /bin/sh ./libtool  --tag=CC   --mode=compile /usr/bin/gcc-4.2 -std=gnu99 -DHAVE_CONFIG_H -I. -I./src  "-I./src" -I/opt/local/include -DPCRE2_CODE_UNIT_WIDTH=8 -fvisibility=hidden     -D_THREAD_SAFE  -pipe -Os -arch i386 -MT src/libpcre2_8_la-pcre2_tables.lo -MD -MP -MF src/.deps/libpcre2_8_la-pcre2_tables.Tpo -c -o src/libpcre2_8_la-pcre2_tables.lo `test -f 'src/pcre2_tables.c' || echo './'`src/pcre2_tables.c
:info:build libtool: compile:  /usr/bin/gcc-4.2 -std=gnu99 -DHAVE_CONFIG_H -I. -I./src -I./src -I/opt/local/include -DPCRE2_CODE_UNIT_WIDTH=8 -fvisibility=hidden -D_THREAD_SAFE -pipe -Os -arch i386 -MT src/libpcre2_8_la-pcre2_substitute.lo -MD -MP -MF src/.deps/libpcre2_8_la-pcre2_substitute.Tpo -c src/pcre2_substitute.c  -fno-common -DPIC -o src/.libs/libpcre2_8_la-pcre2_substitute.o
:info:build {standard input}:9052:no such instruction: `lzcnt %eax, %eax'
:info:build {standard input}:9062:no such instruction: `tzcnt %eax, %eax'
:info:build {standard input}:9307:no such instruction: `lzcnt %eax, %eax'
:info:build {standard input}:9317:no such instruction: `tzcnt %eax, %eax'
:info:build {standard input}:9349:no such instruction: `lzcnt %eax, %eax'
:info:build {standard input}:9359:no such instruction: `tzcnt %eax, %eax'
:info:build {standard input}:9396:no such instruction: `lzcnt %eax, %eax'
:info:build {standard input}:9406:no such instruction: `tzcnt %eax, %eax'
:info:build {standard input}:9438:no such instruction: `lzcnt %eax, %eax'
:info:build {standard input}:9448:no such instruction: `tzcnt %eax, %eax'
:info:build {standard input}:9853:no such instruction: `lzcnt %eax, %eax'
:info:build {standard input}:9863:no such instruction: `tzcnt %eax, %eax'

[larryv (Lawrence Velázquez)]

This looks fine to me, assuming the compiler exclusion can't be any tighter.

[larryv (Lawrence Velázquez)]

In 91bf278a93f819772fc65dff95b77179799a5f92/macports-ports (master):

pcre2: Don't try to build with ancient GCC

Thanks to @kencu for the fix!

Closes: #66723

[mascguy (Christopher Nielsen)]

There's one major downside to this on 10.5: It's now built with a much newer Clang by default - pulling in gcc10-bootstrap, etc, all built from source - which is completely unnecessary.

However, based on testing a few days ago, it builds just fine with macports-clang-3.4.

Bear in mind that git now depends on this port, so it could be considered a bootstrap-ish component. (Maybe not formally, but certainly necessary for us Devs.)

But I don't know what the best approach is. Should we whitelist macports-clang-3.4 for 10.5 and prior only? Or...?

[kencu (Ken)]

MacPorts modifications to cctools will force the assembler to punt off to a newer clang for assembling.

To really test if clang-3.4 works, you would have to make sure that all newer clangs are deactivated.

[kencu (Ken)]

By the way, my "long term" plan for the toolchain on older systems (everything < 10.11, say), would be to have gcc10-bootstrap build clang-11-bootstrap, and then use that to build the toolchain.

So clang-3.3, 3.4, 5.0, 6,0, 7.0, 8.0, 9.0, and 10.0 would all disappear.

[mascguy (Christopher Nielsen)]

Replying to kencu:

MacPorts modifications to cctools will force the assembler to punt off to a newer clang for assembling.

To really test if clang-3.4 works, you would have to make sure that all newer clangs are deactivated.

Yep, the only version I have installed, is MacPorts clang-3.4. (Plus the Xcode 3.1.3 CLT.)

I just re-ran the build on my MacBookPro - at least through destroot - and attached the log; filename: pcre2-build-10.5-clang-3.4.log.gz.

[kencu (Ken)]

That is a bit strange, then. You see, the error is with the assembler.

When you are building with gcc-4.2 on 10.5, you are using the ancient "gas" assembler that comes with cctools. So no surprise it fails on newer assembly.

When you are building with clang-3.4 on 10.5, you are still using the ancient "gas" assembler that comes with cctools. The integrated assembler is not used (by default), and also cctools will not use clang-3.4 as assembler.

So it should not work. Must be something going on to explain what is happening.

[mascguy (Christopher Nielsen)]

Replying to kencu:

That is a bit strange, then. You see, the error is with the assembler.

When you are building with gcc-4.2 on 10.5, you are using the ancient "gas" assembler that comes with cctools. So no surprise it fails on newer assembly.

When you are building with clang-3.4 on 10.5, you are still using the ancient "gas" assembler that comes with cctools. The integrated assembler is not used (by default), and also cctools will not use clang-3.4 as assembler.

So it should not work. Must be something going on to explain what is happening.

Is it possible that the native assembly component isn't being used, in favor of portable C code? (Assuming that upstream provided that fallback?) Haven't dug into it enough to say, but that would be my theory.

[kencu (Ken)]

OK, I was wrong about when the integrated assembler defaulted on.

clang-3.4 does use it by default, so that’s the mystery solved.

​https://github.com/llvm/llvm-project/blob/d13f57a1a1a1cc23c97bf5b99b89f28f8b8c1149/clang/lib/Driver/ToolChains.h#L333

[mascguy (Christopher Nielsen)]

Replying to kencu:

By the way, my "long term" plan for the toolchain on older systems (everything < 10.11, say), would be to have gcc10-bootstrap build clang-11-bootstrap, and then use that to build the toolchain.

So clang-3.3, 3.4, 5.0, 6,0, 7.0, 8.0, 9.0, and 10 would all disappear.

While I like that idea in principle, it's also nice to be able to have a slimmed-down MacPorts installation. But if folks have to wait many hours - or several days, for old PPC machines - for toolchain components to build from source... yikes!

Just curious, how many would be involved, with the new approach?

[mascguy (Christopher Nielsen)]

Per Ken's follow-up e-mail:

Everything is always open for discussion, being an opensource, volunteer project, for sure.

We may never do what I suggested, or perhaps some variation of it. Someone may want to keep around clang-3.4 or 3.7 for some reason.

I just look for the simplest, most direct approach.

gcc10-bootstrap is the last gcc version that can reliably boot from system roots on all systems (even Tiger, headaches though there may be). So that will be the launchpad for all the newer gcc versions (gcc12 and 13 at present). All older systems will need to have access to that. Most users should get it as a prebuilt binary from the build servers.

The current gcc10-bootstrap is not right yet. It will need to be rebuilt differently. For example, the "universal" gcc10-bootstrap on Leopard has the powerpc part as powerpc code and the Intel part as intel code -- so it is not universal. A powerpc mac cannot use it to build Intel code, for example.

But once gcc10-bootstrap is properly sorted out someday, using it to build clang11-bootstrap, and using that to build a current macOS toolchain and the latest clang compiler it can build (probably clang-14) seems just sensible. There is no reason to go through the current clang mess of clang-3.4 -> clang-3.7 -> clang-9.0 -> clang-12 (I think) -> clang-14 -> clang-current. That is just -- well -- insanity really.

By "how many involved" if you mean humans, no idea. Anyone who cares to be, although too many opinions leads to paralysis, as we have seen here before. Probably not even will be me involved, to be honest, as I have too much too do elsewhere and I am mostly using an arm Mac running Ventura at present.

Sorry for the confusion, I was just asking how many toolchain ports would need to be built from source. But it sounds like just gcc10-bootstrap, along with one or two others? That's not bad at all!

If we can keep clang-3.4 around though, that would be good: While it doesn't support compiling many ports these days, it is sufficient for the fundamentals. (Including bash, coreutils, git, and a number of other basics.) But sure, it definitely makes sense to drop the numerous other Clang versions beyond that, if the chain can be simplified with gcc10-bootstrap as a foundation.

So it all sounds good Ken. Looking forward to seeing the work progress!

[catap (Kirill A. Korinsky)]

To be honest universal build as Ken describes it simple doesn't supported by GCC. Someone needs to introduce that support into GCC :)

[kencu (Ken)]

The build system of gcc supports any combination of build, host, and target. So it can be done. But getting the build right is a bit tricky, and the meaning of universal is a bit more involved than what MacPorts defaults to mean.

Take for example a true universal build of gcc for Intel and Arm on Ventura.

You would have to build gcc four times (host/target as Intel/Intel, Intel/arm, arm/Intel, arm/arm), and lipo them all together. Then you have a universal gcc that can build either arch on either machine. (All four builds can be done on either an Intel or Arm Mac.)

Right now our build is (host/target Intel/Intel, arm/arm) and so we wind up with a universal gcc version that has Intel code that outputs Intel binaries and arm code that outputs arm binaries. It's close to what we need, and it is what MacPorts means by "universal" only partially. It can build universal binaries only on some systems by using rosetta.

(I'll leave the Intel and powerpc subtypes to a separate thought, but the multilib feature thankfully makes that easier.)

[catap (Kirill A. Korinsky)]

Ken, I doubt that. -arch option is implemented per driver and powerpc driver hasn't go any idea about arm or x86 arches.

So, we need a some kind of driver for driver which may route by arch option to the right driver.

:(

[kencu (Ken)]

porting the driverdriver.c from apple-gcc42 to newer gcc versions is a separate issue from building a universal gcc.

that would make gcc easier to use when building universal software, but has nothing to do with building it universal.

:)

[kencu (Ken)]

well, that’s not quite the full story.

if gcc had a working driverdriver.c it would make bootstrapping to a fully universal gcc a bit easier, certainly, by combing several steps into one step.