| 1 |
On 12/15/2010 01:25 AM, Perry Smith wrote: |
| 2 |
>> This is interesting - I've not recognized that LIBPATH overrides absolute path too. |
| 3 |
> |
| 4 |
> So, I went back and relinked my gettext libraries so that all of the ones that reference |
| 5 |
> iconv now use aboslute paths and it did solve my problem: |
| 6 |
|
| 7 |
Makes me happy to know my memory hasn't failed on this ;) |
| 8 |
|
| 9 |
> Also, the guy I'm talking to mentioned rtl_enable -s. |
| 10 |
|
| 11 |
Yes, I'm aware of rtl_enable - it is designed to enable runtime linking |
| 12 |
for shared libraries that cannot be recreated from scratch, like /lib/libc.a. |
| 13 |
|
| 14 |
> I am not familiar with portage at all but I've seen that it patches various things like the configure script, etc. |
| 15 |
> It might be easier / safer to leave the scripts alone (leave libtool do whatever it wants) and then use rtl_enable -s, |
| 16 |
> edit the resulting files, and rebuild the shared object the way you want it. |
| 17 |
|
| 18 |
It is more efficient to enable runtime linking during creation of shared objects |
| 19 |
already. Also, creating import/export files with wanted content firsthand is |
| 20 |
easier than editing them later. |
| 21 |
|
| 22 |
Using rtl_enable would still require patching libtool-related scripts, |
| 23 |
to keep libtool uniformly handling all platform specifics - this is what |
| 24 |
it is designed for. |
| 25 |
|
| 26 |
So I don't see any fit for rtl_enable with any source-based package, |
| 27 |
neither indirectly via libtool nor directly in the package's makefiles. |
| 28 |
|
| 29 |
/haubi/ |
| 30 |
-- |
| 31 |
Michael Haubenwallner |
| 32 |
Gentoo on a different level |
Archives