| 1 |
I've come across a fun little issue lately when building sparc64 |
| 2 |
livecd's... |
| 3 |
|
| 4 |
Some shared libaries need -fPIC to compile (libpcap for example), that's |
| 5 |
an easy fix. However, some libraries compile fine with -fpic (libkudzu |
| 6 |
for example). The issues is that shared libraries compiled with -fpic |
| 7 |
can cause issues later on depending on how they are included into a |
| 8 |
dependent application. An example is is hwsetup, which is compiled with |
| 9 |
-fPIC by default, but depends on libkudzu which is compiled with -fpic |
| 10 |
by default. This causes hwsetup to fail during compilation. This only |
| 11 |
seems to be a issue with sparc64 and not sparc, as sparc64 still has a |
| 12 |
lot of the same register restrictions that sparc has but with a higher |
| 13 |
memory footprint. |
| 14 |
|
| 15 |
Im tempted to say that everything on sparc should be compiled with -fPIC |
| 16 |
over -fpic. This is how Debian does it (i believe they do it for every |
| 17 |
arch). The reason i say this is because there is no way to tell if a |
| 18 |
-fpic shared library will be a problem down the line in another |
| 19 |
application. Short of building the whole portage tree repeatedly. |
| 20 |
|
| 21 |
Right now im just fixing them as i come across them, but i'd like to |
| 22 |
know anyones thoughts on this issue. |
Archives