expertenaustausch > comp.os.* > comp.os.unix.programming

Heinz-Mario Frühbeis (18.11.2017, 14:25)
Hallo,

wenn ich jetzt auf dem Entwicklerrechner libboost-dev installiere, dann
-dev, weil ich damit "develope", also entwickele.
Welche Bibliothek braucht es denn dann auf einem anderen Rechner, wo es
"nur" laufen soll?
Braucht es da auch die libboost-dev, oder reicht / braucht es da eine
andere?

Mit Gruß
Heinz-Mario Frühbeis
Marcel Mueller (18.11.2017, 18:27)
On 18.11.17 13.25, Heinz-Mario Frühbeis wrote:
> Hallo,
> wenn ich jetzt auf dem Entwicklerrechner libboost-dev installiere, dann
> -dev, weil ich damit "develope", also entwickele.
> Welche Bibliothek braucht es denn dann auf einem anderen Rechner, wo es
> "nur" laufen soll?
> Braucht es da auch die libboost-dev, oder reicht / braucht es da eine
> andere?


Kommt darauf an, wie Du gelinkt hast. Im Fall von statisch brauchst Du
gar nichts, bei shared Library nur die ohne -dev, allerdings in der
exakt passenden Version.

Marcel
Heinz-Mario Frühbeis (18.11.2017, 22:07)
Am 18.11.2017 um 17:27 schrieb Marcel Mueller:
> On 18.11.17 13.25, Heinz-Mario Frühbeis wrote:
> Kommt darauf an, wie Du gelinkt hast. Im Fall von statisch brauchst Du
> gar nichts, bei shared Library nur die ohne -dev, allerdings in der
> exakt passenden Version. Ok, danke.


Nur mal noch gefragt bezgl. der _exakten_ Version:
Wie sieht denn da die exakte Definition von 'exakt' aus?

Was ich meine ist, auf meinem Notebook habe ich ein Minimal-Arch Linux
drauf, was jetzt bestimmt schon drei Jahre drauf ist und _nie_ irgendein
Update bekam.
Auf dem Entwickler-Rechner habe ich mittlerweile Linux Mint 18.1 mit
_allen_ Updates drauf.
Ich würde jetzt nicht wetten, aber wenn, dann z. Bsp. das sich bei X
irnkwas geändert hat?

Von meinen Bibliotheken mal abgesehen, habe ich folgende Verlinkungen:
-lImlib2 -lX11 -lXext -ldl -lpthread -lrt

Und das läuft anstandslos auf meinem Linux Mint 18.1-Rechner, wie auch
auf meinem Notebook mit drei Jahren altem Minimal-Arch Linux...
Stefan Enzinger (20.11.2017, 11:40)
On 2017-11-18 21:07, Heinz-Mario Frühbeis wrote:

> Nur mal noch gefragt bezgl. der _exakten_ Version:
> Wie sieht denn da die exakte Definition von 'exakt' aus?


Boost entwickelt sich schnell und wird schnell inkompatibel.
Darum solltest du statisch linken.

ldd sagt dir, was dein kompiliertes Programm erwartet.

$ ldd /bin/nano
linux-vdso.so.1 => (0x00007ffdea7e0000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
(0x00007f702525e000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f7025035000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7024c6a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7024a66000)
/lib64/ld-linux-x86-64.so.2 (0x00005627aa0d4000)

lg
Rainer Weikusat (20.11.2017, 18:24)
Stefan Enzinger <mindoms> writes:
> On 2017-11-18 21:07, Heinz-Mario Frühbeis wrote:
>> Nur mal noch gefragt bezgl. der _exakten_ Version:
>> Wie sieht denn da die exakte Definition von 'exakt' aus?

> Boost entwickelt sich schnell und wird schnell inkompatibel.
> Darum solltest du statisch linken.


Holy non-sequitur, Batman!

Falls zueinander inkompatible Versionen von Boost faelschlich behaupten,
dieselbe Funktionalitaet anzubieten, waere das (was uebrigens zu
demonstrieren stuende) ein Fehler in der Bibliothek.
Marcel Mueller (20.11.2017, 20:41)
On 20.11.17 17.24, Rainer Weikusat wrote:
>> Boost entwickelt sich schnell und wird schnell inkompatibel.
>> Darum solltest du statisch linken.

> Falls zueinander inkompatible Versionen von Boost faelschlich behaupten,
> dieselbe Funktionalitaet anzubieten, waere das (was uebrigens zu
> demonstrieren stuende) ein Fehler in der Bibliothek.


Ich glaube, darauf wollte er nicht hinaus.
Das Problem ist eher, bis die von einem favorisierte Boost-Version
Einzug in alle Distributionen genommen hat, können Jahre vergehen.

Marcel
Matthias Andree (20.11.2017, 23:02)
Am 18.11.2017 um 13:25 schrieb Heinz-Mario Frühbeis:
> Hallo,
> wenn ich jetzt auf dem Entwicklerrechner libboost-dev installiere, dann
> -dev, weil ich damit "develope", also entwickele.
> Welche Bibliothek braucht es denn dann auf einem anderen Rechner, wo es
> "nur" laufen soll?
> Braucht es da auch die libboost-dev, oder reicht / braucht es da eine
> andere?


Verwendest Du überhaupt etwas, das gelinkt werden müsste? Viele der
Bibliotheken bestehen nur aus C++-Headern und bedürfen keines Linkens
zur Laufzeit. Ansonsten siehe weitere Antworten hier.
Stefan Enzinger (21.11.2017, 22:54)
On 2017-11-20 19:41, Marcel Mueller wrote:
> On 20.11.17 17.24, Rainer Weikusat wrote:
> Ich glaube, darauf wollte er nicht hinaus.
> Das Problem ist eher, bis die von einem favorisierte Boost-Version
> Einzug in alle Distributionen genommen hat, können Jahre vergehen.


Stimmt, danke.

Es bringt aber auch wenig wenn man gegen
libboost_system.so.1.54.0
linkt aber am System dann
libboost_system.so.1.58.0
installiert ist. Da kann das noch so kompatibel sein, wenn der filename
net passt.

Da gibt's auch keine Links von
libboost_system.so -> libboost_system.so.1.58.0 oder ähnliches,
zumindest unter ubuntu, siehe:


Code der mit mehreren boost versionen kompatibel sein muss ist auch
gleich voller:
#if BOOST_VERSION >= 3
....

bzw:


lg, stefan
Thomas Jahns (22.11.2017, 11:51)
On 11/21/2017 09:54 PM, Stefan Enzinger wrote:
> Es bringt aber auch wenig wenn man gegen
> libboost_system.so.1.54.0
> linkt aber am System dann
> libboost_system.so.1.58.0
> installiert ist. Da kann das noch so kompatibel sein, wenn der filename net passt.


ld.so braucht zunächst mal einen passenden soname, der sollte in dem Fall
libboost_system.so.1 sein und auch so in der Library und dem Programm vermerkt sein.

> Da gibt's auch keine Links von
> libboost_system.so -> libboost_system.so.1.58.0 oder ähnliches, zumindest unter
> ubuntu, siehe:
>


Der .so -Link ist immer im entsprechenden -dev Paket.

> Code der mit mehreren boost versionen kompatibel sein muss ist auch gleich voller:
> #if BOOST_VERSION >= 3
> ...
> bzw:
>


Code zur Kompilationszeit ist natuerlich noch ein anderes Thema.

Thomas
Heinz-Mario Frühbeis (22.11.2017, 13:16)
Am 18.11.2017 um 17:27 schrieb Marcel Mueller:
> On 18.11.17 13.25, Heinz-Mario Frühbeis wrote:
> Kommt darauf an, wie Du gelinkt hast.


'Tschuldigung, kurze Zwischenfrage:
Wie ist das denn jetzt überhaupt mit dem Linken?
Ich ging bis jetzt eigentlich davon aus, daß _immer_ gelinkt werden muss.

Also imF für QT Creator ungefähr so was):

LIBS += -L$$HOME/EB_IDA/Libs/ -Wl,-rpath=$$HOME/EB_IDA/Libs/ -lIDA -ldl
-lpthread -lrt

INCLUDEPATH += $$HOME/EB_IDA/Includes/
DEPENDPATH += $$HOME/EB_IDA/Includes/

Aber in einer cpp-Datei habe ich

#include <boost/interprocess/managed_shared_memory.hpp>

und das funktioniert "trotzdem"<?!>.
Auch sonst habe ich in keinem Part des Projekts gegen boost gelinkt...

In einem anderen kleinen Test-Projekt habe ich

LIBS += -I/usr/include -lImlib2 -lX11 -lXext -ldl -lpthread -lrt

, aber wenn ich das (LIBS +=...) austrage, dann gibt es kein X mehr...

Wann muss denn jetzt gelinkt werden, und wann nicht?
Stefan Enzinger (23.11.2017, 02:20)
On 2017-11-22 10:51, Thomas Jahns wrote:
> On 11/21/2017 09:54 PM, Stefan Enzinger wrote:
> ld.so braucht zunächst mal einen passenden soname, der sollte in dem Fall
> libboost_system.so.1 sein und auch so in der Library und dem Programm vermerkt se

$ readelf -d /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 | grep
soname
0x000000000000000e (SONAME) Library soname:
[libboost_system.so.1.58.0]

>> Da gibt's auch keine Links von
>> libboost_system.so -> libboost_system.so.1.58.0 oder ähnliches, zumindest unter
>> ubuntu, siehe:
>>

> Der .so -Link ist immer im entsprechenden -dev Paket.


Tatsaechlich, ergibt natuerlich auch Sinn:
Thomas Jahns (23.11.2017, 14:54)
On 11/23/17 01:20, Stefan Enzinger wrote:
> $ readelf -d /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 | grep soname
>  0x000000000000000e (SONAME)             Library soname:
> [libboost_system.so.1.58.0]


wenn jede Version nur mit sich selbst kompatibel ist ist das natürlich auch eine
Ansage. Das ruft dann wohl nach -Wl,-Bstatic -lboost_system -Wl,-Bdynamic oder
libboost_system immer mitliefern.

Thomas
Ähnliche Themen