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

[Ken Cunningham]

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
>    legacy.support darwin 10
>    # legacy.support {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 :> 

Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170525/dea0d885/attachment.html>