Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"GLIBC_2.28 et 2.29 not found" dans les dernières compilations Geneweb-linux #1272

Open
rpo opened this issue Jan 3, 2022 · 19 comments
Open
Labels
Bug Feature: Approved A feature-wish that has been accepted by project owners.

Comments

@rpo
Copy link

rpo commented Jan 3, 2022

Dans les derniers release Geneweb-linux, depuis celui du 26 octobre 2021 [Geneweb-587d63db ] l'exécution de gwd résulte en cette erreur :

/lib64/libm.so.6: version `GLIBC_2.29' not found (required by ./gwd)

ainsi que celle-ci:

/lib64/libc.so.6: version `GLIBC_2.28' not found (required by ./gwd) 

Toutes les autres distribution linux avant le 26 octobre sont correctes n'apportant pas ces erreurs à l'exécution de gwd. (la version officielle geneweb-linux-88536ed4 est aussi correcte). Ces librairies auraient été oubliées d'être incluses dans la compilation ?

@rpo rpo changed the title [BUG] "GLIBC_2.28 et 2.29 not found" dans les dernières compilations Geneweb-linux "GLIBC_2.28 et 2.29 not found" dans les dernières compilations Geneweb-linux Jan 4, 2022
@sagotch
Copy link
Contributor

sagotch commented Jan 4, 2022

Je suppose qu'il y a eu un changement d'environnement dans le CI et/ou sur votre distrib et que du coup la version de la lib C doit être augmenté sur la machine hôte.

Alternativement, il est peut-être possible d'installer une version anterieur dans le script appveyor.

@hgouraud
Copy link
Collaborator

hgouraud commented Jan 4, 2022

Si je lis correctement les commentaires sur le Web, cela voudrait dire que la version redHat sur laquelle tu exécutes gwd n'est pas "à jour" pour GLIBC!
Deux solutions :

  • mettre à jour redHat
  • compiler GeneWeb avec "l'ancienne" version de GLIBC et produire une version spécifique pour cet environnement!

@rpo
Copy link
Author

rpo commented Jan 4, 2022

Merci - J'opère avec Rapidnet.ca - Version Linux RedHat Entreprise 8.5 5-44 GCC - la dernière version commerciale disponible - Je vais m'informer auprès d'eux.

@rpo
Copy link
Author

rpo commented Jan 4, 2022

Un premier appel chez Rapidnet et on me dit que ces deux librairies sont des 'codes rouges' chez-eux (parce que considérées vulnérables) - [Peut-être qu'elles n'étaient pas requises avant la compilation avec le nouveau plugin?] - Toujours est-il qu'on cherche une façon sécuritaire de les inclure à mon environnement linux. A suivre.

@rpo
Copy link
Author

rpo commented Jan 5, 2022

Voici la réponse reçue de Rapidnet.

GLIBC_2.28 [& 2.29] = non disponible pour centos7 en serveur mutualisé

GLIBC_2.28 [& 2.29] = disponible de base pour centos8 qui n'est dorénavant plus une version stable. Il faut maintenant utiliser almalinux.org au lieu de centos8

Demandez à votre créateur d'application Geneweb de compiler le programme pour centos7 sur GLIBC_2.17.
Sinon dans le pire des cas je pourrai vous monter un serveur dédié [avec des frais] sur l'équivalent de centos8 avec GLIBC_2.28 - mais reconnu non stable commercialement.

Sinon aussi, je peux vous faire un VPS avec Almalinux à 50$ par mois environ

========================================

Je constate donc que quelque part en septembre ou octobre 2021 votre façon de compiler la distribution linux a changé en demandant appel à GLIBC_2.28 [& 2.29] car avant cette date la demande de ces librairies ne se produit pas à l'exécution de gwd.
Ça concerne mon cas mais aussi possiblement tous ceux qui voudront dorénavant utiliser Geneweb en serveur mutualisé..

Je ne sais pas si la proposition faite par Rapidnet de compiler le programme Geneweb linux pour centos7 sur GLIBC_2.17 plutôt qu'avec GLIBC_2.28 est raisonnable pour vous? Ça éviterait bien des problèmes d'utilisation- merci

@sagotch
Copy link
Contributor

sagotch commented Jan 6, 2022

Je pense qu'il n'y a pas de problème à se baser sur une lib C un peu datée (ce qui reste à tester). Il faut voir comment configurer le CI pour faire cela.

@hgouraud
Copy link
Collaborator

hgouraud commented Jan 6, 2022 via email

@rpo
Copy link
Author

rpo commented Jan 6, 2022

Le prix des com est exhorbitant au Canada. L'arrangement avec GLIBC 2.28 peut se faire à moindre coût mais ils ne vont pas alors supporter les backup, front installations etc.

Par ailleurs on remarque que GLIBC 2.28 et + pose un réel problème un peu partout sur les installations : (recherche Google de: 'GLIBC 2.28 unsupported' ) et pas seulement pour RedHat!

Donc si c'est possible de se baser sur la lib c 2.17 cela éviterait bien des problèmes aux utilisateurs j'imagine. Le dernier release officiel de Geneweb offert sur la page Download et les tags jusqu'en septembre ne posent pas ce problème de librairie.

@rpo
Copy link
Author

rpo commented Jan 20, 2022

Je pense qu'il n'y a pas de problème à se baser sur une lib C un peu datée (ce qui reste à tester). Il faut voir comment configurer le CI pour faire cela.

Vous avez p-e changé l'environnement à une certaine date car jusqu'en septembre 2021 c'est bon. Peut-être aussi que GLC 2.28 n'est pas vraiment nécessaire pour la compilation et faudrait enlever la demande ? Toujours est-il qu'aucun serveur RedHat / Centos commercial pourtant à date ne peut faire fonctionner tel quel les dernières moutures de Geneweb :-]

@a2line
Copy link
Collaborator

a2line commented Jan 20, 2022

Ce n'est pas un choix. Les librairies se mettent à jour toutes seules : les CI prennent les plus récentes et la release est générée par ce dernier. Comme expliqué plus haut, il n'y a probablement aucun problème à compiler avec la version 2.17. Mais pour aller plus loin, j'ai envie d'ajouter que le serveur Geneweb distant n'a pas non plus besoin de l'environnement de compilation du tout. C'est comme installer GeneWeb déjà compilé chez soi quelque soit le système d'exploitation. La compilation avec un Glibc 2.17 peut donc être faite sur une machine physique ou virtuelle avec un OS identique au serveur et il suffira ensuite d'utiliser cette compilation là. Il n'y a pas d’ailleurs pas le choix pour les machines mutualisées où l'on n'a pas accès au root (par exemple la démo GeneWeb 7 tourne chez Tuxfamily sur Debian avec seulement gwd.exe dans le dir et le script cgi… elle n'a jamais compilé GeneWeb).

@rpo
Copy link
Author

rpo commented Jan 20, 2022

Ce n'est pas un choix. Les librairies se mettent à jour toutes seules : les CI prennent les plus récentes et la release est générée par ce dernier. Comme expliqué plus haut, il n'y a probablement aucun problème à compiler avec la version 2.17. Mais pour aller plus loin, j'ai envie d'ajouter que le serveur Geneweb distant n'a pas non plus besoin de l'environnement de compilation du tout. C'est comme installer GeneWeb déjà compilé chez soi quelque soit le système d'exploitation. La compilation avec un Glibc 2.17 peut donc être faite sur une machine physique ou virtuelle avec un OS identique au serveur et il suffira ensuite d'utiliser cette compilation là. Il n'y a pas d’ailleurs pas le choix pour les machines mutualisées où l'on n'a pas accès au root (par exemple la démo GeneWeb 7 tourne chez Tuxfamily sur Debian avec seulement gwd.exe dans le dir et le script cgi… elle n'a jamais compilé GeneWeb).

J'utilise bien gwd déjà compilé pris sur les Releases ou Tags Geneweb , exécuté sur un serveur mutualisé RedHat/Centos dernière version stable. Jusqu'aux environs de septembre 2021 gwd s'exécute sans 'erreur' - à partir d'octobre 2021 environ l'exécution demande les librairies 2.28 et 2.29 et ferme. Pourquoi gwd demande-t-il ces librairies si déjà compilé?

@a2line
Copy link
Collaborator

a2line commented Jan 20, 2022

Je sais qu'on a eu un problème un peu similaire de dll sous Windows l'an dernier. Je vois que https://fr.wikipedia.org/wiki/GNU_C_Library est en version 2.34 stable depuis août 2021 et que la 2.35 est prévue pour dans deux semaines. Cette version 2.29 (décrite comme dangereuse) est de janvier 2019 et je me dis que les problèmes ont pu être corrigés en 6 versions. Ne faudrait-il pas voir le problème à l'envers : plutôt que revenir en 2.17, inciter l'hébergeur à monter en version pour éviter ce « danger » qu'ils craignent ?

@rpo
Copy link
Author

rpo commented Jan 25, 2022

OK - je devrais avoir une mise à jour sur le serveur avec les lib 2.28 et 2.29 et + d'ici deux mois, toujours sur Centos mais version 8. Je vais patienter jusque là - merci. [actuellement 90% des serveurs mutualisés au Canada sont sur Centos 7 sans 2,28-2.29 c'est ce qu"on me dit ! ]

@a2line
Copy link
Collaborator

a2line commented Apr 14, 2023

Est-ce que cette librairie pose toujours problème 14 mois plus tard ?

@rpo
Copy link
Author

rpo commented Apr 14, 2023 via email

@grocanar
Copy link

a priori sur un train de version CentOS on va reste sur la version 2.17 de la glibc.
Passez en glibc2.28 implique de passer en Rocky8 ou alamlinux meme version ou RHEL8.
le principe est de rester compatible binaire tant qu'on ne change pas de version majeure.

@rpo
Copy link
Author

rpo commented Apr 15, 2023 via email

@TitiFix
Copy link
Contributor

TitiFix commented Sep 2, 2023

Bonjour,
Effectivement lorsque je regarde les distributions ce sont des exécutables avec des liens dynamiques (*). On voit que les versions minimales nécessaires (avec ldd -v gw/gwd |sort|grep GLIBC) sont :

  • pour la version 7.00 d'octobre 2020 (dernière publiée) : libc.so.6 >= GLIBC_2.17
  • pour la dernière version 7.01 alpha (en cours mise au point) : libm.so.6 >= GLIBC_2.35

Ce ne semble pas lié à la version d'OCAML mais à la version d'OS pour produire la distribution. Au fil du temps la version par défaut d'OS de l'environnement github à changé. Pour Ubuntu qui est utilisé c'est en octobre dernier ( actions/runner-images#6399 ). C'est Ubuntu 22.04 qui est maintenant utilisé avec github actions.
Cela tire visiblement maintenant la version minimale 2.35 de GLIBC

Visiblement une compilation en changeant d'OS réduit la version de GLIBC
si on prend Ubuntu 20.04 sur github (modification du workflow release) cela n'impose qu'une version GLIBC_2.29 (au lieu de 2.35). Mais il n'y a plus de runner github action pour descendre en dessous.
- os: ubuntu-latest ==> -os: ubuntu-20.04

Pour moi il n'y a que 2 types de solutions

Il faudrait afficher cette contrainte dans le readme (release linux publiée nécessitant une version GLIBC minimale)

Cordialement
Thierry
(gw 6.08 n'avait pas de liens dynamiques)

@rpo
Copy link
Author

rpo commented Sep 3, 2023

Pour ma part et pour la société de généalogie que je représente bénévolement la deuxième solution serait de loin notre préférée si c'est possible : "modifier la production de la version pour revenir à une application portable sans lien dynamique". Éventuellement je pourrais essayer de le faire. Les serveurs partagés qu'on utilisent ne nous donnent pas accès aux librairies GLIBC au-delà de 2.18 2.19 (qui était je crois l'état de la version Linux Geneweb 7.0 - ou 7.01 jusqu'à octobre 2021)

@a2line a2line added Feature: Approved A feature-wish that has been accepted by project owners. Bug labels Oct 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Feature: Approved A feature-wish that has been accepted by project owners.
Projects
None yet
Development

No branches or pull requests

6 participants