port:clamav should use rust or compiler_wrapper PG (and the rust PG might be simplifiable)

[RJVB (René Bertin)]

Trying to build port:clamav on my 10.9.5 system I ran into a failure building the components written in rust.

I was about to give up under the assumption that my OS is too old, but then saw noticed the 'cc' in the error message. On a hunch I thought this might be more than a mode switch (as used by libtool, for instance), created a couple of symlinks mapping cc to ${configure.cc} and c++ to ${configure.cxx}, prepended their location to env(PATH) (simpler than guessing which foo.env I'd need) and the build completed!

I assume that making port:clamav use the rust should fix the issue too. I haven't tried to verify this though; the clamav build system invokes rustc in a rather obfuscated manner.

(BTW: does rustc always invoke the C compiler as cc by default?)

[danielluke (Daniel J. Luke)]

port:clamav does use port:rust

If you can provide build logs from the failed (and successful) builds, that would be helpful. Alternatively you could supply a patch that you've tested (that perhaps uses the compiler_wrapper portgroup). I don't have access to older MacOS versions so I can't develop fixes for them, however I'm not opposed to updating the port to support them as long as the changes don't negatively impact the currently supported MacOS versions.

[RJVB (René Bertin)]

build failure with the "stock" port on OS X 10.9; presumably because rust invokes cc

[RJVB (René Bertin)]

use the rust PG instead of a port:rust depspec

[RJVB (René Bertin)]

Tested with

> cd /path/to/tree/sysutils/clamav port -nok -v build configure.compiler=macports-clang-9.0 configureccache=yes build.jobs=1

There's no point in attaching the successful build log; it just shows a whole bunch of "Compiling foo vX.Y.Z" lines instead of the actual commands showing which compiler is being used.

[danielluke (Daniel J. Luke)]

We'd want to make changes so that the port built successfully for people without them having to manually specify the compiler - do we also need to set compiler.blacklist/whitelist for 10.9?

[RJVB (René Bertin)]

Yes, you'd probably want to do that. I just have no idea what the earliest sufficiently capable clang version is, or what the oldest OS version where the port builds would be. I guess that might be determined by rust ...

I do know that the most recent pre-rust clamav version is 0.104.4 .

[pcafstockf (Frank Stock)]

Indeed, the problem is that rust 1.7.x will not compile on 10.9 (or even 10.13), because rust 1.7.x requires clang-16 and (at least as of HighSierra), clang-10 is the best we get. I did try the rust PG patch provided by RJVB, but it did not work for me, and I don't understand the MacPorts internals well enough to know why.

I need to build clamav as a custom package binary, which means I need a custom MacPorts installation to build clamav. Normally MacPorts would just install a rust 1.7.x binary package on High Sierra, but if you are working with a custom / multi - install, that doesn't work.

Ultimately I installed standard MacPorts on High Sierra, and then installed the rust and cargo packages there. Then installed a second (custom) MacPorts with a local Portfiles repository containing the clamav Portfile. I changed that Portfile from port:rust to bin:rustc:rust. Basically telling the custom MacPorts to use rustc from the default MacPorts. If that weren't convoluted enough, the custom MacPorts doesn't search /opt/local/bin/rustc, so I had to symlink that to /usr/bin/rustc.

But I did ultimately get a custom binary package of clamav.

I've got to believe there is an easier way, and would love to have somebody point out the "right" way to do it. But in the meantime if you need a custom binary package of anything that depends on rust, I can confirm this does actually work.

[kencu (Ken)]

clang-16 works nicely on 10.9. It is available back to 10.6 SnowLeopard in MacPorts ( there is a PR for 10.5 Leopard Intel as well).

​https://packages.macports.org/clang-16/

[pcafstockf (Frank Stock)]

Replying to kencu:

clang-16 works nicely on 10.9. ...

Indeed! Thank you. I got so caught up thinking Xcode clang 16, that I forgot one can just install the clang-16 port.

Of course when creating a custom MacPorts install, clang-16 won't just "install" binary package dependencies, it wants to build them from scratch. So you end up building clang-14, which depends on clang-11, which depends on clang-9, and you end up in an all day build :-).

But, by installing clang-14 and clang_select in the default MacPorts installation, then adding that to the PATH for the custom MacPorts installation, the custom installation built only clang-16, which then allowed for building rust and cargo, and eliminated all the jankiness I described above. No more customizing clamav or any of the other rust dependent ports I subsequently wanted in the custom install.

Thanks again!

[danielluke (Daniel J. Luke)]

Replying to pcafstockf:

But, by installing clang-14 and clang_select in the default MacPorts installation, then adding that to the PATH for the custom MacPorts installation, the custom installation built only clang-16, which then allowed for building rust and cargo, and eliminated all the jankiness I described above. No more customizing clamav or any of the other rust dependent ports I subsequently wanted in the custom install.

So we just need to force macports clang-16 on 10.9? I don't have a 10.9 system to test with, but I'm happy to accept patches. I'm going to close this, but feel free to re-open if anyone can provide a patch that works.