Kompiliertes Programm weitergeben

Martin Baumann · 29 Sep. 2005

Hi,

ich schon wieder. Ich habe ein Projekt, dass die Bibliotheken VTK, QT und Mesa verwendet, kompiliert (und es läßt sich Danke Eurer Hilfe nun sogar starten).

Meine Frage:
Ist es relativ leicht möglich eine Version des Projektes zu erzeugen, die alle verwendeten Komponenten der anderen Bibliotheken beinhaltet? D.h. diese spezielle Version des Projekts wird auf einen anderen Rechner kopiert und läßt sich direkt starten, ohne dass die Bibliotheken installiert werden müssen?

Vielen Dank,
Martin

TeXpert · 29 Sep. 2005

entweder Bibliotheken installieren oder Programm statisch linken wäre das einfachste. An sich solltest Du nur sicherstellen dass entsprechende Pakete mit den Bibliotheken istalliert sind.

traffic · 30 Sep. 2005

Welche Distributionen sind involviert? Falls es um SuSE-, RedHat-, Fedora- und Mandriva-Systeme geht, würde ich ein RPM erstellen, das alle benötigten Bibliotheken nach "/usr/lib/<Names des Programms" (nicht /usr/lib, Begründung siehe unten) und das Programm selbst nach "/usr/bin" installiert.

Dazu schreibst Du dann ein kleines Start-Skript, das noch den LD_LIBRARY_PATH richtig setzt, und fertig. Warum die Bibliotheken nicht direkt nach "/usr/lib" gehören: Auf den anderen Systemen könnten schon RPMs installiert sein, die gleichnamige Bibliotheken enthalten, in dem Fall gäbe es einen Konflikt.

Der Inhalt des RPMs könnte in etwa so aussehen:

/usr/bin/<Name des Programms>: Start-Skript
/usr/lib/<Name des Programms>: Verzeichnis, in dem die eigentliche ausführbare Datei sowie die Bibliotheken liegen
/usr/lib/<Name des Programms>/<Ausführbare Datei>
/usr/lib/<Name des Programms>/<Bibliotheken>

Das Start-Skript ist eine ganz einfache Sache, könnte ungefähr so aussehen:

Code:

#!/bin/sh

if [ "$LD_LIBRARY_PATH" ] ; then
   LD_LIBRARY_PATH=/usr/lib/<Name des Programms>:"$LD_LIBRARY_PATH"
else
   LD_LIBRARY_PATH=/usr/lib/<Name des Programms>
fi

export LD_LIBRARY_PATH

exec /usr/lib/<Name des Programms>/<Ausführbare Datei>

Hinweise zu Anleitungen, wie man RPMs erstellt, findest Du im Forum mit der Suchfunktion, bei konkreten Fragen helfe ich auch gerne.

Falls außer den oben genannten Distributionen auch weitere im Spiel sind, könnte autopackage eine Alternative sein. Das ist eine Art SETUP.EXE für Linux. Ich würde es aber nur machen, wenn es anders nicht geht, weil die meisten Anwender konventionelle, zur Distribution passende Pakete bevorzugen.

Noch zwei Bemerkungen zu den Bibliotheken:

- Falls Du weißt, dass die involvierten Distributionen entweder alle mit GCC =< 3.3 oder alle mit GCC >= 3.4 übersetzt sind, kannst Du Qt weglassen. Qt ist bei jeder Distribution dabei und gehört auf jeden Rechner.

- Falls die involvierten Distributionen teils mit GCC =< 3.3 und teils mit GCC >= 3.4 übersetzt sind, würde ich vorsichtshalber sämtliche Bibliotheken einschließlich Qt statisch linken, um möglichen und fiesen Kompatibilitätsproblemen aus dem Weg zu gehen.

TeXpert · 30 Sep. 2005

traffic schrieb:
- Falls Du weißt, dass die involvierten Distributionen entweder alle mit GCC =< 3.3 oder alle mit GCC >= 3.4 übersetzt sind, kannst Du Qt weglassen. Qt ist bei jeder Distribution dabei und gehört auf jeden Rechner.

das ist nicht richtig, Qt ist nicht essentiell. Du brauchst bei einem reinen GTK-System (Gnome) keine Qt-Libs.

traffic · 30 Sep. 2005

TeXpert schrieb:
das ist nicht richtig, Qt ist nicht essentiell.

Das ist schon klar, ich meinte auch gar nicht, dass es überall installiert sein muss, sondern dass man mehr oder weniger erwarten kann, dass jeder es bei Bedarf installieren kann, weil es bei jeder Distribution dabei ist. Meine libqt-mt.so ist 8,6 MB groß (not stripped), deswegen denke ich, dass man den Platz auch sparen kann. Schaden kann es allerdings auch nicht, lieber eine Bibliothek zuviel als zuwenig mitzuliefern.

TeXpert · 30 Sep. 2005

OK, von dem Standpunkt passt das

allerdings braucht sich der OP dann keien Gendanken zumachen, libvtk kann ich mir auch mit apt-get nachinstallieren.. (gibts für Suse bestimmt auch) und Mesa gibts auch für alle Distris, d.h. irgendwie kann man alles voraussetzen

Martin Baumann · 2 Okt. 2005

Das klingt schon recht vernünftig. Ich habe mir mal verschiedene Sachen der RPMs angeschaut. Da werde ich mich jetzt mal einarbeiten. Das ist sicher sinnvoll! Danke für den Hinweis.

Eine Sache noch:
Die verschiedenen Libs müssen nicht nur auf dem System installiert sein, sondern verschiedene Parameter und Einstellungen müssen bei der Installation / Konfiguration beachtet werden. Ist sowas auch per RMP möglich? D.h. bei der Installation meines Projektes per RPM werden automatisch die anderen Bibliotheken anders konfiguriert / mit den bestimmten Parametern neu installiert?

Gruss, Martin

oc2pus · 2 Okt. 2005

schaust du hier:

[Frage] wie RPMs richtig bauen
http://www.linux-club.de/viewtopic.php?t=29782

TeXpert · 2 Okt. 2005

RPM bauen ist eine Sache, aber wenn die Lib schon auf dem System ist...

hier müsstest Du u.U. die Library dann in ein lokales Verzeichnis installierne und das programm mit einem Wrapper aufrufen, der LD_LIBRARY_PATH passend setzt.

Martin Baumann · 2 Okt. 2005

Aha. Wie würde das dann genau aussehen?
Ich liefere die Libs schon fertig mit? Auch mein Projekt fertig kompiliert? Und dazu noch ein Shell-Script das die Umgebungsvariablen anpasst und danach das Programm startet?

Wenn ich das ganze unter Suse 9.3 kompiliere, unter welchen anderen Systemen wird das dann noch laufen? Auch unter Debian und Co?

Gruss, Martin

TeXpert · 2 Okt. 2005

es kommt drauf an

Hauptproblem: die stdlib, Debian nutzt bis stable (und z.zt. noch testing) eine ältere lib als SID (und wahrscheinlich auch 9.3)

ohne zu testen kannst Du das nicht weitergeben. Jetzt kommts, da es sich dabei mit hoher Wahrscheinlichkeit um ein GPL-Programm handelt (Qt... oder hast Du eine Lizenz gekauft?) schnür ein passendes Paket mit den Autotools und lass die Leute den 3-Sprung selber machen.

Binärpakete, die _nicht_ statisch gelinkt sind problemlos weiterzugeben ist IMHO ein fast aussichtsloses Unterfangen...

Martin Baumann · 2 Okt. 2005

Das Projekt hat bereits makefiles. Unter anderem existiert eine Datei Makefile.inc in der die Pfade zu den Libs und zu den Includings der Libraries einzutragen sind. Hierin sehe ich momentan ein Problem. Wie werden die Pfade in dieser Makefile.inc beim Benutzer aktualisiert, wenn ich ein RPM erzeuge? Momentan muss der Benutzer das von Hand erledigen. Gibts eine Möglichkeit dieses zu automatisieren?

Ihr könnt euch ja mal das Projekt anschauen:
http://www.hiflow.de/HiVision/

Viele Leute haben sich für das Programm interessiert, aber leider hatten fast alle Probleme mit der Installation. Ich hatte auch einige Probleme.

Martin

traffic · 3 Okt. 2005

Ich verstehe nicht ganz, was Du mit dem "Konfigurieren der Bibliotheken" meinst. Meinst Du den Aufwand zum Anpassen der Makefiles an das System, auf dem das Binary erstellt wird? Das hat sich erledigt, sobald das Binary fertig ist!

Also: Die Abhängigkeiten sind:

1. glibc
2. libstdc++
3. X11
4. OpenGL
5. Qt
6. VTK

1. Ist auf jedem System vorhanden -> kein Problem
2. Könnte nur in äußerst theoretischen Fällen nicht vorhanden sein -> kein Problem
3. Muss auf jedem System, auf dem grafische Programme laufen sollen, sowieso vorhanden sein -> kein Problem
4. Wird von jeder Distribution mitgeliefert, ist hinreichend standardisiert, soll jeder Benutzer bei Bedarf selbst installieren -> kein Problem
5. Wird von jeder Distribution mitgeliefert, könnte höchstens wegen der CXXABI-Geschichte problematisch sein -> kein Problem, gegen das Du irgendwas tun könntest
6. Könnte noch am ehesten ein Problem sein, weil es wiederum andere Abhängigkeiten hat und weder bei Fedora noch bei SuSE mitgeliefert wird

Nach meiner Recherche besteht VTK aus mehreren einzelnen Bibliotheken, von denen einige wiederum optional sind, und enthält keine einzige Konfigurationsdatei, also verstehe ich das Problem ehrlich gesagt nicht.

Mein Vorschlag: Pack einfach Dein Binary und Deine VTK-Bibliotheken in ein RPM mit einem Shell-Wrapper nach dem oben beschriebenen Muster, zu konfigurieren gibt es da sonst nichts. Die bisherige Konfiguriererei war ja nur zum Kompilieren notwendig. Wenn es gar nicht anders geht, dann mach das ganze zweimal, einmal mit dem GCC =< 3.3 und einmal mit dem GCC >= 3.4, fertig.

Martin Baumann · 3 Okt. 2005

Das macht mir Mut!

Mit "Konfigurieren der Bibliotheken" meine ich folgendes:
- zum Kompilieren von VTK muss CMake verwende werden. Ausserdem sollen die libs und der source nach der Kompilierung in verschiedenen Ordnern stehen. Das macht einige Parameter bei der Installation notwendig
- bei VTK muss der Hybrid-Modus aktiviert sein
- bei QT muss der thread-flag gesetzt werden (für OpenGL)
- für HiVision müssen in Makefile.inc Pfade zu den Bibliotheken gesetzt werden

Wenn ich aber die fertige Binary liefere ist das wohl nicht notwendig.

Ich habe hier mal meine Vorstellung von der Spec File:

# HiVision's Spec-File

Summary: a visualization platform (2D and 3D grids)
Name: hivision
Version: 2.0
Release: 2
Copyright: GPL
Group: Productivity/Graphics/Visualization/Graph
URL: http://www.hiflow.de/HiVision/
Packager: Martin Baumann <Martin.Baumann@stud.uni-karlsruhe.de>

%description
HiVision is a visualization platform including advanced visualization techniques for the analysis and exploration of data supplied by numerical simulation. Although primarily developed for visualisation in the area of computational fluid dynamics as part of the HiFlow project , the HiVision framework is discipline independent and may be advantageously used in various areas such as structural mechanics and reactive flow simulation. HiVision has been developed using the powerful C++ Visualization Toolkit library (VTK) and for the graphical user interface, the Qt.

%prep
mkdir /usr/lib/vtk4.2

%build
#nothing to do as there are already binaries

%install
cp hivisionmain /usr/bin
cp hivision.sh /usr/bin
cp vtk4.2/lib/* /usr/lib/vtk4.2

%files
/home/martin/local/source/HiVision2.0.2/Bin/hivisionmain
/home/martin/local/source/HiVision2.0.2/Bin/hivision.sh
/home/martin/local/source/HiVision2.0.2/vtk4.2/lib/*

DIe hivision.sh muss aber dann vom Endbenutzer angepasst werden; sehe ich das richtig?
Wieviel Prozent meiner (ersten) Spec File sind zu verwenden? Habe ich etwas grundlegendes falsch gemacht?

Gruss, Martin

oc2pus · 3 Okt. 2005

Code:

%prep
mkdir /usr/lib/vtk4.2

%build
#nothing to do as there are already binaries

%install
cp hivisionmain /usr/bin
cp hivision.sh /usr/bin
cp vtk4.2/lib/* /usr/lib/vtk4.2

%files
/home/martin/local/source/HiVision2.0.2/Bin/hivisionmain
/home/martin/local/source/HiVision2.0.2/Bin/hivision.sh
/home/martin/local/source/HiVision2.0.2/vtk4.2/lib/*

nein nein nein

immer eine BuildRoot definieren, dort wird zunächst alles installiert, als USER!!
BuildRoot: %{_tmppath}/%{name}-%{version}-build

mkdir -s %{buildroot}%{_bindir} bzw
mkdir -s %{buildroot}%{_libdir}

statt cp bitte install -m 755 -s verwenden bei binaries,
install -m 644 verwenden bei libraries oder sonstigen files

statt /usr/bin bitte %{buildroot}%{_bindir} verwenden
statt /usr/lib bitte %{buildroot}%{_libdir} verwenden

in der %files-Sektion:
%{_bindir}/....
%{_libdir}/...

etc ... siehe auch meinen link von oben.

TeXpert · 3 Okt. 2005

traffic schrieb:
Also: Die Abhängigkeiten sind:

1. glibc
2. libstdc++
[...]1. Ist auf jedem System vorhanden -> kein Problem
2. Könnte nur in äußerst theoretischen Fällen nicht vorhanden sein -> kein Problem

heieieiei... das kein Problem möchte ich einfach mal vorsichtig betrachten.

1. an sich ist die libc seit einigen Versionen stabil, aber wenn er die mit einer zu aktuellen Version linkt könnte es auf älteren Maschinen u.U. noch Probleme geben.

2. analog, gerade hier sind wir ja gerade in einer großen Umbruchphase (wenn er denn Debian unterstützen will...)

traffic · 3 Okt. 2005

TeXpert schrieb:
1. glibc

Das kann ein Problem sein, muss es aber nicht - zumindest nicht automatisch. Zwei Möglichkeiten: Entweder man erstellt die Binaries auf einem möglichst alten System, dann werden sie sowohl auf gleich alten als auch auf neueren Systemen laufen, oder man schaut sich mal den Hack der autopackage-Leute an:

http://www.autopackage.org/aptools.html

Diese apbuild-Tools sind für die Verwendung zusammen mit autopackage gedacht, können aber auch problemlos standalone benutzt werden. Es ist ja nicht so, als könnte man keine distributionsneutralen Binaries bauen. Mozilla macht es doch seit jeher ohne größere Probleme - man muss nur aufpassen und zum Bauen am besten das ältestmögliche System nehmen, auf dem die Software gerade noch kompilierbar ist.

TeXpert schrieb:
2. libstdc++

Eben. Deswegen sag ich ja: Wenn es gar nicht anders geht, einfach zweimal bauen, einmal mit dem alten g++ gegen die alte libstdc++ und einmal mit dem neuen g++ gegen die neue libstdc++.

Auch hier kann man Mozilla als Vorbild nehmen: Mozilla verwendet den alten g++ und die alte libstdc++. Für alte Distributionen ist das sowieso kein Problem und für neue auch nicht, weil die neuen Distributionen auch ein Exemplar der alten libstdc++ mitliefern. Deswegen muss man es nichtmal doppelt anbieten.

Mozilla ist allerdings in der glücklichen Lage, C++ nur intern zu benutzen, für externe Bibliotheken allerdings ausschließlich auf C angewiesen zu sein. Das ist hier wegen Qt nicht der Fall, also kann das fiese CXXABI-Problem auftreten. Daran kommt man aber vorbei, indem man es, wie gesagt, doppelt anbietet.

Martin Baumann · 3 Okt. 2005

Frage:

in der %files-Sektion:
%{_bindir}/....
%{_libdir}/...

Ich habe die Dateien unter den Verzeichnissen, wie ich sie in meiner Spec File geschrieben habe. Wenn ich statt denen nun _bindir und _libdir verwende wird doch aber /usr/lib bzw. /usr/lib64 verwendet, oder? Da wird RPM sie aber nicht finden können. ???

Wo sind die Dateien der Reihe nach gespeichert?
Aus der RPM kommen sie in BuildRoot, danach werden sie mit den install-Befehlen in _bindir und _libdir kopiert. Und da sollen sie am Ende ja auch sein.
Danach müssen die Dateien im BuildRoot noch gelöscht werden, oder? Das würde ich dann unter %clean machen.
Stimmt das so wie ich das geschrieben habe?

Gruss, Martin

oc2pus · 3 Okt. 2005

Martin Baumann schrieb:
Frage:

in der %files-Sektion:
%{_bindir}/....
%{_libdir}/...

Zum Vergrößern anklicken....

Ich habe die Dateien unter den Verzeichnissen, wie ich sie in meiner Spec File geschrieben habe. Wenn ich statt denen nun _bindir und _libdir verwende wird doch aber /usr/lib bzw. /usr/lib64 verwendet, oder? Da wird RPM sie aber nicht finden können. ???

dann musst du sie im %install Schritt eben nach %{buildroot}/... kopieren

Martin Baumann schrieb:
Danach müssen die Dateien im BuildRoot noch gelöscht werden, oder? Das würde ich dann unter %clean machen.

ja

zum Beispiel so:

Code:

%clean
[ -d %{buildroot} -a "%{buildroot}" != "" ] && rm -rf %{buildroot}

Martin Baumann · 4 Okt. 2005

Um die dependencies muss ich mich nicht scheren, oder?
Ich habe gelesen, dass die automatisch festgestellt werden können.
Muss ich das von Hand aktivieren oder ist das schon so dabei?

Hier noch meine letzte Spec File:

Gruss, Martin

# ***********************************************************************************************************
# *** HiVision's Spec-File **********************************************************************************
# ***********************************************************************************************************

Summary: a visualization platform (2D and 3D grids)
Name: hivision
Version: 2.0
Release: 2
Copyright: GPL
Group: Productivity/Graphics/Visualization/Graph
URL: http://www.hiflow.de/HiVision/
Packager: Martin Baumann <Martin.Baumann@stud.uni-karlsruhe.de>
BuildRoot: %{_tmppath}/%{name}-%{version}-build

%description
HiVision is a visualization platform including advanced visualization techniques for the analysis and exploration of data supplied by numerical simulation. Although primarily developed for visualisation in the area of computational fluid dynamics as part of the HiFlow project , the HiVision framework is discipline independent and may be advantageously used in various areas such as structural mechanics and reactive flow simulation. HiVision has been developed using the powerful C++ Visualization Toolkit library (VTK) and for the graphical user interface, the Qt.

%prep
mkdir -s %{buildroot}%{_bindir}
mkdir -s %{buildroot}%{_libdir}

%build

%install
install -m 755 -s hivisionmain %{buildroot}%{_bindir}
install -m 755 -s hivision %{buildroot}%{_bindir}
install -m 644 vtk4.2/lib/* %{buildroot}%{_libdir}

%clean
[ -d %{buildroot} -a "%{buildroot}" != "" ] && rm -rf %{buildroot}

%files
%{_bindir}/hivisionmain
%{_bindir}/hivision
%{_libdir}/vtk4.2/lib/*

# HIER STEHEN DIE DATEIEN TATSAECHLICH:
#/home/martin/local/source/HiVision2.0.2/Bin/hivisionmain
#/home/martin/local/source/HiVision2.0.2/Bin/hivision
#/home/martin/local/source/HiVision2.0.2/vtk4.2/lib/*

Ich habe die Sache mit den %Files noch nicht richtig verstanden. Das RPM muss doch zwei Information über jede Datei habe:
1) wo liegt die Datei momentan auf meinem System, sonst kann sie nicht mit in die RPM aufgenommen werden
2) wo soll die Datei bei der Installation des RPM auf dem Ziel-System hinkopiert werden
oc2pus schrieb : dann musst du sie im %install Schritt eben nach %{buildroot}/... kopieren
Häh? In %install werden doch Dateien aus dem RPM-Paket auf das Zielsystem kopiert (so verstehe ich das zumindest). Mein Problem sehe ich darin, dass ich der Spec File mitteilen möchte, wo die Dateien bei mir lokal liegen.

Merkwürdig: Unter %install werden die Dateien nach %{buildroot} kopiert. Danach wird %{buildroot} unter %{clean} wieder gelöscht.

Hmm - ich bin verwirrt -

Vielleicht stehe ich auf dem Schlauch.
Ich lese sieben Quellen über RPM-Bau parallel. Aber irgendwie ...
Ich hoffe ich nerve euch nicht.

Gruß, Martin

Kompiliertes Programm weitergeben

Member

Guru

Guru

Guru

Guru

Guru

Member

Ultimate Guru

Guru

Member

Guru

Member

Guru

Member

Ultimate Guru

Guru

Guru

Member

Ultimate Guru

Member