Salut les Linuxiens de tout bords,
je tiens a vous présenter ma première bibliothèque partagée, qui porte le nom de:
hobdcalc (Hexadecimal, Octal, Binary, Decimal Calculator).
Si vous vous demander ce qu'est concrètement une bibliothèque partagée: je vous explique.
Une bibliothèque partagée est un fichier compiler situer dans un dossier bien spécifique de votre arborescence qui contient des fonctions. La bibliothèque est charger en mémoire et chaque programme qui utilise une fonction de cette bibliothèque va chercher le code machine de cette fonction en mémoire.
La glibc est une bibliothèque partagé donc tous les programmes écrit en C que votre OS ou que vous exécutés utilisent le fichier charger en mémoire de la glibc pour ses différentes fonctions, ce qui économise de la mémoire.
Une bibliothèque partagé s'inclue dans vos programmes grâce a un fichier d'en tête (d'extension *.h) qui ne contient que les déclarations des fonctions, le corps des fonctions se trouvant dans les fichiers d'extension *.so situer sur mon OS Linux dans le dossier /usr/lib.
La bibliothèque doit être linker grâce a l'option -l de gcc ou en utilisant le programme prévus a cet effet le linkeur ld un éditeur de liens.
Rappelez moi a l'ordre si j'ai dit des bêtises.
Brefs j'ai créer une bibliothèque partagé ou shared library sur laquelle est basé Ghobdcalc une calculatrice multibases avec fonctions mathématiques, de mémorisation de valeurs et d'export de données vers une feuille de calcule dans divers formats (*.txt, *.csv et *.html).
Toutes les fonctions de conversion entre les bases 2, 8, 16 et 10 sont pris en charge par la bibliothèque que j'ai créer.
Mais celle-ci peut aussi effectuer des calcules, seulement les opérations de base addition, soustraction, multiplication et division dans les bases 2, 8 et 16.
Brefs hobdcalc est une shared library de conversion et calcules multibases.
Le zip contient:
- Les sources (écrit en C).
- Les pages de manuel ou manpages.
- Un script d'installation au format Makefile.
- Un fichier d'assertion démontrant le justesse des conversions et opérations.
- Et un readme.
Mais j'aimerai quand même poser deux question car je ne suis sur que pour un OS Ubuntu des dossiers:
- Des shared library (/sur/lib sous Ubuntu).
- Des manpages (/usr/man/man${n_section}/ sous Ubuntu).
Et je pense que ces chemins varient en fonctions des distribution.
Dommage que les variables d'environnement:
- MANPATH et
- LD_LIBRARY_PATH
ne soit plus définis et ce ne sont pas seules qui manques.
Je pense q'un programme pour ce genre de problème devrai exister dans le monde Linux moderne:
en pensant qu'il existe de nos jours tellement de distributions qu'il faudrait pouvoir identifier ce genre d'informations. Pourquoi pas un programme nommer manpath qui renvoie le chemin des manpages sur le système cible.
Et vlan je viens de taper manpath dans mon terminal et ça existe déjà la preuve que Linux évolue.
Pour le chemins des shared library sur votre OS je m'en remet a vos réponses éclairés.
Si vous voulez lire le code de ma library ou de mon programme, vos critiques, encouragements sont la bienvenus.
En espérant ne pas trop avoir dit de bêtises, merci pour vos réponses.
# Hmmm.
Posté par jigso . Évalué à 3.
"Rappelez moi a l'ordre si j'ai dit des bêtises."
Euh, les fautes d'orthographe, ça compte ?
Pour la position des libs et des manpath, a priori ce n'est pas ton problème de développeur, c'est le problème du packageur. Et si c'est toi, c'est propre à chaque système, donc tu dois suivre les règles d'ubuntu pour les paquets ubuntu, les règles debian pour debian, les règles redhat pour redhat, etc. et proposer les paquets pour toutes les distributions. Globalement c'est assez similaire d'une distrib à l'autre, mais le diable se cache dans les détails.
L'autre solution c'est de proposer l'installation dans /usr/local.
# LIbtool
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Il existe, depuis 16ans et il permet de faire un build process indépendant de la plateforme unix (linux, bsd, whatever).
ça s'appelle "libtool", et c'est très bien intégré avec les outils "autoconf" / "automake" qui permet la génération d'un script de configuration et des makefiles en fonction des parametres détéctés sur l'OS de l'utilisateur
[^] # Re: LIbtool
Posté par Linuxator (site web personnel) . Évalué à -4.
Merci pour cette info,
étant actuellement logué sur un OS Windows, je ne peut faire de recherches concernant "libtool" dans l'immédiat.
Mais ça parait assez intéressant surtout que je vois plusieurs utilités personnelle:
-) J'ai un programme de sécurité nommer datetime-lock, le problème est que le programme doit être au démarrage, ce que je n'arrive qu'a faire avec la distribution que j'utilise: Ubuntu.
J'ai essayer avec plusieurs autres distributions dans une VM sans succès notamment avec la commande chkconfig.
Attention le programme a un bug, que j'ai récemment découvert, si l'on l'installe sans configurer une première fois une plage, il s'exécute ce qui n'est pas voulus.
Je vais le bugfix dès que j'aurai le temps.
Pourrait tu développer le sujet si tu est connaisseur, utilisateur ce serai vraiment sympa de ta part, de m'éclairer un peu plus que le simple tuyau, je te serai reconnaissant.
Car je pratique le C que depuis 2 ans et je n'ai publier et donc distribuer que 2 programmes, je manque donc d'expérience concernant le packaging de programme écrit en C.
PS: désolé pour les fôtes d'orthogaffes.
Merci pour vos réponses éclairées.
[^] # Re: LIbtool
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
Alors la dessus autoconf/libtool n'aidera pas à grand chose
C'est bien joli, mais si j'ai un accès physique à ta machine, ton datetime-lock seul n’empêchera pas d’accéder à ton sytème, même sans connaître tes mot de passe. Et le plus beau c'est que tu ne le sauras pas…
Soit en bootant la machine avec un autre init (init=/bin/bash dans la ligne de commande du shell) soit en extrayant le disque.
Pour protéger vraiment la machine il faut surtout crypter le FS et la si effectivement tu diffuse ta clef privée à tout vas même la protection de grub par mot de passe ne va pas changer grand chose au problème et encore moins un outil qui éteint la machine lors du boot.
ça fait bien longtemps que je n'ai pas pratiqué donc je vais éviter de dire des bêtises, il existe plein de guide, docs officielle, etc sur les autotools.
http://www-igm.univ-mlv.fr/~dr/XPOSE/Breugnot/
http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool
https://www.lrde.epita.fr/~adl/autotools.html
[^] # Re: LIbtool
Posté par Linuxator (site web personnel) . Évalué à -4. Dernière modification le 26 décembre 2014 à 11:42.
D'accord, ça dépends du degrés de parano, mais dans le README.txt du programme (qui est juste une pierre dans un système de protection) il est conseiller de mettre un cadenas sur son ordinateur pour éviter qu'on puisse l'ouvrir: sur la plupart des modèles il y a une petite rondelle, je ne sais pas si vous l'avez remarquer, pour placer un cadenas afin d'éviter de se faire ouvrir.
Sinon il faut configurer le bios de façon a ce qu'il ne boot pas sur le CD/DVD et surtout mettre un mot de passe bios. Sinon un meuble fermé, adapté, pour mettre son U.C est recommander aussi.
La chambre forte et les lasers pour le plus paranos qui ont les moyens.
Sinon je suis aller rapidement sur le site officiel de libtool et donc c'est un outil pour distribué des libraries comme le dit son nom.
# binaire d'install & économie supposée des lib partagées
Posté par freem . Évalué à 2. Dernière modification le 02 janvier 2015 à 12:38.
2 choses.
Premièrement, pour ton problème de MANPATH et LD_LIBRARY_PATH, peut-être que cpack (qui est fournit avec cmake) pourra t'aider. Pas sûr, perso je ne me suis encore jamais vraiment amusé à faire des archives pour diverses plate-formes…
Secundo, ceci n'est pas totalement vrai:
Les informations et calculs nécessaires à charger une bibliothèque liée dynamiquement (ou «partagée», les fameuses DLL de windows et .so sous linux) sont conséquentes.
Certains considèrent que la quantité d'informations et de calculs nécessaires au bon chargement d'un programme fait qu'au final, lier statiquement ferait en réalité gagner à la fois de l'espace mémoire (a minima mémoire persistante, je crois qu'ils parlaient aussi de RAM mais j'ai un doute) et calculs, du coup il y aurait une réelle perte de performances avec l'édition dynamique.
Il faudrait que j'arrive à retrouver la littérature sur laquelle j'étais tombé il y à quelques mois, les arguments étaient vraiment très intéressants, mais je me souviens que cette littérature m'a mené sur l'un des projets suckless: stali linux. Il y à une FAQ qui expose rapidement les idées de l'auteur sur ce sujet.
Personnellement, je ne suis pas totalement d'accord avec ces gens: lier dynamiquement du code utilisé par le système entier me semble plutôt pertinent, surtout pour les MaJ, bien qu'ils m'aient mis le doute (peut-être que je devrais tester sta.li, pour en avoir le cœur net?). Par contre, ce qui est quasi-certain, c'est que dans le cas de ta lib, qui ne sera pas utilisée par plus de 3-4 utilitaires, en faire une lib statique sera plus efficace.
Tu devrais tester: combien pèsent ta calculatrice liée dynamiquement + la lib, et combien pèse ta calculatrice liée statiquement? Pour ma part, j'avais fait quelques tests de mon côté: j'avais réimplémenté yes, pour être quasi égal au niveau des fonctionnalités avec la version GNU (le seul truc que je supportait pas, c'était les locales pour l'option --help…) et entre le statique sur la glibc et le dynamique, j'avais, de mémoire, 15% de gain. Ma version statique pesait aussi 10k de moins que le yes de gnu, sachant que GNU yes pèse… 31K. Ça donne à réfléchir, et pas qu'un peu.
Tout le monde ne parle que d'édition de liens dynamique, mais je crois que tout le monde fait juste le mouton de Panurge, sur ce point et sur bien d'autres. Peut-être que l'industrie logiciel s'encrasse dans ses idées reçues, au final…
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par Linuxator (site web personnel) . Évalué à -4.
Il faut dire que je suis loin d'être un Guru Linux, et que je n'ai que 2 ans d'expérience avec le C et surtout tout ce qui l'entoure et la grosse lacune de ne pas bien connaître make cmake et co: juste assez pour faire un Makefile avec une unique règle default: ou les quelques lignes nécessaire a l'installation de ma lib sont placer.
Peut être je devrai lire ce livre mais je n'ai publier que deux programmes en C et donc je manque d'expérience pour le packaging et la lib. La prochaine fois j'utiliserai peut-être libtool comme conseiller.
Et disons que j'ai un peu déduit ce qu'était une bibliothèque partager de part mes expériences, sans vraiment être certains et instruit sur le sujet, pour faire les pages man je me suis débrouiller comme j'ai put et je suis content du résultat penser a mettre most comme pager c'est plus sympa en coloré ($ export PAGER=most).
PS: je me suis casser les dents 2 fois sur la calculatrice, une fois avec une interface ncurses et une fois sous forme d'interpréteur pour finalement y arriver avec une interface GTK+3.
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par Linuxator (site web personnel) . Évalué à -3.
Mon plus gros problème est de faire de la pub pour mes créations:
En faisant de la pub sur le site de pygame pour un jeu programmer en python avec pygame. Je fais 1165 téléchargements
Comparez a un autre programme qui n'est pas forcément plus mauvais mais qui ne dispose pas d'un site, permettant de présenter le programme, du module utilisé.
Je fais 25 téléchargements, en faisant un peu de pub sur 2 ou 3 sites Linux.
Si vous savez ou l'on peut présenter ses créations dans le but de les faire découvrir aux autres, le termes de pubs n'est pas approprier car je ne vend rien, ça serai vraiment sympa de votre part de m'en informer !!!
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par freem . Évalué à 2.
github
bitbucket
berlios
sourceforge
savannah
Et bien d'autres (à noter que j'ai écrites les URI de tête, sauf berlios et savannah, j'espère ne pas m'être planté sur les domaines…).
En fait, ça, ce sont de forges logicielles, des sites qui hébergent toute l'infra nécessaire pour bosser à plusieurs autour d'un même projet, ça ne fait pas forcément de la pub, mais ça permets diverses choses, qui facilitent le peer review (revue par les pairs).
Par exemple, on à généralement un outil qui permet de lire le code tel qui était à tel commit (sorte de version, idéalement chaque commit est l'équivalent d'un patch et donc très petit), des outils qui permettent de suivre des projets, voire des développeurs, ainsi que des outils permettant de faire des rapports de bugs et bien sûr, de permettre la soumission de patch d'une façon très très simple.
Après… pour faire connaître, ben, linuxfr, mais attention parce qu'à mon avis ici les gens sont plus dans la recherche du logiciel fini ou qui fait un truc sympa ou alors d'une façon différente. Une nième calculatrice faite juste pour le fun à peu de chances d'intéresser des gens.
Pour ça, j'irais plutôt voir du côté de developpez.com, dont la communauté est plus spécialisée développement (de tout niveau) avec quelques intéressés par le libre mais pas la majorité. Elle est aussi nettement plus importante.
Tu peux aussi utiliser le réseau codes-source, je n'ai jamais trop apprécié ni utilisé, mais ça me semble un peu dans ce que tu cherches.
Peut-être le site du zéro, mais vu ce qu'il est devenu, j'ai un gros doute. D'ailleurs, je crois qu'il à été forké…
Toujours est-il que tu mets le doigt sur un bon point: je ne connais aucune communauté qui soit vraiment orientée peer review, et c'est bien dommage, parce que lire le code des autres est un bon moyen de s'améliorer soi-même tout en aidant les autres pour moi.
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par freem . Évalué à 2.
Moi non plus. Mais on ne parle pas de linux ici, uniquement de développement.
Je suis tombé amoureux de ce truc quand j'ai tenté pour la 1ère fois de compiler openMW. J'avais déjà tenté de compiler pleins de trucs à base d'autotools (genre wxWidgets) et quand ça merde, ça merde juste dur, le code est illisible, et… bref, une plaie.
À côté, j'avais compilé openMW, et j'ai voulu utiliser cpack pour faire un paquet debian, mais le code pour cpack n'était plus à jour. Il ne m'a fallu que 5 minutes à lire un code clair comme de l'eau de source pour corriger (un problème de version de dépendance) et générer le .deb pour ma machine.
C'est tellement simple que c'en est effrayant. Par contre, c'est un générateur de code qui pond un makefile, et comme tous les générateurs de code, ça génère un truc à peu près illisible et clairement pas maintenable.
Maintenant, il permets de compiler en dehors du chemin des sources, sans prise de tête, sous windows comme sous linux ou BSD, et ça, c'est vraiment génial.
J'ai lu que c'était pas terrible quand on essaie de bosser sur de l'embarqué, mais de toute façon je n'ai pas accès à ce type de matos (c'est en projet ceci dit).
Pour faire court, une DLL (enfin, .so sous nux, j'ai encore de vieux réflexes, mais il faut dire que j'ai codé et bricolé plus de 6 ans sous windows only…), c'est une liste de fonction qui est chargée en mémoire lorsqu'un programme à besoin d'elle, et qui est partagée quand plusieurs programmes s'en servent.
Donc, gain théorique de ressources…
Sauf qu'en fait, comme dans toutes les optimisations, on ne gagne jamais sur tous les tableaux, et pire: "early optimization is the root of evil".
Pour faire court (et probablement trop simplifié, mais je n'ai que commencé à lire le super doc que j'ai trouvé à ce sujet récemment) le programme indique à l'OS une liste de symboles dont il à besoin pour tourner (sous linux, qui utilise le format binaire ELF, ça s'appelle des DSO).
Ensuite, l'OS va regarder qui les fournit, s'ils sont déjà chargés en mémoire, et en fonction de la situation, charger la DLL. Une fois que cette DLL est chargée, il va effectuer encore du travail pour dire à l'application qui en à besoin où sont les symboles dont elle à besoin.
Ah, et bien sûr, si l'application n'a besoin que d'un nombre limité de symboles, l'OS charge toute la lib quand même…
Je ne parle même pas des risques d'emmerdes liées à l'utilisation des lib dynamiques (dll_hell, modification illégitime de ld_library_path qui détourne ton application, etc).
Alors que pour une lib statique, l'OS charge le binaire, et basta (par contre, quand on fait une maj il faut refaire l'édition des liens).
Après… les deux ont leurs avantages, et il est probable qu'une DLL bien pensée aie plus d'avantages que d'inconvénients. Seulement voila, les gens (et moi le premier jusqu'à il y à peu) ont tendance à partir du principe que ça ne change rien, ou qu' «il suffit de» alors qu'en fait c'est plus compliqué qu'on ne le pense au premier abord.
Je ne suis pas du camp des auteurs de suckless tools, qui ont commencé une distro ou tout est lié en statique nommée stali, je les trouve trop extrêmes (et dans certains documents qu'ils citent il y à de sacrés biais) mais ils ont ma sympathie quand même, parce qu'ils osent penser différemment et agir contre la tendance actuelle de bloater les programmes sous prétexte que "le client rachètera du matos" (phrase entendue d'un de mes profs, ça ma choqué il y à 8 ans, et je suis content que toutes ses prédictions genre .NET vaincra, l'optim sertà rien & co se retrouvent dégommées par le mobile et l'embarqué, les machines les plus communes maintenant :p).
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par Linuxator (site web personnel) . Évalué à -3.
Ouais mais tu est quand même beaucoup plus calé que moi, déjà tu a semble-t-il étudier l'informatique a l'école, moi je suis autodidacte depuis presque 5 ans et toi tu a passer 6 ans sur Windows, moi quelques heures le temps de faire une version Windows de mes programmes (python, en C c'est un cauchemar le portage: les libraries externes !!!).
Au niveau de la table des symbole je n'ai pas bien compris le processus de compilation et la structure d'un exécutable:
Le compilateur construit une table de symboles d'après l'analyse du code source:
L'analyseur lexicale insère les symboles: c'est la portion du compilateur charger de regrouper les caractères du code source en chaînes significatives, les lexèmes. Ceux-ci sont traduit en éléments syntaxique, les tokens, qui sont passer a l'analyseur syntaxique. Au fur et a mesure que l'analyseur lexicale rencontre des symboles sur son flux d'entrée, il stocke les informations correspondantes dans la table des symboles. Les deux attributs important mémorisés sont le lexème du symbole et le type de token que constitue ce lexème (Un identificateur ou un opérateur, par exemple). Stocker dans une table de hachage…
J'ai du regarder dans un livre pour ne pas dire de bêtises dans le paragraphe précédent. Et il y a aussi une histoire de d'analyse de BNF ??? Un truc qui permet de traiter tous les éléments d'un langage de programmation comme grep peut décrire une langue parlé…
Sinon je ne sais pas trop.
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par Linuxator (site web personnel) . Évalué à -3.
Sinon il y a une histoire de construction d'adresses relative aussi. Je me souvient pas très bien.
Si vous vous demandez d'ou je sort ça il y a un livre intéressant mais qui traite plutôt du fonctionnement matériel d'un ordinateur,
malgré que le livre s'appelle: Architecture des machines et des systèmes informatiques
Le livre est très bien fait coté pédagogique, je vous le recommande chaudement, et n'est pas trop difficile a comprendre et il y a un chapitre sur le processus de la compilation.
[^] # Re: binaire d'install & économie supposée des lib partagées
Posté par freem . Évalué à 2. Dernière modification le 12 janvier 2015 à 12:01.
C'est vrai… mais j'ai appris avant de toucher au code en cours, résultat je n'ai pas appris grand chose à l'école. C'est le temps qui fait que je suis un peu meilleur, rien d'autre amha.
Enfin… pour être exact, je dois aussi préciser que mon seul diplôme obtenu, c'est un bac STI électronique, ça aide aussi j'imagine.
Oui, mais ton noyau doit être capable de retrouver ces symboles dans d'autres binaires, et ça, ça à un coût au runtime, et si ta lib expose trop de symboles, tu perds en vitesses sans y gagner en espace mémoire (voire pire: en y perdant, comme c'est par exemple le cas avec /bin/yes, qui pèse 31Kio chez moi… juste pour flooder une string identique à l'écran, c'est énorme! Et si on veut être exact, on rajoute la taille de la libc.). Je préfère ne pas trop en parler, je dirai des conneries (il faut que je prenne le temps de lire ce fichu pdf…).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.