On 09/03/2010 02:38 AM, NightStrike wrote: > 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? Sure. But you need to send the patch against gcc trunk to gcc-patches. Andrew.
