Hi, ich hab seit kurzem Linux zum spielen auf meinem Laptop in der Mint Distribution. Ich versuche seit ein paar Tagen unterschiedliche Softwarepakete zu compilieren, jedoch renne ich immer wieder in Fehler. Nachdem ich brav ./configure aufgerufen habe mache "make" wie im Readme besschrieben und er fängt auch an, kommt dann aber auf einmal mit Linkerfehlern oder fehlenden include direktiven zu standard include files. Da ich annehme, dass diese Pakete ja häufig heruntergeladen und gebaut werden, versteh ich nicht was da falsch läuft. Einige lassen sich problemlos bauen, andere leider nicht. Ich hab zuletzt versucht http://gmrender.nongnu.org/ zu bauen und bekomme dort make[2]: Entering directory `/home/thomas/daten/MediaRenderer/gmediarender-0.0.6/src' gcc -Wall -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -L/usr/lib -o gmediarender main.o upnp.o upnp_control.o upnp_connmgr.o upnp_transport.o upnp_device.o upnp_renderer.o webserver.o output_gstreamer.o xmlescape.o -pthread -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lxml2 -lglib-2.0 -lupnp /usr/bin/ld: upnp.o: undefined reference to symbol 'ixmlDocument_createElementNS' /usr/bin/ld: note: 'ixmlDocument_createElementNS' is defined in DSO /usr/lib/i386-linux-gnu/libixml.so.2 so try adding it to the linker command line /usr/lib/i386-linux-gnu/libixml.so.2: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [gmediarender] Error 1 m Hat jemand von euch eine Idee? Meine erste Begeisterung für das aktuelle Linux verwandelt sich mehr und mehr in Frust.
Das ist ein Fehler von gmrender, nicht direkt von Linux. gmrender wird seit 2007 nicht mehr im Orginal weiterentwickelt, hat also eventuell Abhängigkeiten zu alten Libraries die dann zu solchen Fehlern führen. Schau mal hier, das ist eine Weiterentwicklung die besser funktionieren sollte: https://github.com/hzeller/gmrender-resurrect
ich schrieb: > Das ist ein Fehler von gmrender, nicht direkt von Linux. Nö. Das ist ein Linker Fehler
1 | /usr/bin/ld: upnp.o: undefined reference to symbol |
2 | 'ixmlDocument_createElementNS' |
3 | /usr/bin/ld: note: 'ixmlDocument_createElementNS' is defined in DSO |
4 | /usr/lib/i386-linux-gnu/libixml.so.2 so try adding it to the linker |
5 | command line |
6 | /usr/lib/i386-linux-gnu/libixml.so.2: could not read symbols: Invalid |
7 | operation
|
Ich habe das Paket gerade mal durch den Compiler gejagt und der läuft bis auf ein paar Warnungen durch. Schau mal hier http://ubuntuforums.org/showthread.php?t=1874930
Hans Ulli Kroll schrieb: > ich schrieb: >> Das ist ein Fehler von gmrender, nicht direkt von Linux. > > Nö. > Das ist ein Linker Fehler Klar, aber an einem Linkerfehler ist nicht Linux schuld, sondern das Programm das nicht aller erforderlichen libs linkt.
Mit gmrender-resurrect hat es auf anhieb geklappt, allderings steht in
dem wirklich brauchbaren ReadMe auch der Hinweis man solle:
sudo apt-get install autoconf automake libtool
ausführen. Es scheint, dass eines davon noch nicht auf meiner
Distribution drauf war.
Mal sehen ob es jetzt besser geht. Die riesigen config und make files
machen mir derzeit noch ziemliche Angst.
ich schrieb: > Hans Ulli Kroll schrieb: >> ich schrieb: >>> Das ist ein Fehler von gmrender, nicht direkt von Linux. >> >> Nö. >> Das ist ein Linker Fehler > > Klar, aber an einem Linkerfehler ist nicht Linux schuld, sondern das > Programm das nicht aller erforderlichen libs linkt. Nö, das nicht direkt, aber bisher hatte ich unter Windows noch nie so große Probleme irgendwelche Projekte mit VS zu übersetzen.
Ist damit gemeinr, dass es unter Linux besser läuft?
> Nö, das nicht direkt, aber bisher hatte ich unter Windows noch nie so > große Probleme irgendwelche Projekte mit VS zu übersetzen. Das gehoert leider zu den Nachteilen von Linux. Ursache dafuer ist das an einem Projekt immer sehr viele Leute unbhaengig voneinander arbeiten und es ausserdem auch sehr viele unterschiedliche Distributionen in unterschiedlichen Softwarestaenden gibt. Du kannst ja mal versuchen einen moeglichst aktuellen Mplayer zu uebersetzen. :-) Olaf
Olaf schrieb: > Du kannst ja mal versuchen einen moeglichst aktuellen Mplayer zu > uebersetzen. :-) Also unter Elementary Luna war das jetzt nicht schwierig ;-)
1 | $ ./configure |
2 | ... |
3 | Checking for yasm ... |
4 | Error: yasm not found, use --yasm='' if you really want to compile without |
5 | $ apt-cache search yasm |
6 | yasm - modular assembler with multiple syntaxes support |
7 | $ sudo apt-get install yasm |
8 | ... |
9 | $ ./configure |
10 | ... (kein Error mehr) |
11 | $ make -j3 |
12 | ... |
13 | $ sudo make install |
14 | ... |
15 | $ mplayer |
16 | Creating config file: /home/simon/.mplayer/config |
17 | MPlayer SVN-r36533-4.6 (C) 2000-2013 MPlayer Team |
18 | ... |
Insgesammt habe ich recht positive Erfahrungen mit dem Übersetzten von Software gemacht, auch wenns noch nicht so viel war. Was mich allerdings zur Zeit fordert: Einen Treibersourcecode (kein fertiges Projekt, nur schnell zusaammegekloppter Code) für MIPS cross-compilieren...
:
Bearbeitet durch User
Ist eben ein großes Problem mit Open Source. Bei MS hat man keinen Ärger mit dem Linker. Das darf man am Stück kaufen ;-)
Ich empfinde es einfach etwas lästig immer erst bei Google zu suchen um rauszufinden, welche lib mir jetzt noch fehlt, wo ich di herbekomme und wie genau dann die Lib heißt, die ich linken muss. Erschwerend kommen unterschiedliche Versionsnummern zwischen GIT-Repositories und den fertigen Versionen hinzu, die man über den "App-Shop" runterladen kann. bei den GUPNP Libs war die neueste Version im GIT 0.8, im Appshop war eine definitiv ältere Version mit Version 1.0 gelabelt. Auch empfinde ich make files nicht undbedint hilfreich um ein Projekt zu verstehen. Eine VS Solution kann man einfach in die IDE laden und gut ist. Ich habe einige zeit gebraucht um ein Projekt in Ecliepse zum laufen zu bringen.
Thomas Burkhart schrieb: > Ich empfinde es einfach etwas lästig immer erst bei Google zu suchen um > rauszufinden, welche lib mir jetzt noch fehlt, wo ich di herbekomme und > wie genau dann die Lib heißt, die ich linken muss. Das waere bei Windows genauso, wenn es denn ein Opensource OS waere und eine Entwicklungsumbgebung mit Compilern mitbringen wuerde. Im Vergleich zu Unix/Linux hat Windows nach einem frischen Install gar nichts on-board um irgendetwas selber zu bauen. In einem Punkt dir recht geben: Die Library-Versionen aendern sich bei Linux schneller als bei den traditionellen Unix-System und sind oft nicht abwaertskompatibel. Unter Solaris war es meistens kein Problem ein Paket fuer Solaris 8 unter Solaris 10 zum Laufen zu bringen, da die steinalten Libraries meistens in die naechste Version mitkommen. FreeBSD ist da aehnlich und erspart einen Sysmlink auf neuere kompatbible Library-Files zu setzen: /etc/libmap.conf Also da ist auf der Linux-Seite sicher noch Verbesserungsbedarf.
DLL's suchen macht viel mehr Spaß! Und schon bei gekaufter Software. Man muß die gar nicht geschenkt bekommen und darf sich doch auf'm suchen freuen.
Ein Vorteil ist, dass man für fast jede Linkerfehlermeldung bei Google einen Post findet von jemandem anderen, der das gleiche Problem hatte mit der dazugehörigen Lösung. Was mich erstaunt, ist, dass Linux im Vergleich zu meinem Windows 7 nicht so flüssig läuft. Ich hätte erwartet, dass es eher noch spritziger in den Reaktionen auf Benutzerninput ist. Z.B. wie lange es braucht bis manche Dialoge aufgehen, bzw. Applikationen starten. Dabei ist vor allem störend, dass man nicht wie bei Windows durch einen Animierten Mauszeiger sieht, dass sich etwas tut. Mein bisheriger Eindruck ist ziemlich gemischt. Allerdings macht es schon Spaß damit zu spielen. Gruß Tom
>Was mich erstaunt, ist, dass Linux im Vergleich zu meinem Windows 7 >nicht so flüssig läuft. Ich hätte erwartet, dass es eher noch spritziger >in den Reaktionen auf Benutzerninput ist. Z.B. wie lange es braucht bis >manche Dialoge aufgehen, bzw. Applikationen starten. Dabei ist vor allem >störend, dass man nicht wie bei Windows durch einen Animierten >Mauszeiger sieht, dass sich etwas tut. Vielleicht ist Deine Kiste etwas unterdimensioniert bezüglich Speicher.
Sind auf meinem Laptop halt nur 3GB sollte doch wohl reichen, oder?
Thomas Burkhart schrieb: > Was mich erstaunt, ist, dass Linux im Vergleich zu meinem Windows 7 > nicht so flüssig läuft. Ich hätte erwartet, dass es eher noch spritziger > in den Reaktionen auf Benutzerninput ist. Z.B. wie lange es braucht bis > manche Dialoge aufgehen, bzw. Applikationen starten. Dabei ist vor allem > störend, dass man nicht wie bei Windows durch einen Animierten > Mauszeiger sieht, dass sich etwas tut. Man muss bei "Linux" zwischen dem eigentlichen Betriebssystem und einer (optionalen!) grafischen Oberfläche und da dann nochmal unterschiedlichen Oberflächen unterscheiden. Es gibt mindestens ein Dutzend verschiedener Oberflächen. Such Dir einfach diejenige aus, die Deinen Bedürfnissen am ehesten entspricht. Bei sehr vielen hast Du auch Deine gewünschte Aktivitätsanzeige bzw. kannst sie einfach einschalten :-) > Mein bisheriger Eindruck ist ziemlich gemischt. Allerdings macht es > schon Spaß damit zu spielen. Ja, man muss sich langsam rantasten - das ging mir damals auch so. Mittlerweile läuft mein Unternehmen bis auf WinXP-VMs für Tests ausschließlich auf Linux - von den CNC-Maschinen über die Laptops und ARM-Aufbauten bis hin zum zentralen Server. Pakete übersetzen wir eigentlich nur sehr selten. Wenn da Bibliotheken fehlen, liefert der Linker aber immer recht genaue Angaben und das Problem ist schnell gelöst. Allerdings arbeite ich jetzt auch schon fast 20 Jahre unter Linux :-)
Thomas Burkhart schrieb: > Was mich erstaunt, ist, dass Linux im Vergleich zu meinem Windows 7 > nicht so flüssig läuft. Es gibt garkeinen Grund, warum Linux schneller sein sollte. Die Leute die das behaupten reden von einem Linux ohne Grafik, aber das kann man nur mit DOS vergleichen (und ein MSDOS ist auf einem heutigen Rechner auch rasend schnell). Setzt man bei Linux bequeme und intuitive Bedienung durch eine GUI voraus wie bei Windows, so ist Linux eher langsamer, weil die Grafik viel umständlicher ins Betriebssystem eingebunden ist. Das Selbstübersetzen von Source-Code ist toll für Softwareentwickler, aber für reine Anwender (wie etwa eine Sekretärin oder einen Journalisten) völlig ungeeignet, da man meistens als Entwickler und Debugger tätig werden muss, um die fast unweigerlich auftretenden Fehler zu eliminieren. Linux-Freaks werden niemals begreifen, dass es der Beruf einer Sekretärin ist, mit einem Textsystem Briefe zu schreiben, und nicht das Textsystem erstmal zu debuggen und immer wieder zu compilieren und dem Chef mitzuteilen, mit dem Brief könnte er ungefähr in einer Woche rechnen. Gruss Reinhard
Reinhard Kern schrieb: > Das Selbstübersetzen von Source-Code ist toll für Softwareentwickler, > aber für reine Anwender (wie etwa eine Sekretärin oder einen > Journalisten) völlig ungeeignet, da man meistens als Entwickler und > Debugger tätig werden muss, um die fast unweigerlich auftretenden Fehler > zu eliminieren. Linux-Freaks werden niemals begreifen, ... Sind wir hier in einem Forum für SekretärInnen oder Journalisten? Nein?
Reinhard Kern schrieb: > Setzt man bei Linux bequeme und intuitive Bedienung durch eine GUI > voraus wie bei Windows, so ist Linux eher langsamer, weil die Grafik > viel umständlicher ins Betriebssystem eingebunden ist. X11 hat gewiss seine Eier, keine Frage. Nicht umsonst hat sich Apple beim Schwenk von System 9 auf OS X dagegen entschieden und lieber Aqua entwickelt. Die alte Netzwerkfähigkeit von X11 wird heute ohnehin kaum noch benutzt. Aber geschwindigkeitsmäßig spielt das mit heutiger Computertechnik keine Geige mehr. Der ganze Grafik-Zinnober ist so schnell, dass sich die PR-Heinis immer wieder neue Gimmicks einfallen lassen müssen, wie sie die Grafik trotzdem wieder langsam bekommen. :-) (Animiertes Aufblenden von Fenstern und sowas.) Spätestens, wenn man diesen Zinnober abschaltet, ist das alles viel schneller, als ein MS-DOS auf dem 80386 je war. Was die Ressourcen frisst, ist der ganze andere Senf, den die "modernen" Desktop-Umgebungen so treiben. Da wird jeder Tastenanschlag mitgezählt um dann vorauszusagen, welche Taste du wohl als nächstes tippen wirst … da kann man wirklich endlos CPU-Leistung reinsetzen. Da nehmen sich aber die "modernen" Desktops für unixoide und Windows praktisch nichts. Beide verplempern dafür unsinnig (meiner Meinung nach) Energie. Der einzige Unterschied: bei den Unixen kannst du dir die Desktop-Umgebung aussuchen, bei Windows funktioniert das so, wie das berühmte Wahlessen in der Schule: entweder du isst's, oder du isst es nicht. ;-) Also wie Chris schon schrieb: wenn dir das zu langsam ist, du aber keinen Desktop brauchst, der dir deine nächsten Tastenanschläge schon weissagen kann, dann nimm dir einfach was anderes.
"Linux ohne Graphik kann man nur mit DOS vergleichen" Genau, man kann es vergleichen, z.B. Bezüglich Netzwerk, ServerProzessen, (gratis) Softwareausstattung, ... Nur mit welchem Resultat? Und von wegen Büro. Ubuntu aufspielen und sofort mit OpenOffice den ersten Brief schreiben. Da sucht man als W7 Instalateur noch nach dem Netzwerktreiber (ich benutze dazu gern Linux-PC's ;-) für die allerwelts Realtec Netzwerkkarte. Der Brief ist da schon lange raus. Früher war ich auch voreingenommen, was Linux anging, aber damals (2000) hat Windows auch noch funktioniert. Heute erzählt es gerne von seiner Einfachheit, die mir schon lange zu kompliziert ist. BTW, ich übersetze tatsächlich manchmal was selber (unter Linux). Wenn ich nicht auf den neuesten (AVR-)GCC warten will. Aber den brauchen ja eh nur Entwickler.
Olaf schrieb: > Du kannst ja mal versuchen einen moeglichst aktuellen Mplayer zu > uebersetzen. :-) Der ist ziemlich gut übersetzbar hier auf einem 11.04 Ubuntu. Er holt sich die aktuellsten Pakete selbst aus dem Netz (ffmpeg,..). Manches muss man manuell nachladen wie libbluray oder wie die heist oder anderes zeug wie iirc eine primitivlib für Farbraumkonvertierungen und was man halt sonst noch in seiner selbst compilierten Version drinn haben will, das meiste will man nicht drinn haben, da sowieso veraltet oder zu exotisch. Da gibts wesentlich schlimmere Pakete wo es einen endlosen Rattenschwanz gibt und man dann bei elementaren Libs aufschlägt wie glibc die man besser nicht einfach mal überbügelt weil sonst die Kiste nicht mehr rund läuft. Besonder übel sind Toolkits (wX) die einen Zoo an weiteren Libs brauchen selbst wenn man gewisse Teile gar nicht auswählt und hinteher läuft es doch nicht rund (Absturz wegen fehlender Lib obwohl man die gar nicht nutzt aber irgendwo wird sie dann doch genutzt). Das ist ein echter Krampf. Wine ist auch so eine Katastrophe.
Ich glaube das ist die eigentliche Herausforderung in der Zukunft, was die Softwareentwicklung besonders in Teams angeht. Eine sinnvolle Quell und Versionsverwaltung mit dynamischer Paketierung.
Thomas Burkhart schrieb: > ich hab seit kurzem Linux zum spielen auf meinem Laptop in der Mint > Distribution. > > Ich versuche seit ein paar Tagen unterschiedliche Softwarepakete zu > compilieren, jedoch renne ich immer wieder in Fehler. .. > Ich hab zuletzt versucht http://gmrender.nongnu.org/ zu bauen und > bekomme dort Verwendest Du die Source-Codes der Distribution, bei Dir Mint (bzw. Ubuntu oder Debian), oder den Source-Code von der Projektseite (gmrender.nongnu.org)? Debian z.B. passt z.T. die Source-Codes an und stellt sicher, dass innerhalb eines Release (z.Zt. wheezy) alle Pakete mit den installierten Bibliotheken möglichst gut zusammen spielen. Ich würde mir, wenn vorhanden, nur die zur Linux-Distribution gehörenden Pakete (als Binär-Paket) installieren. Das Mischen verschiedener nicht abgestimmter Quellen erfordert mehr Arbeit. Bei Debian gibt es aber zu jedem Paket auch den passenden Quelltext als Source-Paket zum selber compilieren, falls man unbedingt selber bestimmte Compiler-Flags verwenden möchte. Siehe z.B. https://packages.debian.org/jessie/gmediarender alesi
:
Bearbeitet durch User
Ja, Software selber kompilieren ist nicht immer lustig... Gottseidank bin ich da kein Freak, der unbedingt alles selber bauen muss. sudo apt-get install ... und gut ists. Kann sein dass die Sourcen aus den Debian-Quellen besser aufeinander abgestimmt sind, aber wenn mein Distributor mir die Software anbietet, wieso nicht gleich die Binärpakete laden? Nur manchmal lässt es sich eben nicht vermeiden. Manche Software gibts nicht in Binärform, bzw. nicht für das eigene System. Letztens brauchte ich einen avr-insight. Also einen insight-Debugger um via avarice meine Atmels zu debuggen. Das hat mich gut nen Nachmittag gekostet, den zu kompilieren. Das Prozedere war ungefähr so: - ./configure - make - Fehler - Fehler googeln und beheben - Fehler - Fehler googeln und beheben - Fehler - Fehler googeln und beheben - Fehler - Fehler googeln und beheben - Fehler - Fehler googeln und beheben Bester Fehler: irgendein (bekanntes) Problem mit einer Latex-Lib. Der Buildprozess lies es sich nicht nehmen, die Doku (= pdf) gleich mit zu bauen, und das ging schief. Musste im Endeffekt in auto-generierten makefiles rum editieren. Ich habs irgendwann gebaut gekriegt, aber lass das mal einen normalen Anwender machen. Muss noch nichtmal eine Sekretärin sein. Auch erfahrene Computernutzer, Informatiker würden da Probleme haben, wenn sie nicht zufällig beruflich mit C, make usw. zu tun haben (oder sehr viel Zeit ins Hobby investiert haben). Ne, wer sich das freiwillig antut hat ein Rad ab ;-) Gottseidank bringt Linux (GNU/Linux, für FSFler) sowas geniales wie Paketverwaltung mit, bspw. apt. Das macht vieles wieder wett :-)
Nu-ja, ist eben wie beim Rumschrauben am Auto: Wenn die Schraube nicht aufgeht, dann geht das Gefummel los. Oder man lässt es bleiben. Oder man geht zum Fachmann und löhnt dafür. Georg B. schrieb: > Ich glaube das ist die eigentliche Herausforderung in der Zukunft, was > die Softwareentwicklung besonders in Teams angeht. Eine sinnvolle Quell > und Versionsverwaltung mit dynamischer Paketierung. Heb dir den Text gut auf, den kannst du bis an dein Lebensende alle 10 Jahre posten! ;-)
Das ist der Grund: a) Warum die echten Linuxer so breite Oberschenkel haben. Sie schlagen sich ständig, vor Lachen, auf selbige. Da musst Du doch nur die Bibliothek xy in der Version 12.2.4 - nicht 12.2.3, die enthält einen Fehler - installieren. Weis doch jeder... b) Ich - wenn möglich - einen weiten Bogen um alles, was Linux heißt mache. c) Die Oberschenkel von Billy-Boy bereits gigantische Ausmaße annehmen.
ben schrieb: > Gottseidank bringt Linux (GNU/Linux, für FSFler) sowas geniales wie > Paketverwaltung mit, bspw. apt. > Das macht vieles wieder wett :-) Aber nicht alles: solange es ein grundsätzliches Konzept von Linux ist, Software nicht für Benutzer, sondern für andere Entwickler zu schreiben, die in der Lage sind, das Programm erst mal zu compilieren und die Fehler rauszumachen, ist es schlicht und einfach als Desktop-System unbrauchbar. Und dann bleibt für Nicht-IT-Profis LEIDER nur noch Windows übrig. Das ist etwa der gleiche Unterschied wie wenn man sich ein Auto kauft, um morgens zuverlässig zur Arbeit zu kommen, oder einen verrosteten Oldtimer zum Dranrumbasteln. Georg
Georg schrieb: > Aber nicht alles: solange es ein grundsätzliches Konzept von Linux ist, > Software nicht für Benutzer, sondern für andere Entwickler zu schreiben, > die in der Lage sind, das Programm erst mal zu compilieren und die > Fehler rauszumachen, ist es schlicht und einfach als Desktop-System > unbrauchbar. Und dann bleibt für Nicht-IT-Profis LEIDER nur noch Windows > übrig. Das grundsätzliche Konzept vom Linux ist, daß alles was ein Normalanwender braucht, bereits in den Paketverwaltungen enthalten ist und simpel installiert werden kann. Wer spezielle Programme braucht, muß halt kompilieren. Dafür kostet es ja auch nichts. Man kann auch für Linux Löhnware kaufen. Die braucht man dann auch nicht zu compilieren. Gruß Andreas
Andreas B. schrieb: > Wer spezielle Programme braucht, muß halt kompilieren. Wobei ich hier das AUR-Prinzip von Archlinux sehr elegant finde. Damit + z.B. yaourt kann man die Software automatisch kompilieren lassen. "yaourt suchbegriff", das richtige Suchergebnis aussuchen und schon wird automatisch heruntergeladen, compiliert und (ordentlich über die Paketverwaltung!) installiert. Das ist so komfortabel, dass ich es auch für fertig compilierte Programme die nicht in den Repos sind nutze. Die könnte man zwar ohne kompilieren installieren, aber das ist komplizierter ist als yaourt. Firefox-Beta oder AVR8-Burn-O-Mat beispielsweise.. Und da das AUR riesig ist, musste ich auch noch keine Spezialsoftware auf ArchLinux kompilieren. Dummerweise ist Arch ansonsten für Anfänger unbrauchbar :-D
Simon S. schrieb: > Damit + > z.B. yaourt kann man die Software automatisch kompilieren lassen. Und das funktioniert zuverlässig? Also zu 100%? Denn im Idealfall sieht der Buildvorgang von GNU Software ja so aus:
1 | ./configure |
2 | make
|
3 | make install |
Das würde ja auch ein nicht-ITler hinkriegen. In der Praxis allerdings klappt das nur in gefühlten 50% der Fälle (ACHTUNG: subjektives Empfinden!) Und dann gehts ans googlen. Hat man Glück fehlt lediglich eine lib, die man davor noch kompilieren und installieren muss. Hat man Pech darf man im makefile rumwurschteln so wie ich letztens. Das ist der Punkt an dem der Anwender aufgibt. Aber grundsätzlich kann man schon sagen: klappt alles, ist Linux komfortabler, was das installieren von Software angeht. Hakts irgendwo, wirds hässlich ;-)
ben schrieb: > Hakts irgendwo, > wirds hässlich ;-) Das entspricht dann der Suche nach fehlenden DLLs bei Windows. Gruß Andreas
ben schrieb: > Und das funktioniert zuverlässig? Also zu 100%? Zu 100% natürlich nicht, denn auch das AUR lebt von seinen Usern, die Packages erstellen und auf dem neuesten Stand halten. Dazu werden Scripts verwendet (PKGBUILD), die sich um den Kompiliervorgang sowie das Erstellen des Packages kümmern. Diese Scripts kann jeder ins AUR hochladen und so anderen seine Packages zur Verfügung stellen.
Andreas B. schrieb: > Das entspricht dann der Suche nach fehlenden DLLs bei Windows. Naja, das Problem der fehlenden Abhängigkeiten hat man unter Windows prinzipiell ja eigentlich auch. Bei Windows ist es gefühlt allerdings eher die Praxis die Abhängigkeiten in der .zip mit dem Quellcode direkt mitzuliefern statt sie selbst zusammensuchen zu lassen.
>Und dann gehts ans googlen. Hat man Glück fehlt lediglich eine lib, die >man davor noch kompilieren und installieren muss. Auch kein Problem. Man muss sich nur durch tausend Zeilen, die während der Übersetzung ausgegeben werden, wühlen. Man weis zwar nicht worum es in den einzelnen Zeilen geht, aber der ausgegebene Fehler in Zeile 827 ist klar und deutlich zu erkennen. Die fehlende Datei Kaesebroetchen.hpp dann zu finden ist, dank Google oder Bing, kein Problem. Das anschließend Butterbrot.o vermisst wird darf dann aber keinen wundern. Und so weiter...
Aber jetzt mal ernsthaft - passend zu jeder Visual Studio Version als Entwickler immer das passende "visual studio redistributable package" mit auszliefern bei Software ist auch nicht "toll gelöst". Super Methode der Bibliotheksverwaltung :-/ bluppdidupp schrieb: > Andreas B. schrieb: >> Das entspricht dann der Suche nach fehlenden DLLs bei Windows. > > Naja, das Problem der fehlenden Abhängigkeiten hat man unter Windows > prinzipiell ja eigentlich auch. Bei Windows ist es gefühlt allerdings > eher die Praxis die Abhängigkeiten in der .zip mit dem Quellcode direkt > mitzuliefern statt sie selbst zusammensuchen zu lassen.
Wenn man statisch linkt (/MT) kann man sich das mitliefern des Redistributable Packages sparen (Aber dann profitiert die Anwendung u.a. nicht mehr von (Sicherheits-)Updates der Komponente via Windows-Update)
bluppdidupp schrieb: > Naja, das Problem der fehlenden Abhängigkeiten hat man unter Windows > prinzipiell ja eigentlich auch. dll - Versionen... Kein eigentliches Windows - Problem, aber hey -> kennt einer noch die D-Link Netzwerkkarten DFE 530 TX oder so und die Treiber dazu? Manchmal passten nicht mal die mitgelieferten Treiber, war das eine elende Sucherei und beileibe kein Einzelfall... MfG Elux
Reinhard Kern schrieb: > Es gibt garkeinen Grund, warum Linux schneller sein sollte. Die Leute > die das behaupten reden von einem Linux ohne Grafik, aber das kann man > nur mit DOS vergleichen (und ein MSDOS ist auf einem heutigen Rechner > auch rasend schnell). Der Vergleich hinkt aber doch sehr. DOS kann fast nichts, während ein Linux ohne graphische Oberfläche bis eben auf die GUI-Programme immer noch alles kann. Jörg Wunsch schrieb: > Die alte Netzwerkfähigkeit von X11 wird heute ohnehin kaum noch benutzt. Ich nutze sie recht häufig (inklusive remote-OpenGL) und würde mich darüber ärgern, sie nicht mehr zu haben. > Aber geschwindigkeitsmäßig spielt das mit heutiger Computertechnik > keine Geige mehr. Der ganze Grafik-Zinnober ist so schnell, dass sich > die PR-Heinis immer wieder neue Gimmicks einfallen lassen müssen, wie > sie die Grafik trotzdem wieder langsam bekommen. :-) (Animiertes > Aufblenden von Fenstern und sowas.) Das wäre mir beim PC ja egal. Da kann man es meistens ausschalten. Beim Telefon ist das heute aber auch schon normal, nur in der Regel halt nicht abschaltbar. Alles muß schön bunt und flüssig animiert faden und wabern und drehen und braucht dafür dann einen Vierkerner mit 2 Ghz und einem 3D-Beschleuniger. Am Ende wundert man sich dann noch darüber, daß das Telefon jeden Tag geladen werden will.
>Auch empfinde ich make files nicht undbedint hilfreich um ein Projekt zu >verstehen. Eine VS Solution kann man einfach in die IDE laden und gut ist. >Ich habe einige zeit gebraucht um ein Projekt in Ecliepse zum laufen zu bringen. wenns nur ne make gibt war die "IDE" wohl vim oder emacs XD Projekt von richtigen Proggern halt :P >Gottseidank bin ich da kein Freak, der unbedingt alles selber bauen >muss. sudo apt-get install ... und gut ists. Bissde feststellst das in dem debian-paket ein riesen bug ist oder die software/ide/etc viel zu alt ist um das Megacoole Projekt das du da im Blog liebst nachzumachen wenigstens kann man anstelle make install ein checkinstall machen... aber debian ist mir da zu mies, ich nehm manjaro oder gleich arch. da gibs AUR und frische updates damit man auch aktuelle Sachen zum laufen bekommt und der ./configure einem nich sagt: Nö, dein halbes system iss mir zu alt etc... >wieso nicht gleich die Binärpakete laden? weil Versionen zu alt? Das ist wie mit Killerspielen. Die kauft man auch nicht in deutschland wegen zensur etc. >Das ist etwa der gleiche Unterschied wie wenn man sich ein Auto kauft, >um morgens zuverlässig zur Arbeit zu kommen, oder einen verrosteten >Oldtimer zum Dranrumbasteln. Da arm und reich immer mehr auseinander gehen hat der arbeiter eh bald keine Wahl mehr und kann sich nur noch das auto, was vom schief angucken fast auseinanderfällt leisten. Von daher: Linux-Analogie goes RealLife... >Und da das AUR riesig ist, musste ich auch noch keine Spezialsoftware auf ArchLinux kompilieren. >Dummerweise ist Arch ansonsten für Anfänger unbrauchbar :-D Manjaro hat nen "normalen" Betriebssystem installer und du bekommst: AUR + yaourt gratis dazu :-) >> z.B. yaourt kann man die Software automatisch kompilieren lassen. >Und das funktioniert zuverlässig? Also zu 100%? Sofern das AUR paket nicht uralt ist, ja. AUR geht so: Da hat jemand die software mal selbst compiliert mit all seinen Hürden und weis nun wie es geht. Das ganze schreibt er in eine art bash-script, PKGBUILD genannt. sieht so aus: https://aur.archlinux.org/packages/ff/ffmpeg-full/PKGBUILD und da ist jetzt genau drinne beschrieben, wo die source runtergeladen wird und wie sie (vollautomatisch, nicht interaktiv) zu compilieren ist. yaourt compiliert sogar AUR abhängigkeiten... Das Beste: will man was aufm andern Linux compilieren könnte man im PKGBUILD abspicken was man tun muss, wenn man das compilen nicht hinkriegt... Hier ein einfacheres beispiel: https://aur.archlinux.org/packages/ff/ffcast/PKGBUILD in build() steht wie man es compiliert package() installiert die binaries in $pkgdir (temporäreS root-verzeichnis) das script wird von makepkg benutzt um das paket zu bauen: #---------- mkdir /tmp/la cd /tmp/la wget https://aur.archlinux.org/packages/ff/ffcast/PKGBUILD makepkg #---------- und das Paket: ffcast-1:1.1-1-i686.pkg.tar.xz wurde gebaut/compiliert+paketiert installieren: sudo pacman -U ffcast-1:1.1-1-i686.pkg.tar.xz Paket Wieder entfernen/deinstallieren: sudo pacman -R ffcast natürlich ist yaourt bequemer, nehm ich auch immer :-) Ich hab zwar auch mal pakete die nicht mehr wollen, weil wohl zu alt, aber in den meissten Fällen hat yaourt mir problemlos das installiert, was ich haben wollte...
Simon S. schrieb: > Dummerweise ist Arch ansonsten für Anfänger unbrauchbar Distros wie Arch oder Gentoo stellen auch gar nicht den Anspruch von Anfaengern benutzt werden zu wollen. Linux/Unix Systeme stellen immer noch den Anspruch das der Benutzer weiss, was er da tut, und das ist auch richtig so. Das merkt man bei Arch/Gentoo ganz besonders. Ich erinnere mich hier an einen Thread, von vor ein paar wochen, in dem in etwa zu lesen war: "Ich benutze seit 2 Jahren Ubuntu... ... jetzt hab ich mir was installiert und da ist ja gar keine .exe-Datei, wie starte ich das jetzt?" Tja, was soll man dazu sagen? ben schrieb: > Aber grundsätzlich kann man schon sagen: klappt alles, ist Linux > komfortabler, was das installieren von Software angeht. Hakts irgendwo, > wirds hässlich Selbst wenn es hakt, ist es mir mittlerweile deutlich lieber als Windows. Installiere mal Visual Studio 2008, 2010, 2012 und 2013 (arbeitsbedingt ist das bei uns auf arbeit so >:-( ) und dann versuch mal eine Version davon komplett und rueckstandsfrei zu entfernen. Und wenn bei 2013 der Testzeitraum abgelaufen ist, bekommst du sogar mit den Express-Versionen probleme... Aber zum Glueck gibt es ja Betriebssysteme die nicht nur nichts kosten, sondern im gesamten auch besser Funktionieren. Totschlagargument fuer mich immer wieder: Paketverwaltung! Linux: ueber die Paketverwaltung ein System-Update machen und alles ist aktualisiert, auch jedes noch so unnuetze Programm das ich installiert habe. Windows: viel spass beim surfen und krampfhaften suchen und informieren ob es fuer meine 598 Programme irgendwelche updates gibt, sofern die Programme keine eingebaute Updatefunktion haben, d.h. von den 598 bleiben immernoch 596 Programme uebrig um die ich mich selber kuemmern muss. aber schoen das man im jahre 2014 immerhin schon fuer M$-Produkte ueber Windows-Update versorgt wird... Flummi schrieb: > Ich hab zwar auch mal pakete die nicht mehr wollen, weil wohl zu alt, Das schoene ist ja: waehrend der Installation wird das ja auch noch gesagt, so z.B. beim repetierHost. Da kommmst waehrend der Installation die Zeile "...is not supported to work with Perl >=5.16 ...". Ok, die Zeile ist schnell wieder weg, aber dir wird immerhin gesagt wodran es haengt. Bei Windows heisst es im idealfall: Die Anwendung hat aufgehoert zu funktionieren. Ok, du erfaehrst nicht, warum es nicht mehr geht, aber hey, wer will das schon wissen...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.