Re: Möglichkeit für neuere libc6 bei stable?
Malte Spiess <debrulz@arcor.de> writes:
> Malte Spiess <debrulz@arcor.de> writes:
>> Jörg Sommer <joerg@alea.gnuu.de> writes:
>>> Malte Spiess <debrulz@arcor.de> wrote:
>>>> Jörg Sommer <joerg@alea.gnuu.de> writes:
>>>>> Malte Spiess <debrulz@arcor.de> wrote:
>>>>>> Malte Spiess <debrulz@arcor.de> writes:
>>>>>>> Jörg Sommer <joerg@alea.gnuu.de> writes:
>>>>>>>> Mir kommt eine verrückte Idee. Ich weiß nicht, ob es klappt, aber hole
>>>>>>>> Dir doch mal das Debian‐Paket für libc6 und libgcc1 (Abhängigkeit von
>>>>>>>> libc6) aus testing und speichere alle Dateien aus /lib und /usr/lib aus
>>>>>>>> den Paketen in ein Verzeichnis /…/neue-libc6. Dann starte Dein Programm
>>>>>>>> mal mit LD_LIBRARY_PATH=/…/neue-libc6. Sollte das nicht klappen, dann
>>>>>>>> starte Dein Programm mal mit
>>>>>>>>
>>>>>>>> LD_LIBRARY_PATH=/…/neue-libc6 /…/neue-libc6/ld.so.1 /…/programm
>>>>>>>
>>>>>>> Das wäre natürlich einfacher, werde ich auf jeden Fall mal probieren!
>>>>>>
>>>>>> Leider kommt danach bei Programmaufrufen ein Speicherzugriffsfehler...
>>>>>
>>>>> Bei welchen Programmaufrufen? Startet Dein Programm noch anderer
>>>>> Programme?
>>>>
>>>> Nein, das nicht. Aber alle Programme, die ich aufrufe, z. B.:
>>>> df, ls, more, less, top,...
>>>> und auch das gewünschte Programm
>>>> ,----
>>>>| mspiess@helios:~$ export LD_LIBRARY_PATH=/opt/lib/
>>>
>>> Wo habe ich was von export geschrieben? Natürlich fliegen Dir dann alle
>>> Programme um die Ohren. Deshalb habe ich auch nicht export
>>> geschrieben.
>>
>> Es tut mir Leid, ich bin halt nicht so der Experte. Aber ich sehe
>> zwischen den zwei Vorgehensweisen keinen Unterschied. :-(
>> So wie ich das sehe setzt man einmal die Variable für die bash-Session
>> und das andere Mal nur für das Programm, oder?
>>
>>> Lies mal die Manualpage ld.so(8).
>>
>> Auch die Lektüre ist nicht sehr erhellend. Der Effekt ist jedenfalls
>> derselbe (wenn ich nicht wieder was falsch gemacht habe):
>> ,----
>> | mspiess@helios:~$ LD_LIBRARY_PATH=/opt/lib/ /usr/bin/less
>> | Speicherzugriffsfehler
>> | mspiess@helios:~$ LD_LIBRARY_PATH=/opt/lib/ /bin/ls
>> | Speicherzugriffsfehler
>> `----
>
> Kleine Anmerkung noch:
>
> Mit Deinem zweiten Vorschlag klappt es tatsächlich mit manchen
> Programmen:
> LD_LIBRARY_PATH=/opt/lib/ /opt/lib/ld-linux-x86-64.so.2 /bin/ls
> funktioniert z. B.
> Bei anderen kommt aber:
> [Beispiel mit df unter falschem Pfad]
Sorry, df hat natürlich einen anderen Pfad! Insofern konnte das
natürlich nicht funktionieren...
Hier ein sinnvolles Beispiel - ich muss aber zugeben, dass ich erst
lange suchen musste, es tut fast immer!
,----
| mspiess@helios:~$ LD_LIBRARY_PATH=/opt/lib/ /opt/lib/ld-2.7.so /usr/bin/R
| /usr/bin/R: error while loading shared libraries: /usr/bin/R: invalid ELF header
| mspiess@helios:~$ LD_LIBRARY_PATH=/opt/lib/ /opt/lib/ld-linux-x86-64.so.2 /usr/bin/R
| /usr/bin/R: error while loading shared libraries: /usr/bin/R: invalid ELF header
`----
Ich vermute, es liegt daran:
,----
| mspiess@helios:~$ file /bin/df
| /bin/df: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
| mspiess@helios:~$ file /usr/bin/R
| /usr/bin/R: Bourne shell script text executable
`----
Das Problem ist dann wohl nur noch:
,----
| mspiess@helios:~$ file /home/mspiess/Avizo5/bin/Avizomain
| /home/mspiess/Avizo5/bin/Avizomain: Bourne shell script text executable
`----
Da werde ich mich wohl noch durch das Skript kämpfen müssen...
Sorry nochmal
Ingrid
Reply to: