Is this possible, since Apple has open sourced the code (libdispatch?) I'm bit confused as to how one can make use of this. Is this like a library with an API that any application can make use of, or an OS feature built into Mac OS X? Can application built "for" Macs and iPhone (with iOS 4) alone make use of this library?
I assume one has to run a port to make gcc also compatible with the new semantic that Apple has introduced.
It's almost a year later but I'm using it quite happily on Ubuntu Natty. Proper packages are coming in Oneiric.
Having read the Ars Technica overview, it appears there are several challenges
GCD makes extensive use of blocks (an Apple extension to C that approximates closures) which means your compiler needs to support blocks. The standard version of gcc has no support for blocks, so you'll either have to port Apple's changes to the Linux gcc or use clang/llvm.
The Mac OS X version of GCD involves some code in the kernel. Clearly, if kernel changes are required to Linux to support GCD, that is a major piece of work. However, it seems that a user space only port is possible.
GCD is licensed under the Apache License. Apparently, this license is not compatible with GPL v2. So you cannot use GCD in any app distributed under GPL v2. GPL v3 is OK though, so an app licensed under GPL v2 "or later" is OK.
Having said all that, the FreeBSD port has been done, so it must be possible.
Related
You know the ARM-based M1 chips that are used in modern mac computers. On those macs, some number of software are ran through the layer called Rosetta (Discord, Steam), some natively, directly through M1 (Slack, IntelliJ) and some actually doesn't work in either way (Virtual Box). Huge list holding the status can be found here.
Apps that can be ran only with Rosetta are not yet M1 optimized, their developers have to optimize it, it takes some time to do so. But what does it mean to optimize it? What the process looks like? I'm quite sure that they don't rewrite the whole application code to another language (like Swift), because Jetbrains was able to M1 optimize their apps quite quickly. On the other hand, Discord is not yet optimized, same for Unity game engine (it's in beta though).
At bottom, it just means that the compiler's backend was configured to emit ARM64 instructions for the program instead of (or in-addition to) x86-64 instructions.
This means that certain x86-64 specific functionality instruction can no longer be used, unless equivalent ARM instructions are used instead.
This usually isn't much of a problem though, because most macOS software is typically written at a higher level of abstraction, using system-provided frameworks.
For example, using CoreImage to manipulate images abstracts you from the details of the CPU and GPU. In such cases, Apple does the heavy lifting of porting over their frameworks. All you have to do as an application developer is to check a box that says "target ARM64".
Is Halide's Hexagon targeting supported on 820E Linux platforms?
The Github project says:
The currently supported combination of targets is to use the HVX target features with an x86 linux host (to use the simulator) or with an ARM android target (to use Hexagon DSP hardware).
Is targeting Linaro / Linux also supported, as well as Android?
There's no major technical reason that I'm aware of that it shouldn't be supportable on Linaro/Linux (vs Android); however, you'd probably need to update the Halide runtime code as needed to support hvx operations on Linux (vs Android) -- e.g. loading and calling code, code signing issues, etc. I don't know of any reason the Halide maintainers wouldn't welcome. (It's probably worth asking about this on the Halide mailing list and/or Gitter channel, where various Qualcomm folk could probably shed more light on what's needed.)
Does anyone know library to browse (and upload/download/stream) on smb shares (SMB/CIFS protocol) from iOS. This must be support for all the Windows OS. This is grade help for me.
Not quite an answer to your question, but I have some tips:
If you write your own client, don't trust the IETF RFC. Microsoft
hasn't been scrupulous in its adherence to the spec. And be sure to
test with Unicode file/folder names, all major versions of Windows,
and so on.
Don't write your own client. :-)
If you use an open-source library, make sure it's not GPL or LGPL,
unless you plan to open-source your entire project. LGPL almost
works—it does on Mac OS X—but it requires dynamic linking, which
isn't supported on iOS.
You may see apps in the app store that use GPL or LGPL libraries,
but don't assume that it is safe to use them yourself. Those apps
are often blatantly abusing the license.
opensource.apple.com has an smb client that's a great reference but
it's a file system kernel extension, so you can't use it directly.
Initial note: The question mentions AIX because it is the initial context but the question really pertains to gcc itself, most probably regardless of the platform.
AIX is supposed to be backwards binary compatible: a C program compiled on AIX 5.1 will run as is on 5.2, 5.3, 6.1 and 7.1.
In my understanding gcc should be built to target a specific system (whether the current one or another one in the case of cross-compiling). So, gcc built on AIX 6.1 targets AIX 6.1, and produces binaries usable on both 6.1 and 7.1 thanks to binary compatibility.
Yet gcc itself built on AIX 6.1 is a 6.1 program, so it should execute on 7.1 as is. Of course if I compile a program with it on 7.1, this program might get linked or use headers specific to 7.1, thus making the resulting binary requiring 7.1. So as far as I understand it, I should be able to run gcc built on AIX 6.1 onto a 7.1 machine, and produce maybe non-optimal yet perfectly valid binaries, although they would require 7.1 as a side effect of linking.
This looks too much like rainbows and unicorns dancing in glittery skies. I smell something fishy but lack any knowledge of gcc innards. Please mighty crowd, enlighten me.
tl;dr: Can gcc built on and targeting a version N of an OS/platform be run and used on version N+1 by virtue of platform binary compatibility to produce binaries running on version N+1? If not, what mechanism would prevent it?
Here's enlightenment: your question is way too general. In order to answer it, someone would have to have knowledge of
the operating systems you care about
the OS versions you care about
the gcc versions you care about
and then research the binary compatibility in this three dimensional matrix.
Mechanisms preventing binary compatibility are too numerous and directly correlate to your OS and compiler vendor's ingenuity at breaking it. One of the more common and documented ways being official deprecation of API calls, removal of compatibility libraries shipped, and bridges being burnt, like going from a.out to ELF.
Right. I'm currently in a class that is exploring many different programming languages. Among them are COBOL and Ada, both of which I can't seem to find a free compiler. Has anyone had better luck and if so, where might I find them? Thanks!
You want the GNAT GPL Edition.
There is much available for Ada at http://libre.adacore.com/libre/, including Eclipse plugins and IDEs. Free downloads are available for students.
The OpenCOBOL compiler is free. As far as I know there are versions for Windows, Linux and Mac OS X - http://www.opencobol.org
Edit : A possible option might be Veryant isCOBOL http://www.veryant.com. Veryant are due to release a student version (i.e. restricted) of their compiler. Veryant's isCOBOL compiler compiles to a Java run-time and as such may run on OS X.
Their faq http://www.veryant.com/products/faq.php?type=all states that "Being Java-based, the isCOBOL Compiler runs on any platform that supports a Java Development Kit (JDK) version 1.4.2 or greater. The isCOBOL Debugger and isCOBOL compiled code can run on any platform that supports a Java Runtime Environment (JRE) of 1.4.2 or later. Thus, isCOBOL APS supports a wealth of platforms including AIX, HP-UX, Linux, Solaris and Windows. The only exception to this is isCOBOL ISAM ODBC, which currently runs only on Windows."
gcc's Ada compiler, gnat, does not come with Xcode so you will need to find it elsewhere or build it from source. Free COBOL compilers are a bit harder to find.