# [revdep-rebuild] openoffice source...

## Fenril

Bonjour,

Sur une de mes machines (Gentoo AMD64) j'ai fait un bon petit revdep-rebuild des familles. J'ai donc comme cela arrive parfois des liens cassés, sauf que là, celui qui est concerné c'est OpenOffice :

```
# revdep-rebuild -i

 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies

 * Packages containing binaries and libraries broken by a package update

 * will be emerged.

 * Collecting system binaries and libraries

 * Generated new 1_files.rr

 * Collecting complete LD_LIBRARY_PATH

 * Generated new 2_ldpath.rr

 * Checking dynamic linking consistency

[ 78% ]  *   broken /usr/lib64/openoffice/basis3.2/program/i18npool.uno.so (requires libicui18n.so.42

libicuuc.so.42)

[ 79% ]  *   broken /usr/lib64/openoffice/basis3.2/program/libfrmlx.so (requires libicui18n.so.42

libicuuc.so.42)

[ 80% ]  *   broken /usr/lib64/openoffice/basis3.2/program/liblnglx.so (requires libicuuc.so.42)

 *   broken /usr/lib64/openoffice/basis3.2/program/liblwpftlx.so (requires libicui18n.so.42

libicuuc.so.42)

 *   broken /usr/lib64/openoffice/basis3.2/program/libmswordlx.so (requires libicuuc.so.42)

 *   broken /usr/lib64/openoffice/basis3.2/program/libsvtlx.so (requires libicuuc.so.42)

 *   broken /usr/lib64/openoffice/basis3.2/program/libsvxcorelx.so (requires libicuuc.so.42)

 *   broken /usr/lib64/openoffice/basis3.2/program/libsvxlx.so (requires libicuuc.so.42)

 *   broken /usr/lib64/openoffice/basis3.2/program/libswlx.so (requires libicuuc.so.42)

[ 81% ]  *   broken /usr/lib64/openoffice/basis3.2/program/libvcllx.so (requires libicule.so.42

libicuuc.so.42)

[ 100% ]                 

 * Generated new 3_broken.rr

 * Assigning files to packages

 *   /usr/lib64/openoffice/basis3.2/program/i18npool.uno.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/libfrmlx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/liblnglx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/liblwpftlx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/libmswordlx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/libsvtlx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/libsvxcorelx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/libsvxlx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/libswlx.so -> app-office/openoffice

 *   /usr/lib64/openoffice/basis3.2/program/libvcllx.so -> app-office/openoffice

 * Generated new 4_raw.rr and 4_owners.rr

 * Cleaning list of packages to rebuild

 * Generated new 4_pkgs.rr

 * Assigning packages to ebuilds

 * Generated new 4_ebuilds.rr

 * Evaluating package order

 * Generated new 5_order.rr

 * All prepared. Starting rebuild

emerge --oneshot   app-office/openoffice:0
```

Il s'agit de... la version source non compilée, que j'ai préféré installer à celle du paquet binaire. Bon vous imaginez bien ça m'a pris une après-midi... Donc j'aimerai éviter de le refaire pour une simple réparation de lien, du coup ma question est de savoir si cela recompile entièrement openoffice et donc j'en aurai pour des heures, ou simplement les fichiers concernés du paquet, ou s'il existe une astuce pour ne recompiler que ces fichiers.

----------

## gglaboussole

Oui ça va te recompiler oo et prendre autant de temps, sauf si tu utilises ccache qui permettra à gcc de réutiliser les parties de code identiques (à condition bien sûr qu'il ait déjà été compilé au moins une fois avec ccache d'activé)... y a pas d'astuces, à moins de refaire les liens symboliques avec ln mais je te le déconseilles vivement

----------

## ghoti

 *gglaboussole wrote:*   

> à moins de refaire les liens symboliques avec ln mais je te le déconseilles vivement

 

A mon avis, tu confonds l'"édition des liens" (étape de compilation réalisée par "ld") et les liens symboliques de fichiers, créés avec "ln" ...  :Wink: .

Même si dans les deux cas on parle de "liens", "liaisons" et "symboles", les deux notions n'ont strictement rien à voir l'une avec l'autre.

La raison pour laquelle il faut recompiler OO.o, c'est, en gros, parce que les liens internes vers les fonctions de bibliothèques qui avaient été introduits à la compilation dans les exécutables OO ne sont plus valables suite à la mise à jour de ces bibliothèques.

Vu que l'historique de compilation (sources, makefiles, fichiers objets, ...) ne sont pas conservés (/var/tmp/portage ... ! ), il n'est pas possible de ne refaire que l'édition des liens. Il faut tout recréer de A à Z.

----------

## gglaboussole

En fait non je ne confond pas   :Wink:   j'ai déjà vu certains gentooistes fainéants  qui liaient symboliquement l'ancienne librairie à la nouvelle (à moins que ce ne soit l'inverse !), ainsi l'exécutable est leurré puisque les liens qu'il comporte pointent vers la bonne librairie, quand bien elle aurait changer de nom... mais c'est de la bidouille crade, qui ne marche pas toujours et qui de toute façon si elle marche ne permet pas de profiter des dernières améliorations de la lib...

----------

## Fenril

C'est bien ce qui me semblait, je suis parti pour une recompilation.

Tiens ça ne serait pas une idée ça, de pouvoir recompiler que ce qui est nécessaire dans un paquet, et ainsi supprimer le défaut inhérent à toute distribution source ? C'est du cas par cas, et ça rajouterai une bonne complexité au tout, mais pourquoi pas ? Du genre la possibilité de gérer séparément dans le Makefile les fichiers objets générés lors de la compilation ? C'est qu'une idée comme cela...

----------

## gglaboussole

Je ne pense pas que ce soit possible... c'est l'inconvénient des libs partagées... (ou alors faut du "static" partout, ou garder des tas de versions slottées )

En revanche portage 2.* peut préserver tes binaires d'un cassage ou t'indiquer si tu souhaites expressément mettre à jour une lib la liste des recompilations nécessaires...et tu prends ta décision en fonction du temps que tu veux y consacrer et des "risques" que tu veux prendre

----------

