Comment 26 for bug 263773

Hi Iain,

first off, what I think that change will result in is -DLARGE_FILE_OFFSET
being passed to ghc6 internal libraries when compiled as C-code. I'm not
entirely sure if this will match/won't match the compiler flags for cabalized
packages. So the possibility of a different ABI for packages would result if
these would call c-code dependendant on -DLARGE_FILE_OFFSET being present or
not (or more specific, if the (external) c-ABI would change if
DLARGE_FILE_OFFSET was present or not).
Imho that means that only haskell libraries calling external c-code dependant
on that compiler flag would be affected. One candidate that comes to my mind
would be gtk2hs, and I'll certainly check if its ABI will stay the same before
applying the patch.

Did I miss s.th.?

On Friday 19 September 2008 22:18:38 Iain Lane wrote:
> To be honest this feels very risky to me, and I'm having grave doubts
> that anything other than a full transition is good enough. I can quite
> easily see this introducing unforseen regressions that are only picked
> up once Intrepid is released and people start hammering on it seriously.
> We then get into SRUs which are a lot of hassle for many people. I don't
> want people to think that Ubuntu is a broken platform for Haskell (yes,
> I know that the presence of this bug introduces a degree of breakage but
> IMO it's not as severe as the risk of the fix).

Fair enough. There certainly is the possibility that haskell libraries
depending on other haskell libraries would fail to build after that change
(w.o. rebuilding the former libraries beforehand).

>
> So consider this my vote for no change without a full transition (and
> then we may as well go to 6.8.3). This is clearly unfortunate for Darcs
> but I believe that the risks outweigh the potential benefits.

What other options do we have to fix darcs? Is there any workaround we could
apply to darcs?

Cheers and thanks for your help,
    Stefan.