[Fli4l_dev] Informationen zum Weekly-Tarball vom 14.12.2012 [24502]

[Bernd Kuhls]

Christoph Schulz <fli4l at kristov.de> wrote in
news:50cba8c7$0$6637$9b4e6d93 at newsspool2.arcor-online.net: 

> src:
[...]
> * diverse weitere Verbesserungen und Korrekturen [24432]-[24435], 
> [24437]-[24442], [24444], [24446]-[24448], [24452], [24454], [24471]

Hallo,

SVN rev. 24452 ("CHANGE: RPATH eliminiation moved into pkg-autotools.mk")
[1] bereitet mir beim Portieren eines wichtigen Paktes auf das neue src-
Paket einiges Kopfzerbrechen. Die binaries dieses Paketes sind gegen libs 
aus demselben Paket gelinkt, welche nicht in /usr/lib liegen, sondern in 
/usr/lib/foo/.

Mit dem bisherigen src-Paket haben diese binaries den rpath-check nicht 
bestanden, da der build-path enthalten war. Das habe ich anstatt des o.g. 
Patches für libtool in foo.mk mittels folgendem 
FOO_POST_INSTALL_TARGET_HOOKS (inspired by Debian[2]) behoben:

find $(TARGET_DIR)/usr/bin -type f -exec chrpath -r /usr/lib/foo {} \;

Dies funktioniert nun nicht mehr, da der o.g. SVN commit dafür sorgt, dass 
die binaries gar keinen rpath mehr haben, was zu folgender Fehlermeldung 
von chrpath führt:

/home/bernd/.fbr/buildroot/output/sandbox/foo/staging/usr/bin/bar: no rpath 
or runpath tag found.

chrpath kann nur bestehende rpath-Einträge ändern, aber keine neuen 
erzeugen, wenn diese fehlen. Diese nun rpath-losen binaries bestehen jetzt 
das "Checking dynamic linking" natürlich nicht mehr:

>>> foo 0.1 Error: Library libfoo.so.0 referenced by usr/bin/bar not found

Den neuen POST_CONFIGURE_HOOK aus pkg-autotools.mk zu umgehen oder in 
foo.mk rückgängig zu machen (FOO_POST_CONFIGURE_HOOKS =), geht leider 
nicht, da pkg-autotools.mk nach foo.mk ausgewertet wird. 

Gibt es eine andere Möglichkeit, das Problem zu lösen?

Viele Grüße, Bernd

[1]
https://ssl.nettworks.org/repo/browse/fli4l/trunk/src/src/fbr/buildroot/pac
kage/pkg-autotools.mk?r2=24452&r1=24434
[2] http://wiki.debian.org/RpathIssue