| 1 |
On Monday 28 April 2014 10:30:58 Michael Haubenwallner wrote: |
| 2 |
> IIRC, aixdll is needed by portage itself for these tasks: |
| 3 |
> *) extract the binary dependencies for preserve-libs feature |
| 4 |
> *) merge library archives containing shared objects - even with |
| 5 |
> "aix-soname". |
| 6 |
|
| 7 |
Then I think it needs to be installed before gcc which builds aix-soname |
| 8 |
libraries, but not necessarily any earlier than that. |
| 9 |
|
| 10 |
> > I don't have a good idea of what texinfo might possibly be used for, |
| 11 |
> > except for makeinfo for which there is now a more general workaround in |
| 12 |
> > place. Is it used for anything else? |
| 13 |
> |
| 14 |
> IIRC nope, makeinfo might have been the only reason. |
| 15 |
|
| 16 |
I'll remove it, then. |
| 17 |
|
| 18 |
> |
| 19 |
> > sys-apps/diffutils is apparently needed to work around |
| 20 |
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14251 , but I don't see how |
| 21 |
> > -- that bug needs gnu coreutils, not diffutils. Do you know what this is |
| 22 |
> > for? |
| 23 |
> |
| 24 |
> AFAICT, the comparison stage in gcc uses cmp. IIRC I've seen failures when |
| 25 |
> that is not the GNU diffutils' cmp. |
| 26 |
|
| 27 |
Ah yes, good point. |
| 28 |
|
| 29 |
> > Moreover, do you know whether this workaround is still necessary for the |
| 30 |
> > aix versions we support? |
| 31 |
> |
| 32 |
> Comment it out or drop it, and the buildbots here whill tell. |
| 33 |
|
| 34 |
Alright, I'll give it a test later. |
| 35 |
|
| 36 |
> > If I understand correctly, dev-libs/libiconv is a dependency for a lot of |
| 37 |
> > programs, including gcc, and as such needs to be installed before gcc. |
| 38 |
> > This is clear. Are there any other packages in the early bootstrap that |
| 39 |
> > depend on it? Could it be installed immediately before gcc? I see that it |
| 40 |
> > was recently moved from immediately before gcc, to one of the first |
| 41 |
> > things in stage3. Why is this? What hell are you avoiding this way that I |
| 42 |
> > should retain? |
| 43 |
> |
| 44 |
> Okay, you've asked: The "hell with shared libiconv.a" is this one: |
| 45 |
> |
| 46 |
> [snip] |
| 47 |
|
| 48 |
Hellish indeed. |
| 49 |
|
| 50 |
libiconv used to be built immediately before gcc, but recently you moved it to |
| 51 |
very early stage3. Why is that? As far as I can see, gcc is the earliest |
| 52 |
stage3 package that uses iconv. Or is there a hidden dependency somewhere? |
| 53 |
Evidently you changed it in response to a bug, but I don't see it. |
| 54 |
|
| 55 |
-- Ruud |
Archives