[freeBSD] Pb avec libpthread

qd je tente d'installer zope, ou de démarrer Mozilla, j'ai droit à un
message d'erreur au sujet de libpthread: "libpthread.so.0 not found".
Mais je croyais que cette lib faisait partie du système de base?

Quelle version de FreeBSD as-tu ?

J'utilise le système de ports, si cette lib est nécessaire comment se
fait-il qu'elle ne soit pas installer avec les prog qui la nécessitent?
Merci de vos lumières.

Elle est installé par le systeme de base (make build/installworld) dans
/usr/src. Elle est la depuis FreeBSD 5.3, je crois qu'elle s'appelait
libkse avant, donc, tu peux jouer avec libmap.conf pour faire ce que tu
veux:

(Note si ca t'interesse, il faut utiliser libc_r pour pouvoir utiliser
le debuggueur java).

# Utiliser libc_r pour debugguer du JAVA
# ------------------------------
libc_r.so.5 libpthread.so.1
libc_r.so libpthread.so
#libpthread.so.1 libc_r.so.5
#libpthread.so libc_r.so
libkse.so libpthread.so
libkse.so.1 libpthread.so.1
#libpthread.so libkse.so
#libpthread.so.1 libkse.so.1

A toi de voir ce que tu veux activer... (en gros commenter les lignes
que j'ai et décommenter un des deux groupes commentés).

--
Nicolas Le Scouarnec

Elle est installé par le systeme de base (make build/installworld) dans
/usr/src. Elle est la depuis FreeBSD 5.3, je crois qu'elle s'appelait
libkse avant, donc, tu peux jouer avec libmap.conf pour faire ce que tu
veux:

(Note si ca t'interesse, il faut utiliser libc_r pour pouvoir utiliser
le debuggueur java).

# Utiliser libc_r pour debugguer du JAVA
# ------------------------------
libc_r.so.5 libpthread.so.1
libc_r.so libpthread.so
#libpthread.so.1 libc_r.so.5
#libpthread.so libc_r.so
libkse.so libpthread.so
libkse.so.1 libpthread.so.1
#libpthread.so libkse.so
#libpthread.so.1 libkse.so.1

A toi de voir ce que tu veux activer... (en gros commenter les lignes
que j'ai et décommenter un des deux groupes commentés).

J'ai freeBSD5.3.
Et j'ai aussi les libpthread et libkse.
J'essaie donc libmap.conf.
Merci.

libc_r.so.5 libpthread.so.1
libc_r.so libpthread.so
#libpthread.so.1 libc_r.so.5
#libpthread.so libc_r.so
libkse.so libpthread.so
libkse.so.1 libpthread.so.1
J'ai freeBSD5.3.

Normalement, alors, tu dois utiliser libpthread pour tout, donc
utiliser un fichier de config semblable au miens.

Et j'ai aussi les libpthread et libkse.

Ils sont bien présent dans /usr/lib ?

J'essaie donc libmap.conf.

Ca m'étonnerai que ca marche si les fichiers existe bien, l'erreur doit
etre ailleurs.

Pour Mozilla, j'ai la meme erreur, cependant, cette erreur vient du
chargement du plugin FlashPlayer 7 qui est prévu pour Linux.

--
Nicolas Le Scouarnec

Nicolas Le Scouarnec wrote:

qd je tente d'installer zope, ou de démarrer Mozilla, j'ai droit à un
message d'erreur au sujet de libpthread: "libpthread.so.0 not found".
Mais je croyais que cette lib faisait partie du système de base?

Quelle version de FreeBSD as-tu ?

J'utilise le système de ports, si cette lib est nécessaire comment se
fait-il qu'elle ne soit pas installer avec les prog qui la nécessitent?
Merci de vos lumières.

Elle est installé par le systeme de base (make build/installworld) dans
/usr/src. Elle est la depuis FreeBSD 5.3, je crois qu'elle s'appelait
libkse avant, donc, tu peux jouer avec libmap.conf pour faire ce que tu
veux:

(Note si ca t'interesse, il faut utiliser libc_r pour pouvoir utiliser
le debuggueur java).

# Utiliser libc_r pour debugguer du JAVA
# ------------------------------
libc_r.so.5 libpthread.so.1
libc_r.so libpthread.so
#libpthread.so.1 libc_r.so.5
#libpthread.so libc_r.so
libkse.so libpthread.so
libkse.so.1 libpthread.so.1
#libpthread.so libkse.so
#libpthread.so.1 libkse.so.1

A toi de voir ce que tu veux activer... (en gros commenter les lignes
que j'ai et décommenter un des deux groupes commentés).

Echec complet.

Mon libmap.conf:
# /etc/libmap.conf
#
# candidate mapping
#
libpthread.so.1 libpthread.so.1 # Everything uses 'libpthread'
libpthread.so libpthread.so

libc_r.so.5 libpthread.so.1 # Everything that uses 'libc_r'
libc_r.so libpthread.so # now uses 'libpthread'

[/tmp/mplayer] # Test version of mplayer uses libc_r
libpthread.so.1 libc_r.so.5
libpthread.so libc_r.so

[mplayer] # All other mplayers use libpthread
libpthread.so.1 libpthread.so.1
libpthread.so libpthread.so

[/usr/local/jdk1.4.1/] # All Java 1.4.1 programs use libthr
# This works because "javavms" executes
# programs with the full pathname
libpthread.so.1 libthr.so.1
libpthread.so libthr.so

libkse.so libpthread.so
libkse.so.1 libpthread.so.1

Y a-t'il une erreur?
Flashplayer cherche encore libpthread.so.0, qui est ds
/usr/compat/linux/lib.
Frustrant.

# /etc/libmap.conf
#
# candidate mapping
#
libpthread.so.1 libpthread.so.1 # Everything uses 'libpthread'
libpthread.so libpthread.so

C'est bon ca ? Commente le, pour voir.

libc_r.so.5 libpthread.so.1 # Everything that uses 'libc_r'
libc_r.so libpthread.so # now uses 'libpthread'

Ok.

[/usr/local/jdk1.4.1/] # All Java 1.4.1 programs use libthr
# This works because "javavms" executes
# programs with the full pathname
libpthread.so.1 libthr.so.1
libpthread.so libthr.so

libthr et libc_r, ce sont les memes ?

libkse.so libpthread.so
libkse.so.1 libpthread.so.1

Mets ca en haut plutot. Avant le premier [...]

Y a-t'il une erreur?
Flashplayer cherche encore libpthread.so.0, qui est ds
/usr/compat/linux/lib.

Pour flashplayer, il faut utiliser le wrapper qui est dans les ports et
lire le pkg-message, je crois.


--
Nicolas Le Scouarnec

According to Nicolas Le Scouarnec <nlsn+news+nospam_invalid@free.fr>:

libthr et libc_r, ce sont les memes ?

Non. Il y a _trois_ bibliothèques de threads Posix dans FreeBSD.

Explications :


** Sous FreeBSD 4.x et précédents, le noyau ne connaît que les
processus, pas les threads. Chaque processus vit dans son propre espace
mémoire. Les threads sont implémentés entièrement en userland, sans
en souffler mot au noyau. L'implémentation repose sur des changements
de contexte "à la main" (il suffit, au fond, de recharger quelques
registres, notamment pour changer de pile, et de faire un saut au
bon endroit). Pour que les threads gardent leur aspect préemptif
(c'est-à-dire que si un thread part dans un gros calcul, les autres
tournent encore), un signal (SIGALRM) est lancé périodiquement.

Cette méthode "userland" suppose qu'aucun appel signal bloquant n'est
fait (si un thread fait un tel appel, ça bloque le processus, donc
tous les threads, puisque le noyau ne voit qu'un processus et pas de
threads). Tous les appels système bloquants doivent donc être détournés
et émulés, en les transformant en interne en appels non bloquants et en
embrayant sur le gestionnaire local de threads pour bloquer le thread
seul. Dans les faits, ça prend la forme d'un remplacement de la libc, à
savoir la libc_r.


** La méthode de la libc_r n'est pas satisfaisante sur certains points :

-- Une bibliothèque est linké avec soit la libc, soit la libc_r, ce
qui fait qu'une bibliothèque donnée ne peut être utilisée en théorie
qu'avec soit les programmes multi-threadés, soit les programmes
mono-threadés. Dans la pratique, on peut truander, parce que les ABI
de la libc et de la libc_r sont quasiment identiques, mais ça suppose
de faire gaffe, notamment dans la gestion des NEEDED dans les .so.
Apparemment, sous OpenBSD (où le même problème se pose), ils ont
décidé d'utiliser la libc_r systématiquement.

-- Comme le noyau ne voit qu'un seul processus, sur une machine SMP,
le processus n'est que sur un processeur à la fois. Donc les threads
tournent sur le même processeur, laissant les autres inoccupés.

-- La libc_r est pénible à maintenir parce qu'il faut être exhaustif :
_tous_ les appels système bloquant doivent être détournés et émulés.
Cela signifie que si un nouvel appel est rajouté dans le noyau, il
faut rajouter le code correspondant dans la libc_r. L'aspect unifié
des BSD rend la chose possible (le noyau et la libc sont mis à jour
en même temps, de façon synchrone) mais pas forcément facile.

Aussi, il a été décidé de faire mieux. Le modèle choisi est dit "N:M" ;
c'est le modèle le plus compliqué mais aussi le plus puissant. L'idée
est que le noyau aura connaissance de N entités (des entrées dans une
sorte de table de processus, en gros) et que la bibliothèque de threads
partagera ces N entités sur M threads. Les entités noyau sont appelées
"KSE" (pour "Kernel Scheduling Entity") et sont décrites dans le man
kse(2). La bibliothèque qui fait tout ça est la "libpthread", qui est
maintenant la bibliothèque de threads par défaut dans FreeBSD (5.3).
La libpthread s'appelait "libkse" pendant sont développement.


** La libpthread a été un peu longue à mettre au point ; pour servir
de prototype et de plateforme d'essai, il a aussi été programmé une
bibliothèque plus simple, faisant le modèle "N:1" : chaque thread est la
transcription directe d'une entité du noyau, qui prend en charge tout
le scheduling. On peut alors voir les threads comme des processus qui
s'avèrent partager le même espace mémoire. Le modèle "N:1" est moins
bon que le "N:M" pour les fortes charges, mais il est quand même décent
(i.e., on ne voit pas la différence sur une machine personnelle) et il
est nettement plus facile à mettre au point (pour info, Linux tourne
avec le modèle N:1, alors que Solaris fait du N:M depuis une bonne
décennie au moins).

Cette bibliothèque intermédiaire s'appelle la "libthr".


** La libc_r existe encore, pour pouvoir lancer les binaires compilés
sur des FreeBSD 5.x anciens (genre 5.1). La libc est, quant à elle, au
courant de l'existence des threads, c'est-à-dire qu'elle contient des
appels aux fonctions telles que pthread_mutex_lock() afin de rendre
des choses comme malloc() thread-safes. Elle contient également des
implémentations de ces fonctions qui ne font rien, déclarées en tant que
"weak symbols". Ceci veut dire que si le programme est mono-threadé,
il n'est pas lié à la libpthread et le surcoût est négligeable ; en
revanche, si le programme est multi-threadé, il est lié à la libpthread
(ou la libthr) dont les implémentations remplacent automatiquement
les fausses implémentations de la libc (magie de l'édition de liens
dynamique) et la libc devient alors thread-safe, et tout marche. Ce qui
était le but recherché.



En résumé :

-- En théorie, on peut remplacer la libpthread par la libthr et
réciproquement, sauf pour des binaires qui font des choses un peu
louches, ou au moins ont besoin de contrôler très finement ce qui se
passe au niveau du scheduling (c'est le cas d'une JVM, à cause des
interactions entre les threads et le garbage collector), auquel cas il
veut mieux conserver la bibliothèque prévue pour (celle utilisée à la
compilation -- chez moi, la JVM est linkée avec la libpthread et s'en
porte très bien).

-- En pratique, on peut forcer l'utilisation de la libc + libpthread
à un programme qui attend la libc_r, et réciproquement, mais c'est "à
la hussarde" et je ne conseille pas. Des bugs peuvent apparaître là où
l'ABI ne correspond pas exactement.

-- Cette histoire de threads est la raison majeure pour laquelle j'ai,
personnellement, attendu les 5.3-BETA pour passer mes machines à FreeBSD
5.x : je voulais que tous les packages s'installent avec la nouvelle
libpthread, plutôt que d'avoir des binaires liés avec la libthr ou la
libc_r et de devoir faire une transition à coups de libmap.conf. Bon,
j'ai quand même dû me payer ça avec le changement de version de libm,
mais c'est une autre histoire.

-- Le plugin Flash 6 pour Mozilla est en fait un plugin Linux,
qui référence les bibliothèques Linux avec l'ABI Linux. Le port
linuxpluginwrapper installe des bibliothèques de conversion qui
s'occupent de faire croire au plugin qu'il y a bien du Linux en dessous,
mais sans l'artillerie de l'émulation Linux générique car le plugin
doit être chargé dans l'espace mémoire du Mozilla, donc avec la libc de
FreeBSD et tout le reste. Heureusement, un plugin est par essence assez
disjoint du système (il parle au browser web plus qu'à l'OS) et comme
le format des bibliothèques partagées est le même sous Linux et sous
FreeBSD (c'est du ELF), cette magouille passe. Il reste néanmoins que
le plugin Flash référence (avec un entête ELF "NEEDED") une bibliothèque
sous le nom de "libpthread.so.0" qu'il faut rediriger, non pas sur
la libpthread de FreeBSD directement (l'ABI n'est pas la même) mais
sur le wrapper. Aussi, j'ai ça dans mon libmap.conf :

# Flash6 with Mozilla/Firebird/Galeon/Epiphany
[/usr/local/lib/linux-flashplugin6/libflashplayer.so]
libpthread.so.0 pluginwrapper/flash6.so
libdl.so.2 pluginwrapper/flash6.so
libz.so.1 libz.so.2
libstdc++-libc6.2-2.so.3 libstdc++.so.4
libm.so.6 libm.so.2
libc.so.6 pluginwrapper/flash6.so

et ça marche. On voit à gauche les référence linuxienne du .so, à droite
les remplacements fournis. C'est un gros hack mais il s'avère que ça
tourne et c'est un peu tout ce qu'on lui demande.



--Thomas Pornin

À (at) Wed, 1 Dec 2004 08:43:29 +0000 (UTC),
pornin@nerim.net (Thomas Pornin) écrivait (wrote):
[... des explications très complètes sur l'historique de libthread & Co...]
[... et sur l'état actuel et les éventuels problèmes restants...]

-- Cette histoire de threads est la raison majeure pour laquelle j'ai,
personnellement, attendu les 5.3-BETA pour passer mes machines à FreeBSD
5.x : je voulais que tous les packages s'installent avec la nouvelle
libpthread, plutôt que d'avoir des binaires liés avec la libthr ou la
libc_r et de devoir faire une transition à coups de libmap.conf. Bon,
j'ai quand même dû me payer ça avec le changement de version de libm,
mais c'est une autre histoire.

Pour ceux qui, comme moi, n'ont pas su attendre la 5.3 et se retrouvent avec
des ports datant d'une 5.2 (ou plus vieux) qu'il faut à mettre à jour pour ne
plus avoir de dépendances sur libm.so.2 et libc_r.so, je peux fournir un petit
script Perl qui fournit la liste des ports à mettre à jour et surtou l'ordre
où il faut les recompiler. C'est du bricolage vite fait mais ça m'a bien
dépanné.

[/usr/local/lib/linux-flashplugin6/libflashplayer.so]
libpthread.so.0 pluginwrapper/flash6.so
libdl.so.2 pluginwrapper/flash6.so
libz.so.1 libz.so.2
libstdc++-libc6.2-2.so.3 libstdc++.so.4
libm.so.6 libm.so.2
libc.so.6 pluginwrapper/flash6.so

et ça marche. On voit à gauche les référence linuxienne du .so, à droite
les remplacements fournis. C'est un gros hack mais il s'avère que ça
tourne et c'est un peu tout ce qu'on lui demande.

Savez-vous si une manip similaire est nécessaire et/ou peut fonctionner pour
le plugin flash de firefox ?

Pour l'instant, j'ai mis ce plugin de côté car tel que je l'installe, il
plante systématiquement firefox dès qu'on charge du flash. En revanche, java
fonctionne à merveille.

En tous cas, merci pour ces explications.

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>

-- Une bibliothèque est linké avec soit la libc, soit la libc_r, ce
qui fait qu'une bibliothèque donnée ne peut être utilisée en théorie
qu'avec soit les programmes multi-threadés, soit les programmes
mono-threadés. Dans la pratique, on peut truander, parce que les ABI
de la libc et de la libc_r sont quasiment identiques, mais ça suppose
de faire gaffe, notamment dans la gestion des NEEDED dans les .so.
Apparemment, sous OpenBSD (où le même problème se pose), ils ont
décidé d'utiliser la libc_r systématiquement.

Non, OpenBSD utilise des symboles faibles dans libc, afin que si
libpthread entre en jeu, tout le monde utilise du code MT-safe. libc_r
n'existe plus.

Thomas Pornin wrote:

# Flash6 with Mozilla/Firebird/Galeon/Epiphany
[/usr/local/lib/linux-flashplugin6/libflashplayer.so]
libpthread.so.0 pluginwrapper/flash6.so
libdl.so.2 pluginwrapper/flash6.so
libz.so.1 libz.so.2
libstdc++-libc6.2-2.so.3 libstdc++.so.4
libm.so.6 libm.so.2
libc.so.6 pluginwrapper/flash6.so

et ça marche.

Pas chez moi.
Merci beaucoup pour vos explications. Je commence à m'intéresser aux OS,
quand la FMC me laisse le temps, et j'en apprends tous les jours, ici.

According to Paul Gaborit <Paul.Gaborit+news@enstimac.fr>:

pornin@nerim.net (Thomas Pornin) écrivait (wrote):

[/usr/local/lib/linux-flashplugin6/libflashplayer.so]
libpthread.so.0 pluginwrapper/flash6.so
libdl.so.2 pluginwrapper/flash6.so
libz.so.1 libz.so.2
libstdc++-libc6.2-2.so.3 libstdc++.so.4
libm.so.6 libm.so.2
libc.so.6 pluginwrapper/flash6.so

et ça marche. On voit à gauche les référence linuxienne du .so, à droite
les remplacements fournis. C'est un gros hack mais il s'avère que ça
tourne et c'est un peu tout ce qu'on lui demande.

Savez-vous si une manip similaire est nécessaire et/ou peut fonctionner pour
le plugin flash de firefox ?

À ma connaissance, c'est nécessaire aussi pour Firefox, et par ailleurs
ça marche sur ma machine de bureau, qui est en 5.3 avec Firefox.

En fait c'est assez indépendant du browser web. Les plugins sont censés
être partagés entre tous les browsers web qui fournissent l'API qui va
bien (globalement un accès graphique, qui se retrouve intégré dans la
page web, et des fonctions d'aide pour ne pas marcher sur les pieds du
browser) ; dans les faits, ça concerne Netscape, Mozilla et ses dérivés.
Les plugins sont ensuite référencés dans /usr/X11R6/lib/browser_plugins/
sous la forme de liens symboliques. Chez moi j'ai ça :

flashplayer.xpt -> /usr/local/lib/linux-flashplugin6/flashplayer.xpt
libflashplayer.so -> /usr/local/lib/linux-flashplugin6/libflashplayer.so
libjavaplugin_oji.so -> /usr/local/jdk1.4.2/jre/plugin/i386/ns610/libjavaplugin_oji.so

Je ne sais pas au juste quelle est la distinction entre le .xpt et le
.so, mais j'ai les deux et dans les faits ça marche avec Mozilla et avec
Firefox. Le troisième lien est pour Java. Il y avait aussi un lien vers
le nppdf.so, le plugin d'Adobe pour afficher du PDF, mais je l'ai viré
parce que je préfère télécharger les PDF eux-mêmes, quitte à lancer un
viewer externe (Acrobat Reader est plus rapide que le plugin équivalent,
je ne sais pas pourquoi au juste mais je le constate).


--Thomas Pornin