Du musst die Lib hinzufügen. Einfach reinziehen (1 x Header, 1 x Kompilat).

Aber was meinst du mit Architekturen wechseln!? Nichts von Cocoa ist nicht mitgegangen. Das Problem dürfte eher auftauchen, wenn du Third-Party-Libs verwendest.

Ist dir die unterschiedliche Bedeutung von <> und "" klar? Möglicherwiese hast du einfach die Header im falschen Pfad.

Du versuchst jetzt aber nicht, die kompletten Sources von mySQL in Dein Xcode Projekt einzubinden und mySQL immer selbst mitzukompilieren? Nicht? Dann ist ja gut.

Eigentlich sollst Du eine Client-Library daraus bauen, libmysqlclient. Die bindest Du dann in Deine Projekte ein. Dann musst Du das auch nicht immer neu compilieren. Ausserdem ist die lib garantiert nicht darauf ausgelegt, "einfach so" kompiliert zu werden, da gibs sicher komplizierte Makefiles etc. so dass es schwierig wird, einfach die C-Dateien bei dir "reinzuziehen". Warum auch, dafür gibt es doch Libraries.

Davon abgesehen bekommst Du so auch sicher Probleme mit der Lizenz, oder Du musst Deine Anwendung dann unter GPL veröffentlichen. Weiss ich aber nicht ganz genau. Muss ich auch nicht wissen, weil man sowas nicht machen sollte

So ist das doch der einfachste Weg?!
Die Lib kompilierst Du Dir für was auch immer. Ich hab nicht so die Ahnung von iPhone/ARM, aber die Chancen stehen nicht schlecht, dass das sogar schon jemand gemacht hat. Fürs iPhone brauchst Du aber, soweit ich weiss, statische Libs. Steht in der Doku von mySQL nichts?

EDIT:
Du solltest mal wirklich Google benutzen. Da gibt es haufenweise fertige Lösungen für alles, was Du Dir vorstellen kannst. Du musst nur so abwägige Terme wie "MySQL Cocoa" oder "MySQL iPhone" eingeben. Kennst Du dies Google?

Was ich noch überall gelesen habe: Warum willst Du von Deinem iPhone aus direkt auf eine MySQL Datenbank zugreifen? Wäre eine einheitliche Web-Schnittstelle nicht der bessere und einfachere Weg?
Ganz zu schweigen davon, dass man eigentlich kein MySQL Server offen im Netz stehen haben will, damit jeder darauf zugreifen kann.

Was willst Du überhaupt genau machen, vielleicht ist da auch schon das Problem Ich kann mir auch nicht recht vorstellen, warum man MySQL in einer C-Anwendung, und dann noch auf einem mobilen Gerät benötigt. Ausser vielleicht irgendwelche Anwendungen für Grossunternehmen etc.

Ich habe keine der Möglichkeiten ausprobiert. Wenn Du das aber schon gemacht hast, wäre es gut, wenn Du aufführst, was Du probiert hast und woran es gescheitert ist, dann kann man Dir sicherlich einfacher helfen.
Entsprechend wäre eine "bessere" Frage in etwa: "Ich habe keine vorkompilierte MySQL Client Lib für das iPhone gefunden, brauche aber unbedingt MySQL Zugriff auf einen Server von mir. Ich habe versucht, die Lib selber zu kompilieren, das scheitert aber an XXX. Kann mir hier jemand etwas empfehlen? Ich bin auf direkten MySQL Zugriff angewiesen wegen YYY."

Was heißt denn 'offen'?
MySQL hat ausgesprochen fein granulierte Sicherheitskonzepte auf Userebene.
Ich sehe da kein Problem, jeweils die benötigten User mit den dazugehörigen Rechten hin und her zu melden.
Im Allgemeinen macht man ja eh nicht alles in einer einzelnen Abfrage, also kann man auch die Sitzungen teilen.

In einem Punkt hast du natürlich recht: man sollte schon wissen, was man tut.

Lucas de Vil schrieb:

zerm schrieb:

Ganz zu schweigen davon, dass man eigentlich kein MySQL Server offen im Netz stehen haben will, damit jeder darauf zugreifen kann.

Was heißt denn 'offen'?
MySQL hat ausgesprochen fein granulierte Sicherheitskonzepte auf Userebene.
Ich sehe da kein Problem, jeweils die benötigten User mit den dazugehörigen Rechten hin und her zu melden.
Im Allgemeinen macht man ja eh nicht alles in einer einzelnen Abfrage, also kann man auch die Sitzungen teilen.

In einem Punkt hast du natürlich recht: man sollte schon wissen, was man tut.

Das ist eine Prinzipfrage. Als Server-Admin gibt man nichts heraus, was man nicht unbedingt muss, und das ganze hat rein gar nichts mit den Sicherheitskonzepten auf Userebene zu tun. Es braucht nur ein Sicherheitsloch in mysqld entdeckt werden, und jeder kann es sofort remote(!) ausnutzen, das ist nicht gut. Man möchte so wenig Angriffsfläche wie nur irgend möglich bieten, dadurch muss man auch nur auf wenige Komponenten achten - etwa nur darauf, dass der Apache aktuell ist, den MySQL kann man dann regulär updaten und muss nicht mitten in der Nacht ein Update reinspielen, weil ja jeder es remote ausnutzen könnte.
Dazu kommt, dass man weitere Sicherheitskonzepte nur an einer Stelle umsetzen muss - bspw. kann so nur Apache geflooded werden und man weiss wie man damit umgeht. MySQL dagegen auch noch abzudichten ist eher sinnlos. Man macht es halt einfach in der Praxis nicht, weil so ziemlich rein gar nichts dafür spricht.


SSL Zertifikate gibt es inzwischen kostenlos. Davon abgesehen bietet ein Self-Signed Zertifikat genau die gleiche Sicherheit - nur die Authentizität wird nicht geprüft, aber das wird sie ja in deiner Custom-Lösung natürlich auch nicht.
Warum Du es in Deiner Custom-Lösung "nicht entschlüsselt" bekommst, kann ich Dir leider so nicht sagen, da gibt es aber viel, auf das man achten muss.


Warum wird das ganze durch direkten SQL-Zugriff komfortabler? Wenn Du etwas am Datenbank-Layout änderst, musst Du an allen Clients extra auch Anpassungen vornehmen. Eine schöne API, welche das rohe SQL weg-abstrahiert ist hier (in meinen Augen) ganz klar Vorteilhaft.
So oder so kannst Du aber ein PHP Skript schreiben, was SQL-Anfragen ausführt. Dann brauchst Du nirgendwo sonst ein SQL-Client. Schön finde ich das aber immer noch nicht, aber darum geht es ja wahrscheinlich auch nicht.

Nachtrag:
Informiere Dich vorher noch einmal, wie man das mit der Verschlüsselung überhaupt macht. Kein Mensch verschlüsselt tatsächliche Inhalte mit RSA und das hat vielerlei Gründe.