libzzip fails to build on Snow Leopard -> snowleopardfixes can help also

Ken Cunningham ken.cunningham.webuse at
Fri May 26 05:27:27 UTC 2017

On 2017-05-25, at 12:32 AM, Mojca Miklavec wrote:
> I don't know what the cleanest approach would be, but I like the idea.
> I can imagine a PortGroup, something in the spirit of:
>    PortGroup legacy 1.0
> darwin 10
>    # {darwin < 11}
> which would add a dependency and append the necessary flags for darwin10.
> (The library could be built statically.)
> Mojca

It works quite well, and it's easy to control. The only thing I can think of that would be better and even more transparent would be to link it in with clang when needed, as Apple has done with some other library functions, like this bit from the clang patches in ToolChains.cpp:

+    if (isMacosxVersionLT(10, 5))
       AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.10.4.a");
-    } else {
-      if (getTriple().getArch() == llvm::Triple::x86)
-        AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.eprintf.a");
+    else
       AddLinkRuntimeLib(Args, CmdArgs, "libclang_rt.osx.a");
-    }

This actually would be a pretty sweet way to go with this issue. 

You'd have to put that together with an #include_next for a copy of string.h and perhaps a few other headers that define the missing functions.

Of course, it's better for authors to test for all the missing functions, but as these are all common functions for the past 10+ years, that might be a bit too much to ask. 

Or I could just give up on 10.6.8 and get in the modern era :> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-users mailing list