<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 18, 2016 at 12:35 AM, Alexey Kuznetsov <span dir="ltr"><<a href="mailto:kuznetsov.alexey@gmail.com" target="_blank">kuznetsov.alexey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">I read emerying carefully. Very informative. But you missing a point. I'm not talking why it is not possible. Do you think all Linux distoros more compatible between each other than Mac with three build </div></div></blockquote><div><br></div><div>As someone who's been involved with Linux almost from the beginning, and has been a Linux sysadmin for several decades: I *know* they are more compatible. I mean, the "alien" program (which converts between various Linux package formats) has existed for almost as long as Linux distributions have; while it can't translate differences between init systems, for most applications it's an ugly but effective way to use packages from one Linux distribution on other distributions. And LSB (and Red Hat's crusade to slam systemd down everyone's throat) has largely mitigated the other differences.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">system's? They all have problem you mention, including absolute path linking (they are using same liking tools) and more! But they all understand they need to be together and they find the way. I'm </div></div></blockquote><div><br></div><div>ELF does *not* use absolute paths. Mach-O does. It also appears that you did not notice that OS X ld is *not* binultils ld, and binutils ld is known to cause various things to break badly on OS X, even when it's not lagging the latest Apple changes to Mach-O "load commands" (runtime loader opcodes). (And it certainly isn't gold, which only works on ELF objects.)</div><div><br></div><div>ELF objects contain references to SONAMEs of the form libFOO.so.N, which are located via $LD_LIBRARY_PATH and/or /etc/ld.so.cache, and as long as the FOO and the N are the same (and most systems have compatibility library packages to ensure that) stuff will generally work. And, barring systems like Gentoo (which is often looked down on by users of other Linuxes, in part for this reason), the libraries are built with the same or compatible options everywhere.</div><div><br></div><div>Apple-provided, Fink, MacPorts, and Homebrew all use different library paths, deliberately because of default build options and compatibility issues. MacPorts and Homebrew both are similar to Gentoo (more correctly, all of them are similar to the BSD ports system) in that it's easy for users to change library options in incompatible ways. You see this in MacPorts when using non-default variants causes archives to be ignored in favor of local builds --- because variants don't just change what files are installed, they change how the program is built. The prebuilt archive's libraries, if any, will not be compatible with what you build with non-default options.</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>