| 1 |
On 11/01/13 05:10, Mike Frysinger wrote: |
| 2 |
> On Wednesday 09 January 2013 06:39:37 justin wrote: |
| 3 |
>> On 09/01/13 12:29, justin wrote: |
| 4 |
>>> On 09/01/13 10:26, Diego Elio Pettenò wrote: |
| 5 |
>>>> On 09/01/2013 09:40, justin wrote: |
| 6 |
>>>>> Also the internals of the build are affected (probably through the |
| 7 |
>>>>> difference in configure). This leads to disrespected LDFLAGS and broken |
| 8 |
>>>>> tclConfig.sh. So this simple change has deep consequences. |
| 9 |
>>>> |
| 10 |
>>>> This looks like the _version_ of autoconf used is different. Is the |
| 11 |
>>>> output from the same exact system? |
| 12 |
>>> |
| 13 |
>>> Okay, did some more debugging and it seems to be not the new singly |
| 14 |
>>> inheriting eclass. |
| 15 |
>>> |
| 16 |
>>> Repeating the sequential emerge on different FS I get a completely mixed |
| 17 |
>>> result. Sometimes both compile are good, sometimes only one and sometime |
| 18 |
>>> none. |
| 19 |
>>> Could this be a problem with eautoreconf or is this autotools specifc |
| 20 |
>>> problem? |
| 21 |
>> |
| 22 |
>> I assume it is a portage problem, because the log says autoconf is run |
| 23 |
>> but configure.in didn't change. |
| 24 |
> |
| 25 |
> this sounds like bug 417355. the autom4te.cache dir gets busted (somehow). |
| 26 |
> when autotools runs, it looks at the cache dir, sees that things are up to |
| 27 |
> date, and then doesn't regen any files. |
| 28 |
> -mike |
| 29 |
> |
| 30 |
|
| 31 |
Yeah, it was because of the double patching of configure and |
| 32 |
configure.in. Cleaning the patch made it work. Interestingly in the |
| 33 |
beginning I really could reproduce a correlation between the inherit |
| 34 |
order and this breakage. Bad that was false. |
| 35 |
|
| 36 |
Thanks justin |
Archives