On Sat, Jul 17, 2010 at 9:30 PM, Dmitrijs Ledkovs <dmitrij.ledkov@xxxxxxxxxx> wrote: > On 17 July 2010 18:44, Andrew Haley <aph@xxxxxxxxxx> wrote: >> On 07/16/2010 09:54 PM, Dmitrijs Ledkovs wrote: >>> On 16 July 2010 21:44, David Daney <ddaney@xxxxxxxxxxxxxxxxxx> wrote: >>>> On 07/16/2010 12:58 PM, Dmitrijs Ledkovs wrote: >>>>> >>>>> Is it supported to build java without gc? >>>> >>>> I don't think so. Even if it were, it wouldn't be very useful. >>>> >>>> Probably a better use of time would be to fix whatever problem is keeping >>>> the GC from working for you. >>> >>> Thanks for the heads up. >>> >>> This boils down to boehm-gc being not upto-date with boehm CVS. >>> >>> The last try from nightstrike to try to get someone to merge a newer >>> one stalled in 2006. >> >> 2009, actually: exactly a year ago. I think he wanted x86_64-*-mingw* >> support, but no-one volunteered to do any of the work to get it into >> gcc. We could try to get the process re-started. >> >> Is there a platform that you are using that isn't supported by the >> version of the GC in gcc sources? >> > > x86_64-*-mingw* =))))) > > Right here is what i did: > > 1) import all available boehm tarballs into git > 2) import boehm cvs into git > 3) take gcc-git import and filter-branch boehm-gc dir > 4) using graft points made "import boehm-gc 6.6" of the gcc branch to > have only one parent which is boehm-gc 6.6 tarball import > 5) using graft points made cvs initial commit to have parent boehm gc > 7.0alpha5 tarball import > > At this point I have 3 branches with common history =))))) > > next I took gcc & cvs branches and smashed them together =)))) hoping > git will manage. > > Now ignoring: > > 1) All new upstream files, and auto-resolved paths > 2) Configury changes (for now) > 3) Docs & readme > > The unmerged bit is not that large: > > # Unmerged paths: > # (use "git add/rm <file>..." as appropriate to mark resolution) > # > # both modified: darwin_stop_world.c > # both modified: dbg_mlc.c > # both modified: dyn_load.c > # both modified: finalize.c > # both modified: gcj_mlc.c > # both modified: include/gc.h > # both modified: include/gc_config_macros.h > # both modified: include/private/gc_locks.h > # both modified: include/private/gc_pmark.h > # both modified: include/private/gc_priv.h > # both modified: include/private/gcconfig.h > # both modified: include/private/pthread_support.h > # both modified: mark_rts.c > # both modified: misc.c > # both modified: os_dep.c > # deleted by them: powerpc_darwin_mach_dep.s > # both modified: pthread_stop_world.c > # both modified: pthread_support.c > # both modified: ptr_chck.c > # both modified: win32_threads.c > # > > Now the idea is to fetch the offending commits put them up in an > instance of rietveld code review and start analysing them one by one > by studying code, pinging commiters, searching mailing lists. > > And / or possibly doing this distributed via sharing of git's rerere > files =))))) it doesn't look that much work to get gcc up to speed > with boehm cvs trunk =)))))) > > ps. full git status during merge conflict is attached. > ps. tar of the working directory with confict and the git repo is > available here: > people.ubuntu.com/~dmitrij.ledkov/boehm-merge.tar.xz This thread died, much like my aforementioned previous attempts. Did anyone update the in-tree boehm-gc? Andrew, can you help with this task if not?
