1 |
On Wed, Jan 08, 2014, Rick "Zero_Chaos" Farina wrote: |
2 |
> Or we could just stop randomly moving libs across the system and |
3 |
> breaking things then hackmeating things back to a "working" state with |
4 |
> gen_ld_script. |
5 |
> |
6 |
> The whole reason for having gen_ld_script is because people wanted |
7 |
> dynamic libs in / and static libs in /usr (which seems insane) and it |
8 |
> broke everything (because that idea is insane). |
9 |
|
10 |
No it's not: it makes no sense whatsoever to have static libs in /; they |
11 |
can only ever be used when one is compiling software, so by definition |
12 |
have /usr available. And moving a dynamic lib is perfectly fine in terms |
13 |
of the system running. That's what /etc/ld.so.cache is for. |
14 |
|
15 |
I agree that it hasn't been done brilliantly fwtw. But there is no |
16 |
reason on earth not to make the change proposed until such time |
17 |
as an alternative impl is put in place; it can only make /lib more |
18 |
consistent. |
19 |
|
20 |
> Maybe we could just |
21 |
> install all the libs together (either / or /usr) and stop pretending |
22 |
> that what we are doing isn't wrong? |
23 |
|
24 |
I'm still at a loss to understand why building the pkg with libdir=/lib |
25 |
and then simply moving the static libs to /usr is not an option. |
26 |
/usr/lib is automatically looked up by the linker, so that won't affect |
27 |
builds: the only issue I can see would be a minor edit of any pkgconf |
28 |
file, if libs are under a subdir, and that only affects static linking. |
29 |
|
30 |
In no event, could not having static libs available under /lib be an |
31 |
issue at startup, in stark contrast to dynamic ones. So the ld_script |
32 |
approach seems really odd, no doubt a result of my ignorance. If all |
33 |
else failed wrt libtool, one could easily symlink static libs under |
34 |
/usr/lib to their lt install location under /lib. |
35 |
|
36 |
-- |
37 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |