TiMidity: need help compiling this library for the iPhone - iphone

I'm using a powerful library called TiMidity, which I'm sure many iPhone developers have used already used. This is a platform-independent set of programs, but during compile-time in XCode (gcc compiler), there are hundreds of dependency errors that come up.
If anyone here has used TiMidity before for their apps, your advice will be gold.
Thanks everyone,
Phil.

I usually use this script to compile static libraries for the iPhone, but TiMidity++ isn't a library and the API's it uses to output sound on OS X aren't available on the iPhone OS.
Here's what I've gotten so far:
Save build_for_iphoneos somewhere in your path and +x it
cd to the extractd TiMidity++ folder
build_for_iphoneos simulator
This will fail
Copy timidity/newton_tables.c somewhere safe.
make clean
build_for_iphoneos device
Manually edit timidity/makefile and remove all references to DAU_DARWIN and darwin_a
Copy newton_tables.c back into the timidity subfolder and touch it
make
You should now have a timidity binary that can be used from the shell on a jailbroken device (after signed via ldid of course) and object files you can include in your project.
Note: TiMidity++ is GPL, so you will have to release your application under that license if you use any part of it. Also, this is really messy because TiMidity++ wasn't designed to be used this way, all of the darwin integration is broken on iPhone OS, and automake confuses me.

You have to remove AU_DARWIN from ./Makefile as well as timidity/Makefile.

Related

Alternative to GTK WIn7

I have begun to use GTK(2), and I find that the workings of the library to be very good, but the documentation sucks.
I want to upgrade to GTK3, but it seems I need to install something called packman. That is a difficult philosophical step for me. Why can't I simply download a zip file(s) somewhere?
The documentation uses a lot of words without saying much, and the downloads want you to download stuff OTHER then gtk in order to get gtk. Why don't they simply have a GTK package and let me decide if I need all the other stuff.
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
Anyway, that is mostly a rant, what I'd really like is a suggestion to an alternative to GTK+.
Here are some of my requirements...
#1, It must NOT be an interpreter. Using Code::Blocks and C, I get an exe file and I'd like to continue that way.
#2 It must be programmable using C. I'd really like to stick wiith C::B, but I guess in a pinch I can use Eclipse (although that is another nightmare I won't get into here.)
#3 GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
Any suggestions woule be apreaciated.
Thanks, Mark.
You best bet is to give a look at https://en.wikipedia.org/wiki/List_of_widget_toolkits#High-level_widget_toolkits
If you wan to stick to C and not C++, then Qt is out.
The other that stands out is EFL. I've never used it myself, but it has good reputation and probably your best bet if you want to quit GTK+ and stick to C. However I don't know how easy it is to use it on Windows.
Now about GTK+:
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
There are people here that use GTK+ with Code::Blocks, so I don't get what kind of problem you're referring to.
Then your other problems:
The documentation uses a lot of words without saying much
Examples?
the downloads want you to download stuff OTHER then gtk in order to get gtk
What you don't get is that GTK+ is more that just the libgtk library. It has dependencies on a lot of other libraries, like glib, cairo, pango, etc. In the past there used to be a bundle or installer to have that installed on Windows, but people would mess up on setting the environment up based on their needs and give up. As the GTK+ manpower for the Windows platform is limited, the GTK+ team delegated the distribution of the GTK+ binaries to the MSYS2 project.
MSYS2 is a popular project that provides a lot of open source software already built for Windows, and solves the problem of building and installing dependencies by hand for the user. This step is made to make installation simpler, not harder. In a handful of commands you have GTK+ and all its dependencies installed for your platform, and can start coding your app. Another command and you have python and the python GTK+ bindings installed and can get started. Want to depend on another popular library? Chances are MSYS already provides it.
Windows has been known for decades to be bad on dependency management. If package management wasn't a a pain point on Windows, then stuff like chocolatey or conan wouldn't exist.
Your philosophical reluctance is merely that: philosophical. Sure GTK+ on Windows isn't perfect. With MSYS2 you will get packages built with gcc so the debug symbols are not compatible with the Visual Studio debugger and you will need to use gdb instead. But on your other question you say you use gcc and loathe Visual Studio, so this should not be a blocker to you.
GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
This is not possible for the moment as static compilation of GTK+ isn't supported. The redistribution of an app, however, isn't as easy as I'd like it to be. The best way on Windows to redistribute your app while using MSYS2 is to create a pacman package for your app, listing its dependencies, then call pacman to install your app on an empty directory and tell it to install all your dependencies there too. The result will be a directory that you can redistribute, with a self-contained installation of your app and all its dependencies, GTK+ included.

retrieve app's author - jailbreak iOS 6

How can I retrieve an app's author (or developer or publisher, etc) on a jailbroken iOS 6.x device? In iOS 4.x and 5.x, there was an author member in the SBApplication class. But in iOS 6.1 I now get an NSUnknownKeyException when requesting the author. A quick look at SBApplication.h from a iOS 6 class dump online didn't show anything promising (except signerIdentity, but that's something else). Is there any easy way to get this, without digging around in any Info.plist files?
Update: The Info.plist files actually don't contain this information either. The iTunesMetadata.plist file on the other hand does, but System/Cydia apps don't have this file.
I haven't yet jailbroken my iOS 6 device or run class-dump on all the iOS 6 frameworks, so I can't tell you if there's another private API to do exactly what you used to be able to do.
Your suggestion about inspecting the contents of app folders (e.g. /var/mobile/Applications/*/*.app/) and reading the iTunesMetadata.plist files sounds reasonable. Reading each app's Info.plist would also give you the CFBundleIdentifier, which would normally at least contain the publisher's domain name (e.g. com.mycompany.MyAppName).
For apps that don't come from the app store (and don't have iTunesMetadata.plist), you could try another technique (in addition to reading Info.plist):
Cydia packages are maintained with dpkg utilities. You can list all installed packages with the command dpkg -l. You can invoke this command either with
system("dpkg -l >> /tmp/output.log 2>&1");
piping the output into a temporary file, or with NSTask. NSTask is part of OS X APIs, and is not in the iOS public APIs. But, if you add the NSTask.h header to your project yourself, you can certainly use it as a private API in a non-App Store app, to run a command and capture output programmatically.
At the command line, running dpkg -l would give you:
ii libhide 2.1 Library to hide icons. If you are a developer wanting to use this library, code samples included in /usr/lib
ii libxml2-lib 2.6.32-3 represents the library for libxml2
ii lsof 33-4 shows what files programs have open
ii lzma 4.32.7-4 slower, but better, compression algorithm
ii make 3.81-2 dependency-based build environments
ii mobilesubstrate 0.9.3999.1 powerful code insertion platform
ri ncurses 5.7-12 feature-complete terminal library
ii network-cmds 307.0.1-6 arp, ifconfig, netstat, route, traceroute
so, your app could parse that output, to read package names from the second column.
Then, you could use the apt-cache show command to get the information from the package's DEBIAN/control file, which would have something like this:
iPhone-3G:~ root# apt-cache show sqlite3
Package: sqlite3
Version: 3.5.9-12
Architecture: iphoneos-arm
Maintainer: Jay Freeman (saurik) <saurik at saurik dot com>
Installed-Size: 348
Pre-Depends: dpkg (>= 1.14.25-8)
Depends: sqlite3-lib
Replaces: sqlite3 (<= 3.5.9-11)
Filename: debs/sqlite3_3.5.9-12_iphoneos-arm.deb
Size: 71928
MD5sum: 6d47c112692ac00af61bd84e3847aa42
Section: Data_Storage
Priority: standard
Description: embedded database used by iPhoneOS
Name: SQLite 3.x
Tag: purpose::library, role::developer
I know this is more work than just using author from SBApplication, but maybe it's good enough? Hopefully, some one else will chime in with another answer ...

Can't make deb files work using Theos. Manually copying the dylib - works

I'm having a really weird problem. I've developed my first tweak for the iPhone (intended for Cydia distribution). I'm all done developing the tweak and everything works, but I'm having trouble packing it into a deb file. Typing make and manually copying the dylib into Library/MobileSubstrate/DynamicLibraries and the preference file into Library/PreferenceLoader/Preferences - everything works just fine, but when I type make package, my tweak doesn't work at all. The files are copied to their right folders, I can see the settings in the Settings.app, but the dylib won't run, I can't even see my NSLog in the console. I tried using dpkg -b, and even http://www.myrepospace.com/iDeb/ but to no avail.
What can I do?
Thanks!
I'm the author of Theos, and you posted this question in the IRC channel and then summarily left.
I would like to help you, but I need to look at the package that Theos creates.
Barring the usual issues, since it IS a tweak, please make sure to respring after you install the package, as dpkg will not do that for you.
You can find me in #theos (irc.saurik.com) as DHowett.

ARM disassembler/cross-compiler for examining iOS compilation

Can anyone recommend either:
an ARM disassembler that runs in either Windows or MacOS and which can ideally understand the executable format used by iOS
within MacOS, a way to call the cross-compiling GCC installed by XCode directly from the command line (so that I can run it on a small test file and ask for assembly output).
Basically, I'm interested in seeing how certain things get compiled for ARM/iOS by XCode/gcc to help me with optimisation. As you can see, although I have both a Windows and Linux background, I'm not fundamentally a Mac specialist so I'm not too familiar with e.g. where XCode intsalls all its gubbinry or the ins and outs of whatever binary format iOS uses.
I don't particularly care whether I have to do the "disassembly" under Mac OS or Windows, but what I was trying to avoid is installing a brand new copy of GCC configured to cross-compile to ARM, as XCode presumably has a perfectly good installation already sitting there somewhere... Any help appreciated.
You can always use otool disassembler. It's rather basic but does the job.
IDA Pro can disassemble ARM Mach-O files used in iOS. Using it is (in my biased opinion) much better experience that looking at the dead listing. You can check how it works with the demo version.
Disclaimer: I work for Hex-Rays.
an ARM disassembler that runs in either Windows or MacOS and which can ideally understand the executable format used by iOS
I can suggest you a LLVM. If it is built with default options, llvm-objdump will disassemble ARM.
Also, looks like http://developer.apple.com/technologies/tools/whats-new.html Apple is using LLVM toolchain in iOS SDK.
There is already an ARM cross compile toolchain built into Xcode. You can debug your iOS applications at the source and ASM level with the gdb debugger support already built into Xcode. For example, open your iOS app and select Device and Debug. Then set a breakpoint at a source line and run your program until the breakpoint is hit. Now select "Run -> Debugger" from the menu. When the debugger is showing, select "Run -> Debugger Display -> Source and Disassembly" and you will see a window on the right side that shows the ARM asm code that was generated from your source code. You can step through the code a source line at a time using the buttons. If you want to step one ARM asm instruction at a time, open up the gdb console and use the "stepi" instruction (type it once, then just hit enter to repeat).
Take a look at Hopper. It's darn cheap compared to IDA (though not as powerful) and the recent versions can handle ARM.
Within MacOS, a way to call the cross-compiling GCC installed by XCode directly from the command line (so that I can run it on a small test file and ask for assembly output).
Use this script for a gcc that compiles for iphone:
#!/bin/bash
# Note: The "/Applications/Xcode.app/Contents" prefix is only required on 10.7.2 and
# later (where Xcode is installed through app store rather than as a package).
# If running 10.6 or earlier, cut out that prefix.
PLATFORM=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
# Change this to the iOS version you want to compile for (you must have the platform
# SDK installed in Xcode)
VER=6.1
$PLATFORM/Developer/usr/bin/gcc -arch armv7 -framework IOKit -framework CoreFoundation -F $PLATFORM/Developer/SDKs/ iPhoneOS$VER.sdk/System/Library/Frameworks -I $PLATFORM/DeviceSupport/Latest/Symbols/usr/include -L $PLATFORM/Developer/SDKs/iPhoneOS$VER.sdk/usr/lib -L $PLATFORM/Developer/SDKs/iPhoneOS$VER.sdk/usr/lib/system $*
Source: newosxbook.com
Take a look at Radare2 it is an open Source tool that is rising it's Feature-Set constantly and already supports ARM disassembling.

Cross-compiling Makefile: dealing with test programs

I'm trying to cross-compile several libraries from OSX to iOS. I've successfully cross-compiled libjpeg and libogg.
But I can't compile libvorbis because configure insists on creating and running a small test program. This obviously fails, because it creates an armv7 binary, fails to run it, and then interprets this as missing ogg libraries.
How do you usually deal with this kind of problem? I'm tempted to hack the configure script to work around these issues, but because of this kind of failure some features may be disabled. I'm also thinking of letting configure generate a native Makefile and then convert it to use the iOS toolchain, but this seems too error prone.
Any advice?
If you are cross-compiling anything that has more dependencies than libc (glibc) it becomes much more complicated. You need to have already cross-compiled all the dependencies. And the cross-compiler toolchain and all helper build programs and scripts need to know how to find those dependencies (the cross-compiled libraries and headers).
You need to have already cross-compiled libogg (and its dependencies) and installed them into the cross-compile root directory. The headers and libraries from your build system can't be used for the host (arm7) system. They must be kept separate.
Also, if you want to have shared object libraries (*.so) and not just static libraries then there is a whole new set of complications. For example, while a cross-compiler toolchain contains a cross-compiled libc as part of the toolchain, you still need a libc for the host system. The libc that is part of the toolchain can be used for this, but the way it is structured is different than on the host system. Sometimes people copy and re-arrange the files, but often people just compile and install a new glibc for the root.
Anyways, all that to say, the two errors you are seeing are because the configure script is not able to find a cross-compiled libogg library. If you haven't already, you need to cross-compile libogg (and dependencies) and install them into your target root. Then you need to tell the configure script where your cross-compiled headers (yes, header are architecture specific) and libraries are in your target root. Usually using CFLAGS, LDFLAGS, CXXFLAGS, etc (NOT --prefix) but there may be other environment variables you need to set also to affect things like pkg-config, etc. After you have built each dependency, then you need to get the makefile to install the dependency to the root. Usually this is done with make DESTDIR=[root] install but some makefiles have their own mechanism (or no proper alternate install mechanism).
You may also need to override certain configure checks (using environment variables) that are poorly written and don't have good cross-compile defaults. These variables usually start with ac_cv_*
So the basic process is to do this for packages that you need (in dependency order):
export CFLAGS=-I[root]/usr/include LDFLAGS=-L[root]/usr/lib CXXFLAGS=-I[root]/usr/include
export ac_cv_[test1]=[yes|no] ac_cv_[test2]=[yes|no] ...
./configure --host=[arm7-blah-blah]
make
make DESTDIR=[root] install
Good luck. Once you feel comfortable with standard cross-compiling, then you will be ready to take on the real black art, the Canadian cross ;-)
I finally figured it out. I tricked configure by explicitly making it link with ogg (LDFLAGS="/usr/local/ios/lib/libogg-armv7.a" ./configure ...) and then removed the explicit reference to the library from the generated makefile.