Carsten Schlote wrote: >>> I got some problem with a packet that stores it libraries in >>> /usr/lib/<pkgname>/lib<foo>*. This requires rpath-link options for >> the >> >> Just for curiosity....why does it store its libs in there? > > Because these libs are more or less private and shared between a > set of small tools. As autoconf allowed for such stuff I forged it that > way. > > The intention was to split off some of these libs as separate packets > later and move them to /usr/lib. > >> Note: rpath != rpath-link >> >> rpath is for runtime linking, rpath-link for compile time. >> Actually we have "rpath-link" so that the compile time linker finds >> implicit shared libs. > > I just had a short look on what fixup did (removing some hardlink stuff > and options starting with rpath) and then I used the workaround to not > call patchin. So whatever wasn't changed in configure/ltmain.sh - now > everything works fine again.
okay, so the output below is from a not fixed up library? >> patchin disables "rpath", yes >> >>> Possible workaround: >>> - use ldconfig to work around this problem on the target. >>> - use a .prepare stage without a call to patchin (my current >>> workaround). >> does this work? >> Can you post me a "readelf -d" of the programs and libs? > > $ readelf -d > platform-kp-mcb2-32/packages/mcbsystools-1.1/usr/bin/umtscardtool > > Dynamic section at offset 0x301c contains 22 entries: > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: > [libmcbtoolset.so.0] > 0x00000001 (NEEDED) Shared library: [libc.so.6] > 0x0000000f (RPATH) Library rpath: > [/usr/lib/mcbsystools] > .... Okay, that's the correct RPATH. do you have any rpath to you home directory, where you build or installed the lib? > cschl...@kplaws107lx:~/src/ptx/ptxdist-projects.git/kp-ppc$ readelf -d > platform-kp-mcb2-32/packages/mcbsystools-1.1/usr/lib/mcbsystools/libmcbt > oolset.so.0.0.0 > > Dynamic section at offset 0x1bf8 contains 21 entries: > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: [libc.so.6] > 0x0000000e (SONAME) Library soname: > [libmcbtoolset.so.0] > 0x0000000c (INIT) 0xc50 > 0x0000000d (FINI) 0x1974 > ... > > With patchin, the RPATH is gone and the tool can no longer find its lib. > The simplest solution is to allow some option to keep RPATHs. Or just > filter RPATHs pointing to /usr/lib or /lib, which are redundant anyway. The problem with the libtool stuff is, that the libtool script is autogenerated during ./configure from ltmain.sh which comes with the package. And this libtool scripts are really bash-black-magick. I've no idea how to fix it the right way. I even don't understand exactly what the sed does, I converted a patch against libtool from OE. It some things, disable rpath, otherwise path to your home directory would end up in rpath and it disables relinking during make install, the sed line with the many backslashes fixes a problem with symbol naming on blackfin. (The symbols of C-functions have two __ instead of just one _ as on all other architectures) >> I've a half finished cleanups of "patchin" here. But or rather luckily >> I've a customer project this week. > > Do you have a branch with this patchset? I could pull and test your > work. Maybe adding > some fixes or addition as time permits. It's in a very early stage, sorry, doesn't work. Not because of bugs, just because it's not finished :( Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
-- ptxdist mailing list ptxdist@pengutronix.de
