Sortie d’Ubuntu 18.04 LTS Bionic Beaver

Posté par  . Édité par Davy Defaud, BAud, Lucas, Benoît Sibaud, ff9097, palm123, Sylvestre Ledru et Bruno Michel. Modéré par bubar🦥. Licence CC By‑SA.
Étiquettes :
43
27
avr.
2018
Ubuntu

Sortie le 27 avril 2018, Ubuntu 18.04 est la vingt‐huitième version d’Ubuntu. Il s’agit d’une version dite « LTS » (Long Term Support), qui sera maintenue pendant cinq ans. Son nom de code est Bionic Beaver, soit le « castor bionique » en français.

Castor américain, d’après Wikipédia

Sommaire

Distribution Ubuntu

Pour rappel, Ubuntu est une distribution GNU/Linux basée sur Debian. Elle a hérité de sa distribution mère l’objectif d’universalité : elle vise à être utile sur les ordinateurs de bureau, les ordinateurs portables, mais aussi les serveurs, l’informatique en nuage et les objets connectés en général. Elle se veut simple d’accès pour les utilisateurs n’ayant pas de connaissances poussées en informatique, mais également attrayante pour les développeurs.

En plus de la distribution mère, Ubuntu, il existe plusieurs variantes officielles, fournies avec des choix logiciels différents, afin de couvrir un besoin (Ubuntu Server, Ubuntu Studio…) ou de fournir un environnement de bureau particulier (Kubuntu, Xubuntu, Lubuntu…). Cette dépêche présente les principales nouveautés.

Version LTS

L’abréviation LTS signifie Long Term Support, ou support à long terme, c’est‐à‐dire que contrairement aux versions stables qui sortent tous les six mois et qui bénéficient des correctifs de sécurité neuf mois après la sortie de la publication stable, une version LTS sort tous les deux ans et est maintenue pendant soixante mois (cinq ans).

Ce type de maintenance étendue existe depuis les débuts d’Ubuntu (la première LTS était Ubuntu 6.06 Dapper Drake, sortie il y a douze ans). Cependant, la généralisation de la maintenance de cinq ans à toutes les variantes (et pas seulement les serveurs) date d’Ubuntu 12.04 LTS Precise Pangolin.

À noter cependant que le support n’est assuré par Canonical que sur les paquets du dépôt main. Les paquets provenant d’autres dépôts sont, quant à eux, maintenus du mieux possible par la communauté, bien que des employés de Canonical puissent parfois également donner un coup de main.
En pratique, le support de cinq ans s’applique pour Ubuntu Desktop, Ubuntu Server et Ubuntu Core. Toutes les autres variantes ne seront supportées « que » pendant trois ans, à l’exception notable d’Ubuntu Studio qui ne sera supportée que neuf mois.

Il est possible de mettre à jour d’une version LTS à une autre. Si vous utilisez actuellement Ubuntu 16.04 LTS, notez que la mise à jour ne vous sera pas proposée avant fin juillet et la sortie de la première réédition « 18.04.1 » de cette nouvelle Ubuntu. En attendant, si vous souhaitez forcer le mouvement, vous pouvez simplement lancer la commande do-release-upgrade -d.

Nouveautés générales

  • noyau Linux 4.15 ;
  • Mesa 3D 18 ;
  • GCC 7.3 ;
  • Glibc 2.27 ;
  • systemd 237 ;
  • Python 3.6.5 ;
  • PHP 7.2 ;
  • OpenJDK 10 ;
  • PostgreSQL 10 ;
  • LXD 3.0 ;
  • GNOME 3.28 ;
  • KDE Plasma 5.12 ;
  • Qt 5.9.4 ;
  • LibreOffice 6 ;
  • Firefox 59 ;
  • LLVM/Clang 6 ;
  • meilleure prise en charge de l’architecture IBM s390x.

Option d’installation minimale

L’installateur Ubiquity, utilisé par la version standard d’Ubuntu et par la plupart de ses variantes, offre dorénavant une option permettant une installation « minimale ». Concrètement, avec cette option, seul un navigateur Web et les utilitaires de base seront installés en plus du bureau. Exit donc LibreOffice, le lecteur vidéo et autres.

Améliorations concernant la sécurité

De nouvelles options de compilation liées à la sécurité ont été activées par défaut. Les exécutables sont maintenant « à position indépendante » (PIE) et à « liens immédiats » (immediate binding), ce qui permet de rendre plus efficace la technique d’Address Space Layout Randomization.
Pour résumer, l’exploitation d’éventuelles failles de sécurité sera plus difficile au sein des logiciels fournis par Ubuntu.

Nouveautés pour le bureau par défaut (GNOME)

Alors que la version 17.10 d’Ubuntu utilisait par défaut un compositeur graphique basé sur le protocole Wayland, il a été décidé de retourner sur l’ancien et éprouvé X.Org pour cette version LTS. Le choix entre les deux sessions reste disponible sur l’écran de connexion. Il est attendu qu’Ubuntu 18.10 repasse en mode Wayland.

Début de « Snapification »

Lors d’une nouvelle installation, certains composants de GNOME sont par défaut installés via des paquets Snap. Il s’agira de la calculatrice, du moniteur système et des lecteurs de journaux système et de tables de caractères.
Les paquets Snap permettent une véritable isolation entre les applications et le système. Cela permettra de maintenir à jour les applications en question au cours de la vie de cette Ubuntu LTS, et donc éviter de rester bloqué cinq ans sur les versions de GNOME 3.28 fournies par les paquets Debian standards.

Le lecteur attentif notera que les applications « snapifiées » jusqu’à présent ne sont pas forcément celles dont les mises à jour paraissent le plus crucial. Mais il faut voir celles‐ci comme un premier pas qui permettra de s’assurer de la fiabilité de l’ensemble. L’objectif est que de plus en plus d’applications soient livrées par défaut sous forme de Snap à l’occasion des prochaines versions d’Ubuntu.

Écran de premier lancement

Au premier lancement après installation ou mise à jour, un guide « Quoi de neuf dans Ubuntu » est affiché. En plus de présenter des explications sur l’ergonomie globale du bureau, ce guide propose de configurer Livepatch (le système de mise à jour du noyau qui ne nécessite pas de redémarrage) ainsi que la collecte d’information au sujet du matériel utilisé.

Côté serveurs

En dehors des mises à jour de nombreux composants, la nouveauté la plus visible pour les nouvelles installations concerne l’introduction d’un nouvel installateur en mode texte nommé Subiquity. Celui‐ci calque son fonctionnement sur l’installateur standard des versions pour ordinateur de bureau d’Ubuntu. Ses principaux avantages sont une rapidité et une simplicité d’installation accrue, tout en permettant de partager le code sous‐jacent entre toutes les versions d’Ubuntu, et donc une charge de maintenance plus faible. De plus, ce nouvel installateur permet enfin à Ubuntu version serveur de profiter d’une véritable session autonome (live), afin de pouvoir facilement tester le système avant de lancer l’installation.
À noter cependant que Subiquity ne gère pas encore l’installation en mode RAID ou LVM. En cas de besoin, l’ancien installateur reste disponible au sein des images d’installation minimales et alternate.

Et la suite ?

À l’heure actuelle, le nom de code d’Ubuntu 18.10 n’a pas encore été dévoilé. Votre serviteur a un faible pour « Charming Caribou », mais c’est Mark Shuttleworth qui saura, comme d’habitude, trouver le nom qui convient. Au rayon des nouveautés attendues, on peut principalement s’attendre à une session Wayland fiabilisée et qui redeviendrait la session par défaut. Il est également probable que Kubuntu fasse un pas similaire avec la prochaine version de Plasma.

Plus globalement, Ubuntu 18.10 annonce le début d’un nouveau cycle de deux ans jusqu’à la prochaine version LTS, qui sortira en 2020. Il s’agira donc du moment idéal pour réaliser des changements au sein des technologies fondamentales de la distribution. En plus de l’accélération de la « snapification » du système, on parle par exemple de l’utilisation de l’algorithme de compression Zstandard pour tous les paquets afin d’accélérer les temps d’installation.
Vivement octobre prochain !

Aller plus loin

  • # KDE et wayland...

    Posté par  . Évalué à 5.

    Il est également probable que Kubuntu fasse un pas similaire avec la prochaine version de Plasma.

    Tu parles de la prochaine LTS dans 2 ans parceque si c'est pour la version de Octobre j'en serai bien surpris. Il reste beaucoup de chemin a Plasma pour etre utilisable avec Wayland… comme par exemple la possibilite de se connecter a une session et de s'en deconnecter sans faire bloquer le serveur… Ou d'avoir le curseur de la souris qui ne change pas de taille lorsque tu te deplaces d'une fenetre a une autre, ou que certaines applications ne demarrent pas… ou de refaire marcher soit les activites soit les bureaux virtuels mais bon la ils ont fait le tour de force de casser les deux en meme temps!

    Enfin des pailles quoi…

    Et je suis un utilisateur de Plasma et de KDE (je n'arrive a me faire a Gnome).

    • [^] # Re: KDE et wayland...

      Posté par  (site web personnel) . Évalué à 2.

      Perso, j'ai testé Wayland/KDE et j'ai été très agréablement surpris. Précisons tout de suite ce qui pourrait jouer:
      - Opensuse tumbleweed (Rolling Release)
      - Chip graphique du CPU i5-8400 avec le driver modesetting (ce driver semble avoir pris le pas sur le driver "intel"
      - Je n'utilise pas les "activités"
      - résolution 3840*2160

      Je n'ai pas su tout les bugs que tu cites, juste un truc pour moi, le non fonctionnement de la boite qui apparaît normalement sur le alt+F2.

      Reste que je suis d'accord avec toi, si j'étais "décideur de distrib", je n'irais pas non plus le mettre par défaut sur une TLS en Octobre ;) et d'autant plus que le cas Nvidia n'est pas réglé.

      Mais pour moi "tout seul", j'ai vraiment hésité avant de retourner sur Xorg: Wayland/KDE c'est presque fonctionnel sur ma config.

      • [^] # Re: KDE et wayland...

        Posté par  . Évalué à 3.

        En fait tous les problemes que j'ai cite sont reference en bug donc bien reel :)

        Le premier c'est assez penible car sddm et kde se renvoie la balle… (alors que bon le probleme a aussi lieu avec gdm…)
        Le probleme de curseur je crois que c'est lie a intel en effet.
        Le probleme d'application qui ne demarre pas va etre regle bientot.
        le probleme avec les activites, les devs de plasma renvoient (a juste titre) sur ceux de kde-desktop et la c'est ou la grosse embrouille arrive. Il y a du bon dans les activites (j'ai commence a m'en servir contraint et force pour avoir des fond d'ecran different suivant les bureaux) mais voila ca rentre en conflit avec les bureaux… du coup ils paraitrait que les devs ont "enfin" compris et vont merger les deux trucs… ce qui veut malheureusement dire de gros problemes en vue pour les utilisateurs… mais bon si on arrive finalement a avoir le meilleur des deux pourquoi pas.

        Et voila les autres problemes avant d'avoir plasma wayland par defaut. Je ne vois pas comment tout cela pourrait etre resolu en 6 mois…

        https://community.kde.org/Plasma/Wayland_Showstoppers

        • [^] # Re: KDE et wayland...

          Posté par  (site web personnel) . Évalué à 2.

          Oh ne t'inquiète pas, je te fais confiance depuis le temps je sais que tu ne raconte pas des cracks. Mais il y aussi les bugs qu'on remarque plus que d'autres selon les usages et les sensibilités de chacun.

          J'ai eu depuis une update vers kde 5.18, et j'ai refait un test Wayland pour voir en ayant à l'esprit ton message.
          - Le login sddm se passe bien
          - les bureaux virtuels ne fonctionnent effectivement pas. Bug bloquant pour moi
          - Rien remarqué sur la souris mais j'ai oublié d'y prêter attention.
          - La boite du Alt+F2 fonctionne bien :)
          - La boite de réglages de Kwin plante lorsqu'on joue avec….
          - A la déconnexion, SDDM se retrouve dans un état "planté". Outch :(

          Il y a effectivement du boulot avant d'être "par défaut" même si c'est encourageant sur l'ensemble.

          Il y a un point qui me turlupine néanmoins. Si je comprend bien, les différents réglages auparavant coté xorg doivent maintenant être créé coté gestionnaire de fenêtre pour Wayland, non? Je pense au DPI, nombre de couleurs, calibration…

          • [^] # Re: KDE et wayland...

            Posté par  . Évalué à 3. Dernière modification le 01 mai 2018 à 13:40.

            • A la déconnexion, SDDM se retrouve dans un état "planté". Outch :(

            Ben oui le "petit" bug SDDM/Plasma wayland… et je ne sais pas si tu as reussi a t'en sortir s'en redemarrer mais pas moi. Ctrl-alt-f2 ne fonctionnait plus… Encore un enorme point negatif dans un plantage wayland. Xorg faisait ca aussi … il y a quelques annees. Ca fait bien longtemps que je n'ai plus vu ce genre de gros probleme.

            Il y a un point qui me turlupine néanmoins. Si je comprend bien, les différents réglages auparavant coté xorg doivent maintenant être créé coté gestionnaire de fenêtre pour Wayland, non? Je pense au DPI, nombre de couleurs, calibration…

            En effet ca doit etre remis pour Plasma et ceci explique par exemple que redshift ne marche pas sous Wayland. Gnome a fait une recode ca pour mutter mais cela n'existe pas encore pour Plasma (que je sache).

            Il manque tout de meme beaucoup de chose pour que je passe a Wayland (et je ne parle pas que de KDE) donc je teste mais je ne compte pas utiliser avant un bon moment. Le truc redhibitoire de Wayland par rapport a Xorg c'est la transparence reseau et c'est pas pour demain que celle qui commence a apparaitre par bureau va fonctionner avec un HPC donc bon il y a encore pas mal d'annee avant que Xorg disparaisse.

  • # Cette 18.04 est très alléchante ...

    Posté par  . Évalué à -5. Dernière modification le 27 avril 2018 à 15:52.

    … mais pour mon usage personnel, je ne change pas d'avis et je reste fidèle à Mageia.

    Et Mageia sous Gnome.

  • # Zstandard, ou pas.

    Posté par  . Évalué à 10.

    on parle par exemple de l’utilisation de l’algorithme de compression Zstandard pour tous les paquets afin d’accélérer les temps d’installation.

    Oula, alors c'est en discussion chez Debian. Et franchement, je suis pas convaincu par l'intérêt de la chose.

    Zstd est un formidable outil de compression, mais l'usage généraliste des paquets, c'est l'installation via le réseau. Et dans la plupart des cas, il vaut mieux du LZMA (xz), qui compresse bien mieux. Le temps de transfert est bien plus long que le temps de décompression. On pourra s'en convaincre sur ce benchmark, en ayant choisi samba comme corpus. Le temps de transfert sur un lien à 7 Mio/s (ce qui est déjà pas mal) prend plus de 90% du temps total.

    Par contre, c'est évident que sur un support d'installation, avoir du zstd permet une installation plus rapide. Ou bien si on installe des VMs à tour de bras avec un dépôt local.

    Donc ce qui est intéressant, c'est que dpkg supporte zstd. Et on pourra voir ce qui peut en être fait.

  • # Netplan et systemd-resolved

    Posté par  . Évalué à 9.

    Pour ceux qui n'utilisent que les versions LTS, les deux nouveautés qui changent pour l'administration d'un serveur sont la dépréciation ifupdown au profit de netplan (la documentation est là https://netplan.io/, chic du yaml !)et de /etc/resolved.conf au profit de systemd-resolved (la documentation est là : https://www.freedesktop.org/software/systemd/man/resolved.conf.html )

  • # Castor

    Posté par  . Évalué à 6.

    C'est donc vrai, cette histoire des castors et des canards…

  • # Snap...

    Posté par  . Évalué à 2.

    Les paquets Snap permettent une véritable isolation entre les applications et le système.

    C'est tellement vrai que ça empêche certains programmes de fonctionner correctement. Par exemple, l'extension TexMaths de LibreOffice qui a besoin de programmes externes ne fonctionne tout simplement si LibreOffice est installé via un snap… (Idem pour flatpak et sans doute pour appimage)

    Vive la sécurité…

    • [^] # Re: Snap...

      Posté par  . Évalué à 2.

      J'ai aussi de mal à voir l'intérêt de snap pour les applications nommées dans la dépêche.
      Si quelqu'un peut éclairer ma lanterne ?

      • [^] # Re: Snap...

        Posté par  (site web personnel) . Évalué à 3.

        cf le 2è paragraphe dans la dépêche… qui s'adresse au lecteur attentif ;)

      • [^] # Re: Snap...

        Posté par  . Évalué à 0.

        Faudrait surtout qu'ils stoppent leur envie de toujours vouloir tout faire à leur sauce. Snap n'a aucun intérêt comparé à Flatpak. Ah si ça leur permet de tout contrôler vu qu'il n'y a pas la notion de dépôts indépendants et que tout est centralisé sur leur dépôt obligatoirement.
        Sinon c'est quand même bizarre de devoir justifier l'intérêt de ces technologies sur un site comme DLFP

      • [^] # Re: Snap...

        Posté par  (Mastodon) . Évalué à 4.

        Moi ce qui me dérange c'est qu'on parle de "début de snapification" dans une LTS. C'est pas dans une version support à long terme que j'aurais intégré un "début de truc encore loin d'être complet ni testé comme il se doit".

        • [^] # Re: Snap...

          Posté par  . Évalué à 3.

          Pour préciser, il s'agit d'un début uniquement en ce qui concerne le desktop.
          Ubuntu Core est entièrement « snapifié » depuis plusieurs versions maintenant. Snap en lui même n'est plus expérimental et était déjà installé par défaut dans la LTS précédente.

    • [^] # Re: Snap...

      Posté par  . Évalué à 3.

      C'est rigolo je viens de lire la meme critique pour les flatpak… je sens qu'il va y avoir de grande partie de rigolade avec ces trucs…

      • [^] # Re: Snap...

        Posté par  . Évalué à 1.

        C'est à dire ?

        • [^] # Re: Snap...

          Posté par  . Évalué à 3.

          Que avoir acces aux programmes fourni par le systeme de paquets classique peut etre problematique (commentaire vu dans une news sur ce site et que j'ai la flemme de chercher).

          Ce qui est logique, sinon cela servirait a quoi l'isolation?

  • # et sinon..

    Posté par  . Évalué à -5.

    ..la bi queue du castor est toute plate ? je ne savais pas :(

    oui oui je -->[]

  • # Kernel

    Posté par  (site web personnel) . Évalué à 10.

    On dira ce qu'on voudra c'est quand même très bizarre de baser une distribution LTS sur un noyau 4.15 non LTS et déjà abandonné upstream. Pourquoi ne pas avoir utilisé le 4.14 qui est un noyau à support à long terme ?
    Le noyau 4.15 utilisé dans cette version d'Ubuntu devra donc être maintenu pendant 5 ans uniquement par les devs de Canonical. Vu la cascade de corrections qui arrive dans la branche -stable (du fait de cette nouvelle technologie) c'est quand même assez casse-gueule comme choix…

    • [^] # Re: Kernel

      Posté par  . Évalué à 0. Dernière modification le 28 avril 2018 à 20:03.

      Effectivement !!!
      Ma Mageia 6, bien qu'elle ait été publiée avec un 4.9 elle est désormais en 4.14.

    • [^] # Re: Kernel

      Posté par  (site web personnel) . Évalué à 2.

      Complètement d'accord. Apparemment, c'était déjà le cas pour Ubuntu 14.04 LTS, qui utilisait le kernel 3.13 (non LTS). Je ne comprends vraiment pas l'intérêt.

    • [^] # Re: Kernel

      Posté par  . Évalué à 2.

      https://wiki.ubuntu.com/Kernel/Support#A14.04.x_Ubuntu_Kernel_Support

      Pour la 14.04 ils s'occupent visiblement de backporter les correctifs dans le 3.13 qui n'est pas non plus LTS.
      Mais tu peux installer le 4.4 en option.

      Un peu compliqué tout ça en effet.

    • [^] # Re: Kernel

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      C'était peut être nécessaire pour pouvoir parfaitement prendre en charge les nouveaux CPU / GPU AMD (Ryzen, Raven Ridge / RX Vega) ?

      • [^] # Re: Kernel

        Posté par  (Mastodon) . Évalué à 3.

        Ou peut-être l'arrivée des correctifs Meltdown et Spectre ?

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # En quoi bon ?

    Posté par  . Évalué à -10. Dernière modification le 28 avril 2018 à 22:58.

    Pourquoi la traduction est-elle qualifiée d'être en "bon" Français ?
    Pour moi, quand on écrit en bon Français, on met une majuscule à Français, j'ai pas raison ?

    • [^] # Re: En quoi bon ?

      Posté par  (site web personnel) . Évalué à 9.

      Eh non.

      On met une majuscule pour parler des Français, des Belges, des Suisses, etc. Mais on parle de la langue française sans majuscule, le français quoi.

    • [^] # Re: En quoi bon ?

      Posté par  (site web personnel) . Évalué à 3.

      France avec un F mais français avec un f.

      • [^] # Re: En quoi bon ?

        Posté par  . Évalué à 3.

        Pas exactement : Français (avec une majuscule) s'il s'agit du gentilé. Mais français (sans majuscule) s'il s'agit de la langue ou de l'adjectif.

    • [^] # Re: En quoi bon ?

      Posté par  (site web personnel) . Évalué à 3.

      La notion de bon français/françois ou de français correct/académique n'a pas beaucoup de sens ici sur deux mots. Corrigé, merci.

  • # OpenJDK non LTS

    Posté par  . Évalué à 2.

    Bizarre d'embarquer une version non LTS de Java dans une distri LTS…

    • [^] # Re: OpenJDK non LTS

      Posté par  . Évalué à 4.

      Il y a des versions LTS d'openjdk?

    • [^] # Re: OpenJDK non LTS

      Posté par  . Évalué à 4.

      D'après les notes de versions, OpenJDK sera mis à jour au cours de la vie de la LTS (donc on passera en 11 par défaut, etc.).

      Sachant qu'OpenJDK 8 reste disponible dans le dépôt universe en cas de besoin.

  • # Pas de LVM par défaut sur les serveurs ??

    Posté par  (site web personnel) . Évalué à 2.

    À noter cependant que Subiquity ne gère pas encore l’installation en mode RAID ou LVM. En cas de besoin, l’ancien installateur reste disponible au sein des images d’installation minimales et alternate.

    Je suis assez étonné de voir ça du côté serveur. Y a-t'il vraiment des administrateurs qui n'utilisent pas LVM? C'est un problème bloquant pour moi, heureusement il y a toujours l'ancien installateur, mais dans ce cas y'a pas vraiment eu de progrès côté serveur. Je testerai ça suffisamment vite.

  • # GCC option de compilation change avec -pie par défaut

    Posté par  (site web personnel) . Évalué à 0.

    bonjour ,

    Avec la LTS18.4 je découvre que ma programmation tout du moins mon makefile …. ben je dois changer en -no-pie sinon je n'ai plus d'executable … pour j'étais déjà en 7.3 mais avec la 16.4

    j'ai essayé de comprendre et fait quelques recherches mais j'ai du mal à comprendre

    deux explications (mais elles ne viennent pas de moi ) mais dans ce cas on perd la notion d'executable … ????

    Parce que d’une part, tu ne spécifies à aucun moment que tu souhaites avoir un objet partagé lors de l’édition de liens (implicite), d’autre part, l’option -no-pie spécifie que ton binaire sera toujours chargé en mémoire à la même adresse de référence.

    "pie" signifie Position Independent Executable. L’intérêt d’utiliser cette option est de pouvoir, à chaque exécution de ton binaire, le charger à des adresses mémoires différentes (exactement comme pour des objets partagés qui ont besoin d’être relocalisés en mémoire en permanence plutôt que de toujours être chargés à une adresse mémoire fixe, ce qui peut entraîner des problèmes de collisions si deux objets partagés doivent être chargés à la même adresse, par exemple).

    L’intérêt de faire ça pour un binaire exécutable et pourquoi pas seulement pour les objets partagés ? Eh bien il s’agit d’une mesure d’atténuation (je ne sais pas comment traduire correctement "mitigation") d’attaques informatique de type Return Oriented Programming où tu vas corrompre la mémoire de ton binaire pour exécuter un code arbitraire. Et pour exécuter ce code arbitraire, tu as besoin de savoir à quels adresses mémoires chercher les bonnes informations. Et comme avec l’option PIE les adresses ne sont jamais les mêmes à chaque exécution, ça rend l’exploitation d’une vulnérabilité plus compliqué que prévu.

    ou encore ….

    Il semble que GCC soit configuré pour créer des binaires -pie par défaut. Ces binaires sont en réalité des bibliothèques partagées (de type ET_DYN), sauf qu'ils s'exécutent exactement comme un exécutable normal. mais ne sont pas marqué executable donc il faut soit les faire monter avec un lanceur ou dans un terminal si l'on conserve l'option -pie (perso je trouve que l'on aurait pu les marqués comme executable c'est plus simple lors de test etc… mais j'ai peut-être pas compris)

    j'ai trouvé les paramètres par défaut
    Linker Options
    object-file-name -llibrary -nostartfiles -nodefaultlibs
    -nostdlib -pie -rdynamic -s -static -static-libgcc
    -static-libstdc++ -shared -shared-libgcc -symbolic -T script
    -Wl,option -Xlinker option -u symbol

    tout ce que j'ai compris :
    c'est pour la sécurité…. mais mais mon programme n'est plus un binaire mais une lib partagé et là je butte parce que pour des applications de gestions d'entreprise qui ne concerne que des données et dont l'environnement est fermé ?????

    reprendre l'ensemble des makefiles pour changer en -no-pie ouffff bref si ont pouvait m'aider je serais preneur … et je ne suis pas partisan de changer la configuration de base.

    Merci

    pourrait-on m’éclairer S.V.P.

    JPL @bientôt

  • # Commentaire supprimé

    Posté par  . Évalué à -3. Dernière modification le 03 avril 2021 à 21:59.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.