libpng mit Visual C++ 2010 bauen geht nicht
-
ipsec schrieb:
Wie man es besser machen kann, zeigt Boost. Dort ist es auch unter Windows nur ein
bootstrap RETURN bjam RETURN, man drinkt etwas länger Tee und das Ding läuft (oder man lädt sich gleich die vorkompilierten Libs).Hör mir blos mit den Saboteuren auf. Warum, zum Henker, brauchen wir NOCH EIN buildtool? Was bitte geht mit autotools und make nicht, weshalb man bjam erfinden musste? Warum bitte muss man ein völlig neues buildsystem schreiben, statt autotools zu erweitern, dass es das tut, was man möchte? Wie mir diese "mir hat die Hintergrundfarbe nicht gefallen, also habe ich mir einen eigenen Windowmanager geschrieben"-Haltung auf den Keks geht!
Beispiel: Ich habe parallel gcc44 und gcc45 installiert. In dem ich meine Umgebungsvariablen für CC und CXX entsprechend setzte, kompiliert JEDE VERDAMMTE SOFTWARE die make benutzt mit dem Compiler, den ich möchte. Bis auf diese Saboteure von boost, die wieder ihr eigenes Süppchen gekocht haben.Wo wir gerade bei buildtool-bashing sind: Um den Java-Kompiler aufzurufen, schreiben die Leute Makefiles in XML !!!einseins1!! Und weil ant immer noch nicht unbenutzbar genug war, wurde dann Maven erfunden.
Man, die Woche hat noch nichtmal angefangen und ich bin schon bedient
-
Ich sag dazu nur dass libpng 1.5.0 bei mir mit zlib 1.2.5 problemlos buildet, habs gerade eben ausprobiert. Mit dem beiliegenden Visual Studio 2010 Projekt. Die Schuld dafür dass du unfähig bist ein Buildsystem zu bedienen kannst du nicht Windows in die Schuhe schieben.
-
dot schrieb:
Ich sag dazu nur dass libpng 1.5.0 bei mir mit zlib 1.2.5 problemlos buildet. Mit dem beiliegenden Visual Studio 2010 Projekt.
Auf der libpng Seite ist ein großer roter WARNUNG-Kasten, dass man 1.5.0 nicht benutzen soll. Daher habe ich mir die auch nicht heruntergeladen.
-
Wenn du runterscrollst wirst du feststellen dass die ganze Website voll ist mit solchen Warnungen für alle möglichen Versionen. Welche Version hast du denn verwendet?
EDIT: die libpng 1.2.44 buildet genauso ohne Probleme mit zlib 1.2.5 in VS 2010
-
Jawohl, mit der Anleitung:
http://cairographics.org/end_to_end_build_for_win32/
und libpng 1.2.44 klappts jetzt endlich. Obwohl es "vcbuild" auf Commandline-Ebene wohl nicht mehr gibt. Aber Projektkonvertierung kann man ja auch in der VS IDE machen. Also ist auch die Anleitung schon wieder ziemlich outdated.
Mannometer, was eine schwere Geburt.
-
Das einzige Problem ist dass die Buildkonfiguration der veralteten Projektdateien (die sind von 2004...) die bei der libpng 1.2.44 dabei sind nicht mit der Konfiguration der zlib 1.2.5 zusammenpasst, das eine ist so konfiguriert dass es versucht eine dll mit __cdecl Funktionen zu linken und das andre produziert eine dll mit __stdcall Funktionen. Da muss man eben die entsprechenden Präprozessorflags richtig setzen, aber das muss man sowieso je nachdem was man haben will. Daran ist definitiv auch kein Windows schuld
vcbuild gibt es nichtmehr weil mit VS 2010 nun auch Visual C++ auf MSBuild umgestellt wurde.
-
dot schrieb:
Daran ist aber auch kein Windows schuld
Doch. Wenn nämlich dieses bekloppte nmake-Tool von VS mit normalen Makefiles umgehen könnte, wären diese ganzen Klimmzüge am Brotkasten nicht nötig.
Oder wenn VC2010 einfach Makefile-Projekte im- und exportieren könnte - ganz früher ging das mal.
-
Es gibt sicherlich 100 make Implementierungen für Windows. Und wenn dieses bekloppte make einfach MSBuild Projekte ausführen könnte hättest du das Problem übrigens auch nicht.
-
PhilippM schrieb:
dot schrieb:
Daran ist aber auch kein Windows schuld
Doch. Wenn nämlich dieses bekloppte nmake-Tool von VS mit normalen Makefiles umgehen könnte, wären diese ganzen Klimmzüge am Brotkasten nicht nötig.
Oder wenn VC2010 einfach Makefile-Projekte im- und exportieren könnte - ganz früher ging das mal.Wenn sich die Bibliotheksentwickler plötzlich entschließen würden, keine Makefiles, sondern VS-Projekte auszuliefern, wäre es dann Linux' Schuld, dass man da nix mehr kompilieren kann, weil das bekloppte make-Tool nicht mit normalen VS-Projekten umgehen kann?
Deine Aussagen sind Schwachsinn, Makefiles sind nicht das Maß aller Dinge.
-
ipsec schrieb:
[...] Makefiles sind nicht das Maß aller Dinge.
Zum Glück absolut nicht. Ich frag mich wieso manche auf die Idee kommen dass das so sein müsste.
-
Richtig.
Aber Makefiles funktionieren nunmal. Und das schon länger, als ich auf dieser Welt bin. Versuch mal ein auch nur halb so altes Visual C++ Projekt aufzumachen oder heute zu kompilieren.
Einfache, zuverlässige Technik, die funktioniert.
configure, make, Enter.Davon ist alles, was ich bisher unter Windows gesehen habe, weit entfernt. Es sei denn, man lässt sich zu 100% auf die proprietäre Technik ein. Man benutzt die IDE von VS, CodeVault (oder wie auch immer das Versionierungssystem heißt) statt git, und am besten nur Bibliotheksfunktionen von .NET. Dann funktioniert sicher Windows genauso komfortabel.
Aber was solls, ich habe mich genug ausgekotzt und noch einen Linux-Windows-Flamewar-Thread braucht die Welt nicht.
Die Lib ist kompiliert, thread kann geschlossen werden.
-
Wie Volker Pispers es mal so schön gesagt hat: Es geht doch nichts über ein einfaches Weltbild
-
dot schrieb:
Wie Volker Pispers es mal so schön gesagt hat: Es geht doch nichts über ein einfaches Weltbild
Du zitierst es falsch: "Der Deutsche hat es gern geschlossen: Hose, Weltbild, ... Alles muss geschlossen sein"
Abgesehen davon hast du völlig recht: wir Linux-Fanboys sind genauso schlimm wie Apple-Fanboys.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Compiler- und IDE-Forum verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
