Connaissance des files créés / installés après la construction à partir de la source
J'ai une tâche à accomplir qui implique la construction d'une série de bibliothèques à partir de source en utilisant configure; make; make install configure; make; make install configure; make; make install . Les bibliothèques générées et les files misc seront mis sur un système embedded compatible avec l'environnement de construction.
Ma question est de savoir comment savoir quels files ont été installés et où je peux les saisir et les déplacer vers l'environnement embedded?
- Lors de la mise à niveau d'un package avec make install, dois-je exécuter la désinstallation pour le package préexistant en premier?
- Mémoire server Linux FOG
- téléchargez tous les RPM à partir d'un méta-package
- Pourquoi l'approvisionnement en .screenrc n'est-il pas pris en charge?
- apt-get source: Commande inconnue "source"
Est-ce qu'un journal créé en cours d'exécution de make install ? Ou est-ce que je fais simplement la sortie de make install dans un file?
Des suggestions, des astuces et astuces seraient grandement appréciés.
- Problème avec la compilation de PHP sur Centos
- Quel est le code source selinux?
- Linux ip route correspondant à la source ip
- Code source pour les utilitaires Linux et les démons
- rsync ne supprimera pas le file qui a été supprimé sur la source
- Paquets Gnome 3
- Compilation du kernel à partir de la source (pour Xen), puis-je utiliser un kernel ordinaire?
- Duplicate rsync source
2 Solutions collect form web for “Connaissance des files créés / installés après la construction à partir de la source”
Vous pouvez utiliser make -n install pour voir ce que fera l'installation. Notez que parfois l'une des commands qu'il exécutera est une autre make dans un directory enfant; make -n n'est pas récursif.
Si le logiciel utilise le script de configuration standard gnu autoconf, vous devriez pouvoir
./configure --prefix=/my/directory/for/embedded/system [...]
et tout sera installé sous ce préfixe.
Vous pouvez essayer de le copyr vers les locations «standard» du système embarqué, mais le logiciel peut ou non fonctionner correctement.
Si rien d'autre, vous pouvez utiliser ceci comme un moyen de rassembler des inventaires sur ce que le logiciel installe.
Autre astuce – essayez de modifier le Makefile pour redéfinir la command qui installe les files (souvent "installer" ou "installer.sh"). Remplacez-le par votre propre version qui écrit son action dans un file journal.
Si vous voulez une solution plus légère pour aider à gérer ce (vs RPM ou dpkg), regardez GNU Stow.
C'est la première raison d'utiliser un système d'emballage, tel que RPM (Red Hat) ou Deb (Debian).
Pour les systèmes Linux embarqués, le système de gestion de packageage habituel est opkg , un successeur d'ipkg, qui est basée sur le format deb, et est généralement facile à adapter à partir des instructions de construction de packageages Debian.