I have Firebreath plugin for Mac that I need to port to Linux
I am trying to find the replacement dependencies for the Linux version. Here is the dependencies I have in my cmake for Mac:
find_library(COCOA_F Cocoa)
find_library(FOUNDATION_F Foundation)
find_library(APPKIT_F AppKit)
find_library(COREDATA_F CoreData)
find_library(AGL_F AGL)
find_library(CARBON_F Carbon)
find_library(AUDIOTOOLBOX_F AudioToolbox)
find_library(COREAUDIO_F CoreAudio)
find_library(AUDIOUNIT_F AudioUnit)
find_library(QUARTZCORE_F QuartzCore)
find_library(QUICKTIME_F QuickTime)
find_library(OPENGL_F OpenGL)
find_library(QTKIT_F QTKit)
So far,
OpenGL => freeglut3 ?
Cocoa => GLFW ?
any suggestions for the other dependencies?
It is very unlikely that there are many direct replacements for these. Rather than looking for direct replacements for each library, figure out what functionality you need and find libraries that provide it.
For example, Carbon covers so many different types of things that it's impossible to guess what libraries on linux you'd actually need. CoreAudio is a little more clear, as it deals with sound, but are you doing sound playback or some other type of sound manipulation?
Better to look for libraries that provide the functionality you need. For example, for sound playback you'll likely want alsa. OpenCV or video4linux both give you webcam access, etc.
Once you have broken it down to what functionality you need a bit of google searching will almost certainly answer your questions without needing to rely on outside help and you can save your questions for specific problems you may run into while doing the port.
Related
I have a small OpenGL application that has been developed using GLUT. What are my best options to render directly to a Linux framebuffer (fbdev) with OpenGL, without an X-Server? I understand that GLUT needs X, so I'm not looking for ways to use GLUT without X.
The framebuffer device I intend to use is confirmed working with fbi and mplayer.
I have done (or I'd like to think that I have done) a pretty exhaustive research, and found some resources and libraries that might work. But most of the info is a bit outdated, and I'm not sure what to trust.
DirectFB looks good, exactly what I'm looking for, but does not seem to be in active development.
I'm inclined to try this out on my target device: https://github.com/mcdoh/glGears-on-DirectFB-with-OpenGL-ES - but again, this is the only example code I can find, and it's six years old.
Mesa is another interesting candidate, but I can't seem to find any recent information.
This looks interesting: http://www.mesa3d.org/glfbdev-driver.html - but I can not find any example code to go from.
So, while a lot of SO answers mention DirectFB and Mesa as solutions, I can't bring myself to be confident in those options while so little material can be found.
So, if you can point me in the right direction here, give me any examples to go from, that would be highly appreciated. What am I missing?
Edit due to question being marked as duplicate:
The answer to the related question recommends using DRM. I intend to run my code on an Allwinner H3-based embedded computer that does not yet support the mainline Linux kernel. Currently, it's running on kernel version 3.14, which I believe does not have DRM support.
So, are there any alternatives?
I need to find a sound library for haskell. I have followed instructions of some that are presented in haskell wiki http://www.haskell.org/haskellwiki/Sound_data_structures but couldnt get any to work. All i need is to play audio files, regardless its format.
I am developing a game with FunGen, and its time for music. I may have somo problems making them work togather, but I cant even play a simple sound example.
Most of my problems are due to cabal installation, or dependancies I cant find anywhare. I am using Windows.
Being on Windows is a major limitation in Haskell audio. Most packages are bindings to C code, and they tend to be either Linux-centric (JACK, Alsa) or at best nominally cross-platform but in practice difficult to build and use on Windows. You'll need to build or install the C library first before installing the Haskell binding.
Have you tried OpenAL? It's probably the most well-suited for what you want to do. If you install the C OpenAL libraries, the Haskell binding should be a fairly simple next step. There are a few add-on packages that are meant to simplify some common tasks, like ALUT and Alure.
Otherwise, most other solutions would actually involve several packages that may not work well together. hsndfile and hsndfile-vector are good for reading audio files (you'll need to have libsndfile installed), but they don't play sound. portaudio will play audio (again, you'll need the C portaudio library), but it hasn't been updated in a while (and some updates are badly needed). You'll also need to be moderately familiar with a C compiler chain (e.g. MinGW or Cygwin) to install the necessary C libraries first.
Another way might be to bind to a dedicated audio language such as Supercollider or Csound. This would be a rather heavyweight solution, but the bindings tend to be better-maintained and at least Csound should be easily installable on Windows (disclosure: I wrote the hCsound package). Sox (C library/executable) might also work for you (I've never tried it on Windows, but it claims to work).
All i need is to play audio files, regardless its format.
Your best bet for this will be hsndfile, mentioned in John L.'s excellent answer above. But you may want to make your life easier initially. The WAV file format is a very simple format -- essentially consisting of raw PCM data with minimal headers prepended. Try to get a WAV file to play, and then broaden your horizons from there.
You will be fighting uphill against a lack of sample code -- and you may find yourself needing foreign memory pointers and other not-so-straightforward techniques -- but there's a decent sample for opening and reading a WAV file here.
Also, when developing on Windows, learn to love the -fno-ghci-sandbox flag. It tells ghci that you're connecting to a library that uses its own thread local storage. It's often the only way to get certain external libraries to work in GHCi.
My friend and I are looking to play around with building a browser game (e.g. Farmville) from a linux environment. Flash seems to be the way most browser games are built, but from what I google flash programming can't be easily (at all?) done from linux. Java seems like the leading candidate, but I am rather bamboozled by all the options out there. What platforms should I consider?
As an aside, I have a strong-ish C++ background and some professional experience with Python.
For browser based games, there are 2 main options if I remember correctly:
Flash, as you've already noted is the most common options. Usually this is done using adobe's software (around $200) or just an actionscript compiler (which is more programming like then normal flash). For Linux, your best bet may be: Burrito 4 Linux with the flashpunk libraries for your game engine.
Second most common option is Java, in which case you'd have to use the .applet package for.
Since you have C++ experience, I would recommend trying a flash actionscript compiler. I've personally used FlashBuilder, but I could not run it in Linux, so your next best option is Burrito 4 Linux noted above.
Hope this helps!
Use the FREE adobe flex SDK on linux.
Gives you flash/flex libraries, and command line tools to compile SWFs, flex, and air applications.
I would like to generalize a build system to compile on several (somewhat similar) platforms. What is a good method for determining the type of host that the shell script or Makefile is running on. I would like to distinguish between mac and linux, but also different specific distributions of linux (e.g. RHEL, Ubuntu). Cygwin is not important for me, but if you include it in your response I am sure others will find it valuable.
The rationale may include using the host type to fetch and install the correct versions of binary packages when it is more convenient to do so than compile from source. In addition, some commercial software is binary-packaged for specific distros, so part of the motivation is to grab the right binary.
Thanks,
SetJmp
Autotools to the rescue. It has tons of macros that help you do this kind of stuff.
http://www.lrde.epita.fr/~adl/autotools.html
uname -a to distinguish major *nix variants
Not so sure what the best way to distinguish red hat from ubuntu would be - could look for package managing tools and query installed packages, eventually helping you narrow down different debian derivatives, etc. There's probably something more obvious and up front though.
linux variants generally store distro information in /etc/issue.
most kernels will put info in /proc/version
It's not completely straightforward. You can use uname to find out the general parameters but to differentiate between distributions is a harder task. Maybe you should consider using something like autoconf to generalise your build system?
Just in case you're using Qt, there's this really nice set of defines, Q_OS_*, that guide you to the Operating System you're compiling on:
Q_OS_AIX
Q_OS_BSD4
Q_OS_BSDI
Q_OS_CYGWIN
Q_OS_DARWIN
Q_OS_DGUX
Q_OS_DYNIX
Q_OS_FREEBSD
Q_OS_HPUX
Q_OS_HURD
Q_OS_IRIX
Q_OS_LINUX
Q_OS_LYNX
Q_OS_MAC
Q_OS_MSDOS
Q_OS_NETBSD
Q_OS_OS2
Q_OS_OPENBSD
Q_OS_OS2EMX
Q_OS_OSF
...
They are defined in QtGlobal. There are even defines that help you figure out the compiler used Q_CC_* or the target Windowing System Q_WS_*.
But if you're not using Qt and want to go for a generic method, you most likely have to fall back to the Autotools package or CMake.
Determining Linux distributions is pretty tricky, but not hard. You first have to figure out what distributions you care about and then make all kinds of distribution specific file/configuration checks like in this example for the ones you've chosen, since you can't really support all of the myriad of Linux distros available out the. :-)
As for the Mac side i'll let the Mac experts answer, but it shouldn't be that hard, since at least the diversity issue is out of the question.
I was reading an article about cross-compiling for OSX on linux, but it was quite hard to understand.
What tools do I need? And what configurations are necessary?
Are there any tools for creating packages too?
First you need odcctools, which contains assembler and linker and such (like binutils but capable of handling the Mach-O object format). Then you need the system libraries from the official SDK. You can download it from Apple, but must agree to some stuff and become a member to do so. And finally good old gcc. Quite easy in theory, but in reallity a horrible mess. The easiest way to go (that I know of) is to use I'm Cross!.
Update: I found a newer and better updated method called xchain. It requires more manual work than I'm Cross! thou.