Apropos Libraries

[Helmut Schellong]

Ich wollte ein Programm von einer neueren Version eines OS laufen lassen.
Dazu kopierte ich benötigte Libs nach /usr/local/lib, 285 an der Zahl.
Diese waren alle neu, also zuvor nicht vorhanden, wurden folglich allgemein nicht gebraucht.

Der Start von KDE mittels kdestart funktionierte dadurch nicht mehr!
Vor dem Abbruch gab es die Fehlermeldung: "libc++.so.1 - Unbekanntes Symbol ...".

Ich frage mich, warum diese zuvor nicht vorhandene Lib überhaupt geöffnet wurde!
Kein Wunder, daß da unbekannte Symbole enthalten sind.
Da ist was inkonsistent.


--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html

[Bonita Montero]

Am 15.06.2023 um 11:12 schrieb Helmut Schellong:
> Ich wollte ein Programm von einer neueren Version eines OS laufen lassen.
> Dazu kopierte ich benötigte Libs nach /usr/local/lib, 285 an der Zahl.
> Diese waren alle neu, also zuvor nicht vorhanden, wurden folglich
> allgemein nicht gebraucht.
>
> Der Start von KDE mittels kdestart funktionierte dadurch nicht mehr!
> Vor dem Abbruch gab es die Fehlermeldung: "libc++.so.1 - Unbekanntes
> Symbol ...".

Ist das nicht die C++-Runtime von clang++ ?
Die hattest Du bestimmt vorher schon auf dem Rechner
und da spielt der Versionsstand sicher eine Rolle.

[Helmut Schellong]

On 06/15/2023 18:50, Bonita Montero wrote:
> Am 15.06.2023 um 11:12 schrieb Helmut Schellong:
>> Ich wollte ein Programm von einer neueren Version eines OS laufen lassen.
>> Dazu kopierte ich benötigte Libs nach /usr/local/lib, 285 an der Zahl.
>> Diese waren alle neu, also zuvor nicht vorhanden, wurden folglich allgemein nicht gebraucht.
>>
>> Der Start von KDE mittels kdestart funktionierte dadurch nicht mehr!
>> Vor dem Abbruch gab es die Fehlermeldung: "libc++.so.1 - Unbekanntes Symbol ...".
>
> Ist das nicht die C++-Runtime von clang++ ?
> Die hattest Du bestimmt vorher schon auf dem Rechner
> und da spielt der Versionsstand sicher eine Rolle.

Ich schrieb doch, daß die zuvor nicht auf dem Rechner war.
Jedenfalls nicht in /usr/local/lib.

Der C-Standard fordert ja irgendwelche Libs, wo die im Standard
definierten C-Funktionen enthalten sind.
Und das ist realisiert aus alten Zeiten 'libc.a'.

>> Ich frage mich, warum diese zuvor nicht vorhandene Lib überhaupt geöffnet wurde!
>> Kein Wunder, daß da unbekannte Symbole enthalten sind.
>> Da ist was inkonsistent.

28972435 -r--r--r-- 1 root wheel 166 Jun 22 2018 /usr/lib/libc.so
28972769 -r--r--r-- 1 root wheel 4156284 Jun 22 2018 /usr/lib/libc.a
34429861 -r--r--r-- 1 root wheel 1449392 Jun 22 2018 /usr/lib32/libc.so.7
34430063 -r--r--r-- 1 root wheel 176 Jun 22 2018 /usr/lib32/libc.so
34430438 -r--r--r-- 1 root wheel 2721658 Jun 22 2018 /usr/lib32/libc.a

28972530 -r--r--r-- 1 root wheel 832992 Jun 22 2018 /usr/lib/libc++.so.1
28972707 -r--r--r-- 1 root wheel 1982076 Jun 22 2018 /usr/lib/libc++.a
28972905 -r--r--r-- 1 root wheel 141 Jun 22 2018 /usr/lib/libc++.so
34429965 -r--r--r-- 1 root wheel 145 Jun 22 2018 /usr/lib32/libc++.so
34430398 -r--r--r-- 1 root wheel 784116 Jun 22 2018 /usr/lib32/libc++.so.1
34430493 -r--r--r-- 1 root wheel 1461664 Jun 22 2018 /usr/lib32/libc++.a

In /usr/local (Third party) gibt es so etwas nicht.

[Enrik Berkhan]

Helmut Schellong <r...@schellong.biz> wrote:

[viel off-topic]

> 28972435 -r--r--r-- 1 root wheel 166 Jun 22 2018 /usr/lib/libc.so
> 28972769 -r--r--r-- 1 root wheel 4156284 Jun 22 2018 /usr/lib/libc.a
> 34429861 -r--r--r-- 1 root wheel 1449392 Jun 22 2018 /usr/lib32/libc.so.7
> 34430063 -r--r--r-- 1 root wheel 176 Jun 22 2018 /usr/lib32/libc.so
> 34430438 -r--r--r-- 1 root wheel 2721658 Jun 22 2018 /usr/lib32/libc.a
>
> 28972530 -r--r--r-- 1 root wheel 832992 Jun 22 2018 /usr/lib/libc++.so.1
> 28972707 -r--r--r-- 1 root wheel 1982076 Jun 22 2018 /usr/lib/libc++.a
> 28972905 -r--r--r-- 1 root wheel 141 Jun 22 2018 /usr/lib/libc++.so
> 34429965 -r--r--r-- 1 root wheel 145 Jun 22 2018 /usr/lib32/libc++.so
> 34430398 -r--r--r-- 1 root wheel 784116 Jun 22 2018 /usr/lib32/libc++.so.1
> 34430493 -r--r--r-- 1 root wheel 1461664 Jun 22 2018 /usr/lib32/libc++.a
>
> In /usr/local (Third party) gibt es so etwas nicht.

Es ist nicht unüblich, dass shared objects in einem "Standardpfad"
gesucht werden, der durchaus /usr/local/lib vor /usr/lib enthalten kann.
Ich weiß nicht, wie dynamisches Linken bei dem von dir favorierten
Betriebssystem funktioniert. Da kannst du ja mal anfangen zu suchen.

Das hat aber nur entfernt mit dem Thema dieser Gruppe zu tun.

Gruß,
Enrik

[Helmut Schellong]

Im C-Standard ist das Wort 'Library' ungefähr 500-mal enthalten.
Der Standard beschreibt sogar konkret vorherige Translationsphasen mit Hilfe
von Einzelobjekten oder zusammengefaßt in Libraries, um schließlich
eine ausführbare Datei produziert zu haben, per externem Linken.

OFFtopic ist dies Thema folglich gar nicht!
Denn der C-Standard ist ja mit allem, was er enthält, zweifellos ONtopic.

Ich habe mit meinem Posting keine Hilfe hier gesucht, sondern ich wollte
konzeptionell fehlerhaftes Verhalten beim Linken aufzeigen.
Denn es wurde grundlos der Start des grafischen Systems des OS abgebrochen,
wegen eines Öffnens einer neuen, fremden Lib mit unbekannten Symbolen, obwohl
der Vorgang bereits 'satisfied' war.

[Bonita Montero]

Am 15.06.2023 um 20:14 schrieb Helmut Schellong:

> Ich schrieb doch, daß die zuvor nicht auf dem Rechner war.
> Jedenfalls nicht in /usr/local/lib.

Ich glaubs ja eher nicht weil das ja eine wirklich
verbreitete C++ -Runtime unter Linux ist.

> Der C-Standard fordert ja irgendwelche Libs, wo die im Standard
> definierten C-Funktionen enthalten sind.

Es geht hier um eine C++-Runtime.

[Enrik Berkhan]

Helmut Schellong <r...@schellong.biz> wrote:
> Im C-Standard ist das Wort 'Library' ungefähr 500-mal enthalten.
> Der Standard beschreibt sogar konkret vorherige Translationsphasen mit Hilfe
> von Einzelobjekten oder zusammengefaßt in Libraries, um schließlich
> eine ausführbare Datei produziert zu haben, per externem Linken.

Und was steht da zu shared objects? In deinem Ursprungsposting ging es
WIMRE um eine libc++.so.1. Das ist keine Library.

> Ich habe mit meinem Posting keine Hilfe hier gesucht, sondern ich wollte
> konzeptionell fehlerhaftes Verhalten beim Linken aufzeigen.
> Denn es wurde grundlos der Start des grafischen Systems des OS abgebrochen,
> wegen eines Öffnens einer neuen, fremden Lib mit unbekannten Symbolen, obwohl
> der Vorgang bereits 'satisfied' war.

Um "konzeptionell fehlerhaftes Verhalten" aufzeigen zu können, sollte
man das Konzept zuvor verstanden haben.

[Helmut Schellong]

On 06/16/2023 14:21, Bonita Montero wrote:
> Am 15.06.2023 um 20:14 schrieb Helmut Schellong:
>
>> Ich schrieb doch, daß die zuvor nicht auf dem Rechner war.
>> Jedenfalls nicht in /usr/local/lib.
>
> Ich glaubs ja eher nicht weil das ja eine wirklich
> verbreitete C++ -Runtime unter Linux ist.

Du hast offenbar keine der Erklärungen von mir gelesen.
Auch nicht mein heutiges Posting.
Sie war definitiv nicht in '/usr/local/lib'!
Ich hatte alle Namen zuvor geprüft.

Das Linken war bereits zuvor mit /usr/lib/libc++.so.1 erfolgt.
Eine ältere Lib, als die, die ich kopierte.
In der neueren steht 'FBSD_1.5', in der älteren 'FBSD_1.3'.
Das neuere Symbol war unbekannt, weshalb kdestart abbrach.

>> Der C-Standard fordert ja irgendwelche Libs, wo die im Standard
>> definierten C-Funktionen enthalten sind.
>
> Es geht hier um eine C++-Runtime.
>

Nein, Inhalt und Name sind irrelevant.
Hätte ich den Namen doch nicht genannt, ich Dussel.

[Bonita Montero]

Am 16.06.2023 um 15:34 schrieb Helmut Schellong:
> On 06/16/2023 14:21, Bonita Montero wrote:
>> Am 15.06.2023 um 20:14 schrieb Helmut Schellong:
>>
>>> Ich schrieb doch, daß die zuvor nicht auf dem Rechner war.
>>> Jedenfalls nicht in /usr/local/lib.
>>
>> Ich glaubs ja eher nicht weil das ja eine wirklich
>> verbreitete C++ -Runtime unter Linux ist.
>
> Du hast offenbar keine der Erklärungen von mir gelesen.
> Auch nicht mein heutiges Posting.
> Sie war definitiv nicht in '/usr/local/lib'!

Das glaub ich eben nicht, denn die libc++ wird sicher so häufig durch
andere Anwedungen genutzt, dass die sowieso schon da sein sollte.

> Nein, Inhalt und Name sind irrelevant.
> Hätte ich den Namen doch nicht genannt, ich Dussel.

Ne, das ist wohl relevant, denn sowas ist i.d.R. sowieso
schon vorhanden.

[Helmut Schellong]

On 06/16/2023 14:16, Enrik Berkhan wrote:
> Helmut Schellong <r...@schellong.biz> wrote:
>> Im C-Standard ist das Wort 'Library' ungefähr 500-mal enthalten.
>> Der Standard beschreibt sogar konkret vorherige Translationsphasen mit Hilfe
>> von Einzelobjekten oder zusammengefaßt in Libraries, um schließlich
>> eine ausführbare Datei produziert zu haben, per externem Linken.
>
> Und was steht da zu shared objects? In deinem Ursprungsposting ging es
> WIMRE um eine libc++.so.1. Das ist keine Library.

Das ist irrelevant.
Der Standard nennt selbstverständlich nicht den Namen 'libc++.so.1', sondern
er beschreibt allgemein, wie ich es oben schrieb.

>> Ich habe mit meinem Posting keine Hilfe hier gesucht, sondern ich wollte
>> konzeptionell fehlerhaftes Verhalten beim Linken aufzeigen.
>> Denn es wurde grundlos der Start des grafischen Systems des OS abgebrochen,
>> wegen eines Öffnens einer neuen, fremden Lib mit unbekannten Symbolen, obwohl
>> der Vorgang bereits 'satisfied' war.
>
> Um "konzeptionell fehlerhaftes Verhalten" aufzeigen zu können, sollte
> man das Konzept zuvor verstanden haben.
>

Richtig - ich habe das verstanden, schon in den 1980ern.

/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:...

Vorstehend der Suchpfad für Libraries.
Alle Verlinkungen 'libc++' wurden per /usr/lib/libc++.so.1 vorgenommen.
Es gibt dann keinen Grund mehr, eine weitere libc++.so.1 in /usr/local/lib zu öffnen.

Dies wurde aber gemacht, und alles abgebrochen, weil darin logischerweise
zu neue Versions-Symbole gefunden wurden.
Wozu gibt es denn eine Suchreihenfolge?
Diese kann per LD_LIBRARY_PATH neu bestimmt werden, um gezielt filtern zu können.
Diese gezielte Filterung wird durch das geschilderte Verhalten unterlaufen/ausgehebelt.
Siehe PATH.

[Helmut Schellong]

On 06/16/2023 16:08, Bonita Montero wrote:
> Am 16.06.2023 um 15:34 schrieb Helmut Schellong:
>> On 06/16/2023 14:21, Bonita Montero wrote:
>>> Am 15.06.2023 um 20:14 schrieb Helmut Schellong:
>>>
>>>> Ich schrieb doch, daß die zuvor nicht auf dem Rechner war.
>>>> Jedenfalls nicht in /usr/local/lib.
>>>
>>> Ich glaubs ja eher nicht weil das ja eine wirklich
>>> verbreitete C++ -Runtime unter Linux ist.
>>
>> Du hast offenbar keine der Erklärungen von mir gelesen.
>> Auch nicht mein heutiges Posting.
>> Sie war definitiv nicht in '/usr/local/lib'!
>
> Das glaub ich eben nicht, denn die libc++ wird sicher so häufig durch
> andere Anwedungen genutzt, dass die sowieso schon da sein sollte.

Es gibt /usr/lib/libc++,so.1
Hingegen /usr/local/lib/libc++.so.1 hatte ich durch Kopieren selbst erzeugt.
Hatte ich - sie ist nämlich schon längst wieder weg - und alles läuft.

>> Nein, Inhalt und Name sind irrelevant.
>> Hätte ich den Namen doch nicht genannt, ich Dussel.
>
> Ne, das ist wohl relevant, denn sowas ist i.d.R. sowieso
> schon vorhanden.

Nicht in /usr/local/lib

[Thomas Klix]

Helmut Schellong wrote at Fri, 16 Jun 2023 11:36:42 +0200:
> [...]

> Ich habe mit meinem Posting keine Hilfe hier gesucht, sondern ich wollte
> konzeptionell fehlerhaftes Verhalten beim Linken aufzeigen.

Herr Schellong, da Sie hier allgemein als Koryphäe bekannt sind, war es
Ihnen natürlich ein leichtes, dieses Problem zu lösen.

Thomas

[Stefan Reuther]

Am 16.06.2023 um 17:44 schrieb Helmut Schellong:
> On 06/16/2023 14:16, Enrik Berkhan wrote:
>> Helmut Schellong <r...@schellong.biz> wrote:
>>> Im C-Standard ist das Wort 'Library' ungefähr 500-mal enthalten.
>>> Der Standard beschreibt sogar konkret vorherige Translationsphasen
>>> mit Hilfe
>>> von Einzelobjekten oder zusammengefaßt in Libraries, um schließlich
>>> eine ausführbare Datei produziert zu haben, per externem Linken.
>>
>> Und was steht da zu shared objects? In deinem Ursprungsposting ging es
>> WIMRE um eine libc++.so.1. Das ist keine Library.
>
> Das ist irrelevant. Der Standard nennt selbstverständlich nicht den
> Namen 'libc++.so.1', sondern er beschreibt allgemein, wie ich es oben
> schrieb.

Der Standard bezeichnet als "Library" eine Menge von Funktionen u.a.,
die "linked" werden können. Er trifft keine Aussage darüber, wie diese
Library physisch abgelegt ist, ob das Objektdateien sind, Archive (*.a,
*.lib) oder Shared Libraries (*.so, *.dll), oder ob der Übersetzer sie
einfach bei Bedarf direkt einsetzt.

Und schon gar nicht trifft er eine Aussage darüber, was der Name
"libc++.so.1" bedeutet.

>> Um "konzeptionell fehlerhaftes Verhalten" aufzeigen zu können, sollte
>> man das Konzept zuvor verstanden haben.
>
> Richtig - ich habe das verstanden, schon in den 1980ern.

Die Welt dreht sich weiter.

> /lib:/usr/lib:/usr/lib/compat:/usr/local/lib:...
>
> Vorstehend der Suchpfad für Libraries.
> Alle Verlinkungen 'libc++' wurden per /usr/lib/libc++.so.1 vorgenommen.
> Es gibt dann keinen Grund mehr, eine weitere libc++.so.1 in
> /usr/local/lib zu öffnen.

Zum einen ist deine Fehlerbeschreibung absolut konfus - sie sagt weder,
welches Symbol bemeckert wurde, in welcher Library es zu finden gewesen
wäre, und welche stattdessen benutzt wurde.

Zum anderen gibt es seit längerer Zeit nun schon die Möglichkeit, dass
eine Library einen eigenen Suchpfad für weitere Libraries mitbringt, und
dieser Suchpfad darf auch relativ sein (RPATH, RUNPATH, $ORIGIN). Weiß
man natürlich nicht, wenn man seit 1985 nicht mehr in die Doku geschaut hat.

Und schlussendlich ist der erste Schritt, sowas zu debuggen, das
ldd-Kommando bzw. die LD_TRACE_LOADED_OBJECTS-Umgebungsvariable, ggf.
noch in Verbindung mit LD_BIND_NOW.

Mit C hat das aber alles nichts zu tun.


Stefan

[Helmut Schellong]

Ja, natürlich.
Ich habe die betroffenen 285 Libs vorerst umbenannt.
So werden sie nicht mehr zum Linken herangezogen.
Ich habe die Zeichenfolge 'lib' in 'bil' geändert, schon vor meinem Posten.
Als Skript-Meister kein Problem für mich.

[Helmut Schellong]

On 06/16/2023 19:09, Stefan Reuther wrote:
> Am 16.06.2023 um 17:44 schrieb Helmut Schellong:
>> On 06/16/2023 14:16, Enrik Berkhan wrote:
>>> Helmut Schellong <r...@schellong.biz> wrote:
>>>> Im C-Standard ist das Wort 'Library' ungefähr 500-mal enthalten.
>>>> Der Standard beschreibt sogar konkret vorherige Translationsphasen
>>>> mit Hilfe
>>>> von Einzelobjekten oder zusammengefaßt in Libraries, um schließlich
>>>> eine ausführbare Datei produziert zu haben, per externem Linken.
>>>
>>> Und was steht da zu shared objects? In deinem Ursprungsposting ging es
>>> WIMRE um eine libc++.so.1. Das ist keine Library.
>>
>> Das ist irrelevant. Der Standard nennt selbstverständlich nicht den
>> Namen 'libc++.so.1', sondern er beschreibt allgemein, wie ich es oben
>> schrieb.
>
> Der Standard bezeichnet als "Library" eine Menge von Funktionen u.a.,
> die "linked" werden können.

Ja, das ist der weit überwiegende Teil.

> Er trifft keine Aussage darüber, wie diese
> Library physisch abgelegt ist, ob das Objektdateien sind, Archive (*.a,
> *.lib) oder Shared Libraries (*.so, *.dll), oder ob der Übersetzer sie
> einfach bei Bedarf direkt einsetzt.

Doch, er trifft hierzu Aussagen, wie ich es schrieb.

5.1.1.1 - Aus einem Draft für C23:
A C program need not all be translated at the same time. The text of the program is kept in units
called source files, (or preprocessing files) in this document. A source file together with all the headers
and source files included via the preprocessing directive #include is known as a preprocessing
translation unit. After preprocessing, a preprocessing translation unit is called a translation unit.
Previously translated translation units may be preserved individually or in libraries. The separate
translation units of a program communicate by (for example) calls to functions whose identifiers have
external linkage, manipulation of objects whose identifiers have external linkage, or manipulation
of data files. Translation units may be separately translated and then later linked to produce an
executable program.

Beispielsweise: "units may be preserved individually or in libraries".

Damit sind beispielsweise foo.o und libfu.a gemeint.

> Und schon gar nicht trifft er eine Aussage darüber, was der Name
> "libc++.so.1" bedeutet.
>
>>> Um "konzeptionell fehlerhaftes Verhalten" aufzeigen zu können, sollte
>>> man das Konzept zuvor verstanden haben.
>>
>> Richtig - ich habe das verstanden, schon in den 1980ern.
>
> Die Welt dreht sich weiter.
>
>> /lib:/usr/lib:/usr/lib/compat:/usr/local/lib:...
>>
>> Vorstehend der Suchpfad für Libraries.
>> Alle Verlinkungen 'libc++' wurden per /usr/lib/libc++.so.1 vorgenommen.
>> Es gibt dann keinen Grund mehr, eine weitere libc++.so.1 in
>> /usr/local/lib zu öffnen.
>
> Zum einen ist deine Fehlerbeschreibung absolut konfus - sie sagt weder,
> welches Symbol bemeckert wurde, in welcher Library es zu finden gewesen
> wäre, und welche stattdessen benutzt wurde.

Doch, das habe ich gepostet.
Das Symbol 'FBSD_1.5' in /usr/local/lib/libc++.so.1 wurde als unbekannt angemeckert.
Ich schrieb das mehrfach (von Anfang an).
/usr/lib/libc++.so.1 (Symbol FBSD_1.3) wird nicht angemeckert.

> Zum anderen gibt es seit längerer Zeit nun schon die Möglichkeit, dass
> eine Library einen eigenen Suchpfad für weitere Libraries mitbringt, und

Das weiß ich auch schon lange, weil Fehlermeldungen entsprechend lauten.
Beispielsweise wird libc.so.7 gefordert.
Habe ich das erfüllt, wird etwas Fehlendes für ein Objekt _in_ dieser Lib gefordert.
Habe ich das erfüllt, wird eine falsche Relokationsart angemosert.
Und da hatte ich genug, und ließ diesen Ansatz fallen.

> dieser Suchpfad darf auch relativ sein (RPATH, RUNPATH, $ORIGIN). Weiß
> man natürlich nicht, wenn man seit 1985 nicht mehr in die Doku geschaut hat.
>
> Und schlussendlich ist der erste Schritt, sowas zu debuggen, das
> ldd-Kommando bzw. die LD_TRACE_LOADED_OBJECTS-Umgebungsvariable, ggf.
> noch in Verbindung mit LD_BIND_NOW.
>
> Mit C hat das aber alles nichts zu tun.

Ja, deshalb habe ich auch zu Werkzeugen, wie nm, objdump, etc., nichts gesagt.
Das läßt schließlich auch der Standard außen vor.
Grundlegende Konzepte nennt er aber doch.

[Stefan Reuther]

Am 16.06.2023 um 23:23 schrieb Helmut Schellong:
> On 06/16/2023 19:09, Stefan Reuther wrote:
>> Er trifft keine Aussage darüber, wie diese
>> Library physisch abgelegt ist, ob das Objektdateien sind, Archive (*.a,
>> *.lib) oder Shared Libraries (*.so, *.dll), oder ob der Übersetzer sie
>> einfach bei Bedarf direkt einsetzt.
>
> Doch, er trifft hierzu Aussagen, wie ich es schrieb.
>
> 5.1.1.1 - Aus einem Draft für C23:

> [...]> Beispielsweise:  "units may be preserved individually or in

libraries".
>
> Damit sind beispielsweise foo.o und libfu.a gemeint.

Das mag ja sein.

Aber wie und wo die abgelegt werden, darüber trifft C keine Aussage.

Insbesondere spezifiziert der C-Standard das Verhalten einer
"Implementation" von C ("An implementation translates C source files and
executes C programs"). Er trift keine Aussage darüber, wie zwei
verschiedene C-Implementationen miteinander interoperieren.

>> Zum einen ist deine Fehlerbeschreibung absolut konfus - sie sagt weder,
>> welches Symbol bemeckert wurde, in welcher Library es zu finden gewesen
>> wäre, und welche stattdessen benutzt wurde.
>
> Doch, das habe ich gepostet.
> Das Symbol 'FBSD_1.5' in /usr/local/lib/libc++.so.1 wurde als unbekannt
> angemeckert.

FBSD_1.5 ist mit ziemlicher Sicherheit kein Symbol, sondern die Version
eines Symbols.


Stefan

[Helmut Schellong]

On 06/17/2023 15:26, Stefan Reuther wrote:
> Am 16.06.2023 um 23:23 schrieb Helmut Schellong:
>> On 06/16/2023 19:09, Stefan Reuther wrote:
>>> Er trifft keine Aussage darüber, wie diese
>>> Library physisch abgelegt ist, ob das Objektdateien sind, Archive (*.a,
>>> *.lib) oder Shared Libraries (*.so, *.dll), oder ob der Übersetzer sie
>>> einfach bei Bedarf direkt einsetzt.
>>
>> Doch, er trifft hierzu Aussagen, wie ich es schrieb.
>>
>> 5.1.1.1 - Aus einem Draft für C23:
>> [...]> Beispielsweise:  "units may be preserved individually or in
> libraries".
>>
>> Damit sind beispielsweise foo.o und libfu.a gemeint.
>
> Das mag ja sein.

Das ist so - eine Tatsache.

> Aber wie und wo die abgelegt werden, darüber trifft C keine Aussage.

Natürlich legt der Standard so etwas nicht fest.
Das wäre ja hochgradig dämlich/unpraktikabel.
Jedoch irgendwo an geeigneter Stelle(n) müssen diese Dateien ja residieren.

> Insbesondere spezifiziert der C-Standard das Verhalten einer
> "Implementation" von C ("An implementation translates C source files and
> executes C programs"). Er trift keine Aussage darüber, wie zwei
> verschiedene C-Implementationen miteinander interoperieren.

Warum sollte er das überhaupt definieren?
Ich habe daran keinen Bedarf - und werde nie einen Bedarf haben.

>>> Zum einen ist deine Fehlerbeschreibung absolut konfus - sie sagt weder,
>>> welches Symbol bemeckert wurde, in welcher Library es zu finden gewesen
>>> wäre, und welche stattdessen benutzt wurde.
>>
>> Doch, das habe ich gepostet.
>> Das Symbol 'FBSD_1.5' in /usr/local/lib/libc++.so.1 wurde als unbekannt
>> angemeckert.
>
> FBSD_1.5 ist mit ziemlicher Sicherheit kein Symbol, sondern die Version
> eines Symbols.

Die Fehlermeldung hatte es gezeigt und als Symbol bezeichnet.
(Muß ich ein Foto machen?)
Ich hatte es bisher auch als Versions-Symbol bezeichnet.

hx /usr/local/lib/bilc++.so.1 :
401b+368 44 5f 31 2e 30 00 46 42 53 44 5f 31 2e 31 00 46 D_1.0.FBSD_1.1.F
401b+384 42 53 44 5f 31 2e 33 00 46 42 53 44 5f 31 2e 34 BSD_1.3.FBSD_1.4
401b+400 00 46 42 53 44 5f 31 2e 35 00 6c 69 62 63 2b 2b .FBSD_1.5.libc++
401b+416 2e 73 6f 2e 31 00 00 00 e0 98 0c 00 00 00 00 00 .so.1...........

[Stefan Reuther]

Am 17.06.2023 um 19:01 schrieb Helmut Schellong:
> On 06/17/2023 15:26, Stefan Reuther wrote:
>> Aber wie und wo die abgelegt werden, darüber trifft C keine Aussage.
>
> Natürlich legt der Standard so etwas nicht fest.
> Das wäre ja hochgradig dämlich/unpraktikabel.
> Jedoch irgendwo an geeigneter Stelle(n) müssen diese Dateien ja residieren.

Es ist ja nicht mal gesagt, dass das "Dateien" sein müssen. Eine
C-Implementation kann die Funktionen auch in einem Speicher-Image halten
(wie Smalltalk?), oder in einer Datenbank.

>> Insbesondere spezifiziert der C-Standard das Verhalten einer
>> "Implementation" von C ("An implementation translates C source files and
>> executes C programs"). Er trift keine Aussage darüber, wie zwei
>> verschiedene C-Implementationen miteinander interoperieren.
>
> Warum sollte er das überhaupt definieren?
> Ich habe daran keinen Bedarf - und werde nie einen Bedarf haben.

Doch. Ausgangspunkt dieses Threads ist, dass du Dateien einer
C-Implementation, die Symbolversion "FBSD_1.3" erzeugt, und Dateien
einer C-Implementation, die Symbolversion "FBSD_1.5" erzeugt, gemeinsam
benutzen wolltest.

>>> Doch, das habe ich gepostet.
>>> Das Symbol 'FBSD_1.5' in /usr/local/lib/libc++.so.1 wurde als unbekannt
>>> angemeckert.
>>
>> FBSD_1.5 ist mit ziemlicher Sicherheit kein Symbol, sondern die Version
>> eines Symbols.
>
> Die Fehlermeldung hatte es gezeigt und als Symbol bezeichnet.
> (Muß ich ein Foto machen?)

Ich glaube, die Funktionalität "cut & paste" für Text war bereits 1985,
als du das letzte Mal eine Dokumentation gelesen hast, erfunden.


Stefan

[Helmut Schellong]

On 06/18/2023 10:47, Stefan Reuther wrote:
> Am 17.06.2023 um 19:01 schrieb Helmut Schellong:
>> On 06/17/2023 15:26, Stefan Reuther wrote:
>>> Aber wie und wo die abgelegt werden, darüber trifft C keine Aussage.
>>
>> Natürlich legt der Standard so etwas nicht fest.
>> Das wäre ja hochgradig dämlich/unpraktikabel.
>> Jedoch irgendwo an geeigneter Stelle(n) müssen diese Dateien ja residieren.
>
> Es ist ja nicht mal gesagt, dass das "Dateien" sein müssen. Eine
> C-Implementation kann die Funktionen auch in einem Speicher-Image halten
> (wie Smalltalk?), oder in einer Datenbank.

Das weiß ich; der Standard schreibt ja auch eher von Datenobjekten oder ähnlich.
Aber irgendein Datenbehälter muß es ja sein; kann man ruhig als Datei bezeichnen.

>>> Insbesondere spezifiziert der C-Standard das Verhalten einer
>>> "Implementation" von C ("An implementation translates C source files and
>>> executes C programs"). Er trift keine Aussage darüber, wie zwei
>>> verschiedene C-Implementationen miteinander interoperieren.
>>
>> Warum sollte er das überhaupt definieren?
>> Ich habe daran keinen Bedarf - und werde nie einen Bedarf haben.
>
> Doch. Ausgangspunkt dieses Threads ist, dass du Dateien einer
> C-Implementation, die Symbolversion "FBSD_1.3" erzeugt, und Dateien
> einer C-Implementation, die Symbolversion "FBSD_1.5" erzeugt, gemeinsam
> benutzen wolltest.

Es geht um fehlerhaftes Verhalten.
Der Linkprozeß hätte die Lib mit FBSD_1.5 gar nicht öffnen dürfen.
Weil alle Symbole darin vor Öffnen bereits erfüllt waren.

>>>> Doch, das habe ich gepostet.
>>>> Das Symbol 'FBSD_1.5' in /usr/local/lib/libc++.so.1 wurde als unbekannt
>>>> angemeckert.
>>>
>>> FBSD_1.5 ist mit ziemlicher Sicherheit kein Symbol, sondern die Version
>>> eines Symbols.
>>
>> Die Fehlermeldung hatte es gezeigt und als Symbol bezeichnet.
>> (Muß ich ein Foto machen?)
>
> Ich glaube, die Funktionalität "cut & paste" für Text war bereits 1985,
> als du das letzte Mal eine Dokumentation gelesen hast, erfunden.

Du begreifst nicht, obwohl ich auch das beschrieben habe.

Ich berichtete, daß der grafische Desktop KDE4 mitten im Start
durch die Fehlermeldung _blockiert_ wurde.
Und zwar erschien ein kleines X-Window oben links mit der Fehlermeldung darin.
Weil der Start in .xinitrc vorgenommen wurde.
Ich mußte das Kommando kill in einem anderen Login-Prozeß verwenden, um zu bereinigen.
Nach der Bereinigung war alles futsch.
Man kann da nur ein Foto machen...

[Felix Palmen]

* Helmut Schellong <r...@schellong.biz>:

> Es geht um fehlerhaftes Verhalten.

Behauptung durch hartnäckige Verweigerung, mal eine tatsächliche
Fehlermeldung zu zeigen?

Höchstwahrscheinlich ist es genau umgekehrt, der ganze Krempel in
/usr/local/lib wird natürlich dependencies auf Symbols in Version
@FBSD_1.5 haben. Und dass da vorher nichts war, zumal ja KDE auf einem
FreeBSD System im /usr/local tree installiert ist, ist sehr
unglaubwürdig.

Natürlich wird so die libc++ in /usr/local sowieso nie gefunden, das
ganze Konstrukt KANN nicht funktionieren. Wenn man so ein Gebastel
unbedingt machen will ist der einzig brauchbare Weg, die benötigten Libs
*woanders* abzulegen (NICHT in einem systempfad) und die binaries, die
sie brauchen, zu patchen (z.B. mit patchelf), um den passenden rpath zu
setzen.

> Der Linkprozeß

so museumsreif wie die Software hier (FBSD_1.3? KDE4?)...

Achja, JFTR: Hat mit C so absolut gar nichts zu tun.

--
Dipl.-Inform. Felix Palmen <fe...@palmen-it.de> ,.//..........
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231

[Helmut Schellong]

On 06/18/2023 13:52, Felix Palmen wrote:
> * Helmut Schellong <r...@schellong.biz>:
>> Es geht um fehlerhaftes Verhalten.
>
> Behauptung durch hartnäckige Verweigerung, mal eine tatsächliche
> Fehlermeldung zu zeigen?
>
> Höchstwahrscheinlich ist es genau umgekehrt, der ganze Krempel in
> /usr/local/lib wird natürlich dependencies auf Symbols in Version
> @FBSD_1.5 haben. Und dass da vorher nichts war, zumal ja KDE auf einem
> FreeBSD System im /usr/local tree installiert ist, ist sehr
> unglaubwürdig.
>
> Natürlich wird so die libc++ in /usr/local sowieso nie gefunden, das
> ganze Konstrukt KANN nicht funktionieren. Wenn man so ein Gebastel
> unbedingt machen will ist der einzig brauchbare Weg, die benötigten Libs
> *woanders* abzulegen (NICHT in einem systempfad) und die binaries, die
> sie brauchen, zu patchen (z.B. mit patchelf), um den passenden rpath zu
> setzen.
>
>> Der Linkprozeß
>
> so museumsreif wie die Software hier (FBSD_1.3? KDE4?)...
>
> Achja, JFTR: Hat mit C so absolut gar nichts zu tun.

Richtig, Du treibst es mit Deinem Posting in den OFFtopic-Bereich hinein.
Deshalb will ich auch nichts weiteres dazu sagen.
Das würde die Sache vollends ins OFFtopic treiben.

[Felix Palmen]

* Helmut Schellong <r...@schellong.biz>:

> Richtig, Du treibst es mit Deinem Posting in den OFFtopic-Bereich hinein.

Bittesehr: ><)))°>

[Bonita Montero]

Am 18.06.2023 um 20:51 schrieb Helmut Schellong:

> Richtig, Du treibst es mit Deinem Posting in den OFFtopic-Bereich hinein.
> Deshalb will ich auch nichts weiteres dazu sagen.
> Das würde die Sache vollends ins OFFtopic treiben.

Ne, weil sonst klarer würde, dass Du Quark erzählst.

[Claus Reibenstein]

Helmut Schellong schrieb am 18.06.2023 um 20:51:

> On 06/18/2023 13:52, Felix Palmen wrote:
>
>> Achja, JFTR: Hat mit C so absolut gar nichts zu tun.
>
> Richtig, Du treibst es mit Deinem Posting in den OFFtopic-Bereich hinein.

Dein Ursprungsposting in diesem Thread war bereits off topic. Den Thread
muss man deshalb nicht mehr "in den OFFtopic-Bereich hinein" treiben,
denn da ist er schon von Anfang an.

Gruß
Claus

[Helmut Schellong]

Das läßt sich ja ganz einfach prüfen, indem auf einem System festgestellt wird, ob
es da gleiche Libraries in /usr/lib und /usr/local/lib gibt.

Ich kann die Fehlermeldungen aber nicht sehen, weil eine davon nur mit meinem
alten Röhren-Monitor zu sehen ist, der seit einer Weile weg ist.

Ich arbeite seit Jahren im Blindflug, weil mein 4K-Monitor
den Modus 640x480 nicht anzeigt, sondern z.B. erst ab 1024x768.

Ich sehe von der BIOS-Ausgabe, über Boot-Manager und Login, sowie
Start von KDE4 - nichts!
Ich habe das alles im Kopf auswendig gelernt und durch Aliases unterstützt, um
bis zum Start des grafischen Desktop kommen zu können.

Genau deshalb habe ich nun eine Workstation mit UEFI und GPT gebaut.
Von der jedoch zurzeit die Hauptplatine per RMA weggesandt ist.

So, nun habe ich komplett OFFtopic geschrieben - genau das, was ich nicht wollte.
Dieses OFFtopic wird einem quasi dauernd aufgezwungen.
Und diejenigen, die einem das aufzwingen, meckern, wenn man es dann auch tut.

Ich rechne damit, daß es OFFtopic weitergeht.

[Helmut Schellong]

Nein, der Standard schreibt wörtlich zu dem Thema Verlinkung.

Und ich reagiere nicht weiter auf solche falschen Anwürfe.

[Claus Reibenstein]

Helmut Schellong schrieb am 19.06.2023 um 18:57:

> On 06/19/2023 18:38, Claus Reibenstein wrote:
>
>> Dein Ursprungsposting in diesem Thread war bereits off topic. Den Thread
>> muss man deshalb nicht mehr "in den OFFtopic-Bereich hinein" treiben,
>> denn da ist er schon von Anfang an.
>
> Nein, der Standard schreibt wörtlich zu dem Thema Verlinkung.

Was genau schreibt er denn, was mit Deinem Problem zu tun haben könnte?

> Und ich reagiere nicht weiter auf solche falschen Anwürfe.

Du möchtest ein Programm auf einem bestimmten OS laufen lassen und hast
damit Probleme. Diese Probleme haben aber nichts mit der Sprache C zu
tun, sondern ausschließlich mit der (durch eigenes Verschulden)
verkorksten Laufzeitumgebung auf Deinem System. Genau deshalb ist es
hier in dieser Gruppe, in der es nur um die Sprache C geht, off topic.

Gruß
Claus

[Felix Palmen]

* Claus Reibenstein <crei...@gmail.com>:

> Helmut Schellong schrieb am 19.06.2023 um 18:57:
>> Nein, der Standard schreibt wörtlich zu dem Thema Verlinkung.
>
> Was genau schreibt er denn, was mit Deinem Problem zu tun haben könnte?

Vermutlich verrate ich ziemlich exakt niemandem in dieser Group (außer
natürlich dem OP) etwas "neues", wenn ich das beantworte: Der Standard
beschreibt Compilation Units und die Möglichkeit, diese in Libraries
zusammenzufassen. Der Standard beschreibt *keineswegs* dynamic linker
für shared objects, geschweigedenn das Verhalten des runtime linkers
(inkl. Suchpfade). Also daher nur so zur Vervollständigung.

>> Und ich reagiere nicht weiter auf solche falschen Anwürfe.
>
> Du möchtest ein Programm auf einem bestimmten OS laufen lassen und hast

> damit Probleme. [...]

Und ich würde an dieser Stelle entweder manuelles ignorieren oder
"PLONK" empfehlen: OP hat ganz offensichtlich nicht den Hauch einer
Ahnung von der Programmiersprache(!) "C", also verpasst man nichts.

Ja, muss mich da wohl an der eigenen Nase fassen, denn das war ja auch
schon vor meiner Antwort stark zu vermuten.

Cheers, Felix

[Bonita Montero]

Am 19.06.2023 um 19:44 schrieb Felix Palmen:

> Vermutlich verrate ich ziemlich exakt niemandem in dieser Group (außer
> natürlich dem OP) etwas "neues", wenn ich das beantworte: Der Standard
> beschreibt Compilation Units und die Möglichkeit, diese in Libraries
> zusammenzufassen. Der Standard beschreibt *keineswegs* dynamic linker
> für shared objects, geschweigedenn das Verhalten des runtime linkers
> (inkl. Suchpfade). Also daher nur so zur Vervollständigung.

Das ist aber ne sehr abstrakte Herleitung der Berechtigung, das
Anliegen hier vorzutragen. Ich mein ich find's ja auch nicht
schlimm da sonst eh nix hier stattfindet, aber wenn mans schon
so haarspalterisch sieht, dann geht das eher nicht durch.

> Und ich würde an dieser Stelle entweder manuelles ignorieren oder
> "PLONK" empfehlen: OP hat ganz offensichtlich nicht den Hauch einer
> Ahnung von der Programmiersprache(!) "C", also verpasst man nichts.

Ich versteh nicht wie man da genervt sein soll.
Was machst Du wenn Du echte Probleme im Leben hast ?

[Felix Palmen]

* Bonita Montero <Bonita....@gmail.com>:

> Das ist aber ne sehr abstrakte Herleitung der Berechtigung, das
> Anliegen hier vorzutragen.

Ist es eben gerade NICHT. Sinnentnehmendes Lesen muss schon verdammt
schwierig sein.

> Was machst Du wenn Du echte Probleme im Leben hast ?

Ah, der nächste Kandidat.

[Bonita Montero]

Am 19.06.2023 um 20:28 schrieb Felix Palmen:

> * Bonita Montero <Bonita....@gmail.com>:

>> Das ist aber ne sehr abstrakte Herleitung der Berechtigung,
>> das Anliegen hier vorzutragen.

> Ist es eben gerade NICHT. Sinnentnehmendes Lesen muss schon
> verdammt schwierig sein.

Ne, das ist eben nur deine Interpretation. Wenn man es wirklich
so blöd nimmt, dann belässt man es bei dem Rahmen den der Stan-
dard beschreibt und sagt nicht, dass alles was da gedachterweise
noch dranhängen könnte auch passt.

>> Was machst Du wenn Du echte Probleme im Leben hast ?

> Ah, der nächste Kandidat.

Ja, is doch wahr, Du musst echt Schmerzen haben.

[Peter J. Holzer]

On 2023-06-19 19:02, Bonita Montero <Bonita....@gmail.com> wrote:
> Am 19.06.2023 um 20:28 schrieb Felix Palmen:
>> * Bonita Montero <Bonita....@gmail.com>:
>
>>> Das ist aber ne sehr abstrakte Herleitung der Berechtigung,
>>> das Anliegen hier vorzutragen.
>
>> Ist es eben gerade NICHT. Sinnentnehmendes Lesen muss schon
>> verdammt schwierig sein.
>
> Ne, das ist eben nur deine Interpretation.

Felix muss interpretieren was er selber geschrieben hat?

Hast Du zum Frühstück einen Literaturkritiker verspeist?

hp

[Bonita Montero]

Am 19.06.2023 um 21:31 schrieb Peter J. Holzer:

> Felix muss interpretieren was er selber geschrieben hat?

Ja, darüber hinaus ...