Resolve test failures on mac: ignore the compile warning

[GiudGiud]

not the most glorious way of fixing this but copilot says the alternative is to write wrappers, which I think defeat the purpose of the templating done here?

Happy to close this if you have a better solution

refs #4387

[moosebuild]

Job Coverage, step Generate coverage on cfcb218 wanted to post the following:

Coverage

	5dc1f0	#4388 cfcb21
	Total	Total	+/-	New
Rate	65.31%	65.31%	-0.00%	-
Hits	77608	77606	-2	0
Misses	41220	41222	+2	0

Diff coverage report

Full coverage report

This comment will be updated on new commits.

[GiudGiud]

Test failures are in metaphyscl and unrelated

[roystgnr]

copilot says the alternative is to write wrappers

Wait - this isn't a mix of incompatible XDR installations, this is a single XDR implementation that's incompatible with itself?

Or ... is it an XDR implementation that's incompatible with the original XDR definition?

    With Mac OS X 10.9, xdrproc_t is no longer defined as:
    
    typedef bool_t (*xdrproc_t)(XDR *, ...);
    
    but instead as:
    
    typdef bool_t (*xdrproc_t)(XDR *, void *, unsigned int);
    
    For reference, Linux systems typically define it as:
    
    typedef bool_t (*xdrproc_t)(XDR *, void *, ...);
    
    The rationale explained in the header is that using a vararg is
    incorrect and has a potential to change the ABI slightly do to compiler
    optimizations taken and the undefined behavior. They decided
    to specify the exact number of parameters and for compatibility with old
    code decided to make the signature require 3 arguments. The third
    argument is ignored for cases that its not used and its recommended to
    supply a 0.

I don't see how a decade-old API change has started biting us now, but I don't think it's safe to just cast a function taking 2 args to a function taking 3 and cross our fingers about what happens at runtime. I'd like to see what the official Apple word is on all this, but a search for "xdrproc_t site:apple.com" just brings up this: a URL for an iOS man page with a header saying it's an OSX man page and the text of a BSD man page, wherein xdrproc_t is repeatedly used but never defined.

Logan switched our recipe environment yesterday to try to work around this mess, but if this is an OSX issue and not just an Intel-Mac-software-decay issue then we're going to need a more robust solution. Let me see what I can do.

[roystgnr]

this is a single XDR implementation that's incompatible with itself?

Or ... is it an XDR implementation that's incompatible with the original XDR definition?

I was somehow still too pessimistic here - it looks like it's an XDR implementation that's incompatible with the original XDR definition and incompatible with itself. The compiler's not complaining that we're trying to cast our own functions of an incompatible type to xdrproc_t, it's complaining that we're trying to cast standard XDR functions, which are apparently of an incompatible type there, to xdrproc_t.

I'm going back to my "Intel-Mac-software-decay" hypothesis, but with more disdain this time. Those function types do look incompatible to me, not just the compiler, and if they are incompatible then letting something call them after casting from one to the other is undefined behavior. If the new recipe works fine then I'm personally okay with letting libMesh on the old environment serve as a cautionary tale rather than as a finite element library.