4. libpng mit Visual C++ 2010 bauen geht nicht

libpng mit Visual C++ 2010 bauen geht nicht

  • P

    Guten morgen,

    ich bin gerade dabei, mir cairo zu bauen.
    Dafür gehe ich nach dieser Anleitung vor: http://www.williamcyap.com/?p=44
    Ich verwende MS Visual C++ Express 2010.

    In der Anleitung komme ich beim Schritt "Compiling libpng" nicht weiter.
    Wenn ich die Projekteinstellungen wie in der Anleitung gemacht habe (mit dem Unterschied, dass ich schon zlib 1.2.5 statt 1.2.3 habe, der Artikel ist von 2008), dann bricht das Bauen von libpng mit folgender Meldung ab:

    1>  Code wird generiert...
1>..\..\scripts\pngw32.rc(104): error RC2104: undefined keyword or key name: Use

    Die Zeilen um 103-105 in der rc-Datei sehen so aus:

    #ifdef PNG_LIBPNG_SPECIALBUILD
      VALUE "SpecialBuild", PNG_LIBPNG_SPECIALBUILD "\000"
#endif /* PNG_LIBPNG_SPECIALBUILD */

    Ich sehe da kein "Use" ??

    Was mach ich falsch?

    Gruß,
    Philipp

    0
  • P

    Jetzt habe ich mir mal die Anleitung hier vorgenommen: http://stackoverflow.com/questions/85622/how-to-compile-cairo-for-visual-c-2008-express-edition

    und hier scheitert es schon einen Schritt vorher an der zlib:

    infback.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_inflate_fast" in Funktion "_inflateBack".
inflate.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_inflate_fast".
zlib1.dll : fatal error LNK1120: 1 nicht aufgelöste externe Verweise.
NMAKE : fatal error U1077: ""C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\link.EXE"": Rückgabe-Code "0x460"
Stop.

    EDIT: Mit zlib 1.2.3 gehts. Super, ich bin unter Windos also gezwungen, veraltete Software mit bekannten Bugs zu nutzen. Großes Tennis.

    EDIT2: Und der nächste Schritt der Anleitung ist auch nicht mehr möglich, da es diese lpng1231.nmake Datei im aktuellen Download nicht mehr gibt. Ganz tolle Wurst!

    Boah, ihr glaubt gar nicht, wie mich diese VERKACKTE WINDOWS-GRÜTZE schon wieder ankotzt!!!!!
    Unter Linux kostet mich das ein ./configure && make RETURN , dann geh ich mir einen Tee holen und wenn ich wieder komme läuft die Kiste.

    Unter Windows muss man seitenlange Anleitungen abarbeiten, die DANN NOCH NICHT MAL FUNKTIONIEREN, wenn man sie befolgt.

    Jedesmal wenn ich unter Windows was machen muss, frag ich mich ernsthaft wie Leute mit sowas arbeiten können.

    Okay, </rantmode off>.
    Sachdienliche Hinweise, anyone?

    Philipp

    0
  • P

    So, hier habe ich eine funktionierende Konfiguration gefunden:

    http://bobobobo.wordpress.com/2009/03/02/building-libpng-in-visual-studio-2008/

    Halten wir fest: Um die Library für eines der populärsten Grafikformate auf einem der populärstem Betriebssysteme unserer Zeit zu bauen, bin ich gezwungen, mir ein Projekt-File von einer obskuren Sharehoster-Seite zu ziehen.
    Von diesem File weiß ich nicht
    -aus welcher Version der libpng es gebaut und
    -was für Würgarounds eingebaut werden mussten, damit es auf diesem System kompiliert.

    Achja, und das ganze ist dann noch gegen eine Kompressionslibrary gelinkt, die bekannte security vulnerabilities hat. Na dann gute Nacht!
    Langsam wundert mich echt garnix mehr.

    0
  • I

    Das liegt nicht an Windows, sondern an der Lib. Wenn die nicht in der Lage sind, für Visual Studio eine vernünftige Projektdatei oder ein Buildscript zu liefern, kannst du nicht Windows dafür schlecht machen. Das wäre in etwa so, als würden sie unter Linux das Makefile "vergessen".
    Bei GMP zum Beispiel ist Visual Studio offiziell nicht unterstützt, das Builden ist demnach ein Graus. Kann da Microsoft was dafür?

    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).

    0
  • P

    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 😞

    0

  • 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.

    0
  • P

    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.

    0

  • 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

    0
  • P

    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.

    0

  • 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.

    0
  • P

    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.

    0

  • 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.

    0
  • I

    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.

    0

  • 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.

    0
  • P

    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.

    0

  • Wie Volker Pispers es mal so schön gesagt hat: Es geht doch nichts über ein einfaches Weltbild 🙂

    0
  • P

    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.

    0
  • C

    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.

    0
Anmelden zum Antworten