Opening a bug about this to keep track of stuff. [ebuild U ] dev-lang/ocaml-3.10.0 [3.09.3-r1] USE="X gdbm latex ncurses tk" 0 kB [1] 3.09.3-r1 built properly and now 3.10.0 does not. Failed build log to follow as attachment.
Created attachment 120382 [details] dev-lang:ocaml-3.10.0:20070526-135631.log
thanks for testing it... but well the error is different of the one for 3.09.3. Anyway, this seems related to it : generating too far calls that are not allowed on hppa (i.e., ocaml hppa native code generation is still bugged) A patch like : Index: ocaml/utils/clflags.ml =================================================================== --- ocaml.orig/utils/clflags.ml +++ ocaml/utils/clflags.ml @@ -58,7 +58,7 @@ and dump_lambda = ref false and dump_instr = ref false (* -dinstr *) let keep_asm_file = ref false (* -S *) -let optimize_for_speed = ref true (* -compact *) +let optimize_for_speed = ref false (* -compact *) and dump_cmm = ref false (* -dcmm *) let dump_selection = ref false (* -dsel *) should tell ocamlopt to always optimize for size rather than for speed but that'd still hide the problem... if it works... Is there any hppa box available for doing such tests so that I could try by myself as that'd probably be simpler for you and me ?
I just rebuilt ml based package with ocaml-3.09 and all seems well (c.f. bug #179882), hence the change in this bug's summary. > Is there any hppa box available for doing such tests so that I could try by > myself as that'd probably be simpler for you and me ? vapier has one and several HPPA team members have access, so you should probably join #gentoo-hppa one day and ask for a login. :)
Created attachment 120873 [details] dev-lang:ocaml-3.10.0:20070601-045518.log With the patch from comment #2 ocaml failed to build again, mentioning "recompile with -ffunction-sections" again.
Created attachment 138756 [details, diff] remove hppa native code support for ocaml Half a year later, still no activity upstream. I think we can sadly declare the hppa native code generation of ocaml dead, this patch removes support for it. Starting from today, ocaml 3.10.0 is good to go into ~arch, so only this bug is refraining me from unmasking it. What should be checked before commiting this patch is that all reverse dependencies of ocaml that are keyworded hppa still build with only bytecode support; if they don't then its a bug that should be fixed as they shouldn't assume the presence of ocamlopt. If you don't have time now to do such testing, please let me know, I'll apply the patch and remove ~hppa keyword on ocaml 3.10.0 before unmasking it so that you'll have all the time you want to test it.
I'm testing it as of now.
OK. Hmm. The upgrade to 3.10.0 causes a couple of problems with dependent packages. * Currently stable dev-ml/findlib-1.0.4-r1 and all versions of dev-ml/lablgtk do make opt || die which is awful if by definition `make opt` will cause an error on certain arches where dev-lang/ocaml is installed without ocaml.opt. This appears to be true for both ppc64 and hppa, though, and ppc64 doesn't seem to have findlib masked. * The currently stable dev-ml/lablgl-1.00 *does* build well and install, but then the unstable version 1.03 does `emake -j1 opt || die "failed to build opt"`. * If we're going to keep supporting packages like mldonkey on HPPA, then we'll have to use a global flag like USE=native or USE=ocaml-opt and use.mask these on these few arches. * This new USE flag should apply as well to dev-lang/ocaml itself, and should be made a default USE flag, so that we can then get rid of the ugly arch-specific code in the ebuild. * net-p2p/mldonkey would need to be fixed with this USE flag as well, as in src_install the executables will have to be renamed from for example <mld_hash.byte> to <mld_hash>. * Best of all is that through this new USE flag you can then test non-optimised code as well as ebuild behaviour on arches that in fact do support optimised code. Judging from the problems above (and from few other issues and inconsistencies that I found while testing the non-optimised ocaml-3.10.0) it could really help generally improving QA for ml based packages as well.
hmm, very good idea, somehow I never thought about it. I'll look into this, this will probably be long as I need to check every single package using ocaml, but yes it would improve quality of our packages, or at least leave people the choice to not use native code. After checking it on ppc64, findlib fails to build, of course... so something has to be done in that regard. One question remains: should *every* single ocaml package be switched to EAPI 1 for use defaults, or should it be a global useflag and go somewhere like in profiles/base/make.defaults ? I'm not sure what would be the best option there. The latter would allow to do it right now, while the former would let it go through a full testing cycle as it would apply only to ~arch ebuilds for now.
(In reply to comment #8) > hmm, very good idea, somehow I never thought about it. > I'll look into this, this will probably be long as I need to check every single > package using ocaml, but yes it would improve quality of our packages, or at > least leave people the choice to not use native code. They aren't that many packages, are they? You should probably open a new bug about this, anyway. > One question remains: should *every* single ocaml package be switched to EAPI 1 > for use defaults, or should it be a global useflag and go somewhere like in > profiles/base/make.defaults ? I'm not sure what would be the best option there. Switching to USE defaults is going to be easier than you now think it is. Doing so later and simply fixing all the ocaml dependent packages now will allow us to finally close this bug.
(In reply to comment #9) > (In reply to comment #8) > > hmm, very good idea, somehow I never thought about it. > > I'll look into this, this will probably be long as I need to check every single > > package using ocaml, but yes it would improve quality of our packages, or at > > least leave people the choice to not use native code. > > They aren't that many packages, are they? a sufficiently large number to not be able to do this very quickly ;) > You should probably open a new bug > about this, anyway. see bug #203886 and esp. its blockers for the nasty side effects...
ok, everything should be good now to use mask ocamlopt and be done.
hmm I had forgotten it: the solver useflag for kdeedu/kalzium needs dev-ml/facile with native code ocaml support
@jer: can we close this bug now ?
I think you can.
(In reply to comment #14) > I think you can. > good ;)
