| 1 |
alright, so embedded needs/wants a broken out libgcc and there are |
| 2 |
apparently archs that need libgcc in /lib for binaries used to bring up |
| 3 |
the system (i hear maybe arm and ia64?? more info here would be |
| 4 |
appreciated). the question is how are we going to break stuff out |
| 5 |
-cleanly- without, erm... breaking stuff. |
| 6 |
|
| 7 |
how are we going to handle slots? |
| 8 |
how about multiple installed versions of libgcc when they all have the |
| 9 |
same soversion? i dont think we can do that if they live in /lib... |
| 10 |
another problem: how are we going to handle archs where the soversion is |
| 11 |
2 for the same libgcc that has soversion 1 on another arch (where does |
| 12 |
this happen btw? alpha and...)? how could we possibly slot that |
| 13 |
correctly with the current support available in portage? |
| 14 |
what about gcc itself? we'll still need to compile the static libs and |
| 15 |
put them in a versioned directory, along with .so symlinks. |
| 16 |
|
| 17 |
i've been working on trying to make stuff more modular and maintainable |
| 18 |
with toolchain.eclass, but i need feedback. lots of it, and from more |
| 19 |
than just toolchain@g.o... |
| 20 |
|
| 21 |
here's a quickie libgcc ebuild for starters. with multilib enabled here, |
| 22 |
it just installs: |
| 23 |
|
| 24 |
/lib32/libgcc_s.so.1 -> libgcc_s-3.4.2.so.1 |
| 25 |
/lib32/libgcc_s-3.4.2.so.1 |
| 26 |
/lib64/libgcc_s.so.1 -> libgcc_s-3.4.2.so.1 |
| 27 |
/lib64/libgcc_s-3.4.2.so.1 |
| 28 |
|
| 29 |
(the libgcc_s_32.so symlink to /lib32/libgcc_s.so.1 would need to be |
| 30 |
created by gcc itself and placed in the versioned directory) |
| 31 |
|
| 32 |
anyone who wishes to beat some sanity into me is welcome to do so ;) |
Archives