|
|
|
|
|
|
|
| | Zitat von Oli
Wäre ja ziemlich umständlich, wenn ich all die Unterordner in /usr/lib/ zum LD_LIBRARY_PATH hinzufügen müsste.
| |
das machen und müssen die auch nicht, weil a) linux und viele andere unix systeme einen run-time dynamic linker kennen und der hat die unglaubliche fähigkeit rekursiv durch verzeichnisse gehen zu können (nebenbei cached der das auch) und b) weil die programme in ihren start scripts nur den entsprechenden pfad für ihre persönlichen libs hinzufügen.
natürlich kann man auch den pfad statisch mit darein schmeissen, allerdings ist das nicht immer so ganz empfehlenswert.
in deinem readelf output da oben, steht übrigens, dass die lib via dem rtdl system gesucht und geladen werden soll. da steht nämlich kein expliziter pfad drin.
was du eigentlich wissen willst ist, wo das system die datei sucht und wie die gesuchten dynamischen objekte, die dein programm laden will, heissen. das machst du mit ldd, welche dazu den dynamischen linker (ld.so) befragt.
/e (fake)
https://www.youtube.com/watch?v=69V__a49xtw
|
|
|
|
|
|
|
|
|
|
|
|
Das was du suchst, nennt sich runtime path. -Wl,-rpath=dir siehe man ld. Das bezieht sich dann nur auf das eine Programm. Alle anderen finden die Bibliothek trotzdem nicht.
|
|
|
|
|
|
|
|
|
|
|
mit LD_PRELOAD lässt sich auch wunderbar “kopierschutz” aushebeln, weil du damit quasi alles, was dynamisch verlinkt ist, ersetzen kannst.
ein paar findige menschen haben z.b. dropbox dazu gebracht, seinen eigenen sourcecode zu dumpen 
PS: ich begreife die C/C++-konvention nicht, Typ *varname = ... zu schreiben. „*“ ist doch teil des typs! char *box bedeutet doch nicht „box-zeiger ist ein char“, sondern „box ist ein char-zeiger“.
|
|
|
|
|
|
|
|
|
|
|
Doch, es bedeutet ersteres 
char *name, buchstabe;
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Doch, es bedeutet ersteres
char *name, buchstabe;
| |
finde ich nicht. ich finde, dass diese initialisierung eine andere semantik haben sollte und komisch ist.
man hat später schließlich keine variable mit dem bezeichner *name , sondern nur name , und diese variable enthält einen wert vom typ char* . variablen in C sind boxen. sie enthalten ein ding mit einer bestimmten größe. und name enthält halt einen char*
|
|
|
|
|
|
|
|
|
|
|
|
Da hast du recht, ich bin mir aber nicht sicher, ob du hier nicht gerade Qualifiers (const, static, ...) und Declarators (&, *, []) durcheinander bringst. Ein Qualifier modifiziert quasi den Datentyp, während ein Declarator nur die aktuell deklarierte Entität betrifft.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Ratatoskr
Das was du suchst, nennt sich runtime path. -Wl,-rpath=dir siehe man ld. Das bezieht sich dann nur auf das eine Programm. Alle anderen finden die Bibliothek trotzdem nicht.
| |
Jo, das ist doch genau das, was ich schrieb. 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ernsthaft?
Ich finde den tenären Operator übrigens klasse.
|
|
|
|
|
|
|
|
|
|
|
Aber doch bitte nicht linksassoziativ.
Ich reg mich über PHP nicht mehr auf. Wer's nutzen möchte, bitte, soll er.
Portal2 ist übrigens als Beta nativ auf Linux erschienen. Crasht bei mir in <4 Sekunden kommentarlos nach Start des Singleplayers. Hach, das wird bestimmt noch
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von teK
| |
Ich finde, die könnten vim in systemd integrieren.
| |
Schlechter Troll, würde nicht füttern.
| |
Das war gegen systemd getrollt, bezogen auf diesen total überflüssigen networkd. Sei nicht immer so unfreundlich zu mir. :-(
--
Traxer: hast du irgendwelche Links/Hintergrundinfos zu dem rekursiven /usr/lib Suchen und dem Cache? Das interessiert mich, ich muss dringend mal ein bisschen Wissen über's Linken und so weiter sammeln.
Ordentliche ld tutorials, die nicht nur aus man pages bestehen, sind auch willkommen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Oli am 26.02.2014 9:50]
|
|
|
|
|
|
|
|
|
Okay, rpath Beispiel: https://dl.dropboxusercontent.com/u/83450/rpath.zip
Wie kriege ich es hin, dass das Beispiel funktioniert (d.h., er erfolgreich linkt), ohne, dass ich die main.o expilizit gegen libfoo.so linken muss?
Ich will also, dass meine Executable von libbar abhängt und libbar von libfoo.
---
| | Hello Oli,
We would like to thank you for the participation in our C++ IDE survey. Unfortunately our first private preview as we see from the information that you have kindly provided won’t work well in your environment (build system, compiler, debugger or libraries used are not supported yet). We kindly ask you to be patient and to wait for later builds with better support for your project. | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 26.02.2014 10:51]
|
|
|
|
|
|
|
|
|
| | Zitat von flying sheep
PS: ich begreife die C/C++-konvention nicht, Typ *varname = ... zu schreiben. „*“ ist doch teil des typs! char *box bedeutet doch nicht „box-zeiger ist ein char“, sondern „box ist ein char-zeiger“.
| |
Vorab Begriffsdefinition, wie von rats schon angedeutet:
Specificator: primitive Typen (char, int, double), class, enum und Qualifier wie const
Declarator: Identifier (Bezeichner) und Operatoren (*, &, [] usw.)
In der Sprache C sind Deklartionen aus Basistyp und Deklartor(en) aufgebaut. Ein Deklarator legt den Variablennamen fest und leitet den zusammengesetzten Typ vom Basistyp ab. Also ist int ein Basistyp und der Deklarator besteht aus * oder & und Variablennamen.
In diesem Sinn kann man vom Basistyp int Variablen mit unterschiedlichen Namen und unterschiedlichen zusammengesetzten Typen ableiten (primitiver Typ, Zeiger, Referenz).
| |
| Code: |
// C-Style
#include <iostream>
using namespace std;
int main() {
// reference must be initalized
int ivar, *iptr, &iref = ivar;
return 0;
}
|
|
Der Erfinder von C++, Bjarne Stroustrup, bevorzugt eine anderen Notationsstil um die logische Semantik des Typs zu betonen. Der Teil des Deklarators, welcher die Ableitung des zusammengesetzten Typs bestimmt, wird bei Stroustrup beim Basistyp notiert und nicht beim Variablennamen. Ich finde das logisch und leichter lesbar.
Problem dabei ist aber, dass der Syntax von C vorgibt, dass die Ableitung und der Variablennamen zusammen den Deklarator bilden.
Warnung: Ein Deklartor gilt nur fuer eine Variable!
| |
| Code: |
// C++-Style
#include <iostream>
using namespace std;
int main() {
int ivar;
int* iptr;
int &iref = ivar;
// dangerous, because misleading
// int* iptr, i_am_not_a_pointer;
return 0;
}
|
|
Empfehlung:
Bleib bei eine Schreibweise. Wenn du die C++-Schreibweise anwendest, deklariere genau eine Variable in einem Statement, wenn ein zusammengesetzter Typ angewendet wird.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 26.02.2014 15:48]
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Okay, rpath Beispiel: https://dl.dropboxusercontent.com/u/83450/rpath.zip
Wie kriege ich es hin, dass das Beispiel funktioniert (d.h., er erfolgreich linkt), ohne, dass ich die main.o expilizit gegen libfoo.so linken muss?
Ich will also, dass meine Executable von libbar abhängt und libbar von libfoo.
| |
Das Problem ist $ORIGIN. ld, der statische Linker, die Endstufe beim Kompilieren, expandiert $ORIGIN nicht. ld.so, der dynamische Linker, der dynamische Bibliotheken in den Speicher läd, versteht $ORIGIN. Du musst ld extra mit einem relativen Pfad füttern oder libfoo.so anderweitig auffindbar machen (LD_LIBRARY_PATH). Konkret auf dein Beispiel bezogen, heißt das:
| |
| Code: |
g++ -o run/main.run obj/main.o -Wl,-rpath='$ORIGIN/../lib',-rpath-link=lib -Llib -lbar
|
|
oder:
| |
| Code: |
...
g++ -shared -o lib/libbar.so obj/bar.o -Wl,-rpath='$ORIGIN',-rpath=lib -Llib -lfoo
...
g++ -o run/main.run obj/main.o -Wl,-rpath='$ORIGIN/../lib' -Llib -lbar
|
|
Letzteres hat allerdings den für ld.so sinnlosen lib Eintrag im RPATH von libbar.so, stört aber keinen.
|
|
|
|
|
|
|
|
|
|
|
|
Aha. Besten Dank! Man würde ja denken, sowas würde von cmake automatisch und immer richtig übernommen...
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
int* iptr, i_am_not_a_pointer; | |
jo, genau dieser teil des sprachdesigns ist eben imho blödsinn. würden man pro statement nur deklarationen mit grundtyp und einem dazugehörigen satz deklaratoren machen dürfen, also wäre die semantik so:
| |
| Code: |
int** iptrptr, iptrptr2; |
|
gäbe es weder fallstrick noch müssten wir unintuitive syntax nutzen (die existiert um auf diesen fallstrick hinzuweisen)
|
|
|
|
|
|
|
|
|
|
|
|
Bedanke darfst du dich bei K&R :-)
|
|
|
|
|
|
|
|
|
|
|
|
Gibts iwo n günstigen arm soc mit mehreren sata slots? Würd mir gerne n nas basteln
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Traxer: hast du irgendwelche Links/Hintergrundinfos zu dem rekursiven /usr/lib Suchen und dem Cache? Das interessiert mich, ich muss dringend mal ein bisschen Wissen über's Linken und so weiter sammeln.
| |
Nachdem ich so unfreundlich war, jetzt wieder ein freundlicher Hinweis: mach doch Mal: sudo ldconfig -p.
|
|
|
|
|
|
|
|
|
|
|
Ah, verstehe. Das bedeutet, in /etc/ld.so.conf kann ich weitere Verzeichnisse angeben. Aber ich glaube, automatisch wird da unterhalb von /usr/lib nichts gefunden. (sonst wäre ich ja nciht auf den eingangs beschriebenen Fehler gestoßen).
/etc/ld.so.cache beinhaltet diesen Cache.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Wie kriege ich es hin, dass das Beispiel funktioniert (d.h., er erfolgreich linkt), ohne, dass ich die main.o expilizit gegen libfoo.so linken muss?
| |
generell, wenn du nicht statisch linken willst und keine direkte dependency willst, dann ist der weg dlopen.
andernfalls, nicht statisch und nicht manuell, dann bleibt dir nur der weg über den rtdl.
|
|
|
|
|
|
|
|
|
|
|
http://atom.io/
| | | Whether you're tweaking the look of Atom's interface with CSS or adding major features with HTML and JavaScript | |
Ja, naja.. Mh, eher nicht?
k thx bye
/e: Sieht irgendwie exakt aus wie Sublime 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von theromi am 27.02.2014 0:11]
|
|
|
|
|
|
|
|
|
| | Zitat von theromi
k thx bye | |
|
|
|
|
|
|
|
|
|
|
|
|
Zur Erinnerung, ich glaube, es ging um einen Texteditor.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von teK
Zur Erinnerung, ich glaube, es ging um einen Texteditor.
| |
…ja?
|
|
|
|
|
|
|
|
|
|
|
|
Wofür braucht der ein Server Socket Backend?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Wofür braucht der ein Server Socket Backend?
| |
Es ist gar nicht so doof, einen Editor als Server-Client app aufzubauen; Tun doch viele Programme. Außerdem ist der Kram, den die Leute von Github sonst so produzieren, eigentlich qualitativ ganz ok. Ich werde es nachher mal testen; Wenn ich mit HTML und CSS Kenntnissen das Ding leicht erweitern kann, wäre das schonmal ein Vorteil.
/e: Ach, ist noch nicht öffentlich.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 27.02.2014 8:14]
|
|
|
|
|
|
|
|
|
|
Emacs kann auch als Server laufen, ist sogar gar nicht unüblich. Ich bau mir auch gleich mein Emacs als System.d user service
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.29 - wie lang das wohl noch gutgeht? ) |
