On Fri, Sep 3, 2010 at 6:11 AM, Andrew Haley <aph@xxxxxxxxxx> wrote: > 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. > I can't. Doing so requires copyright assignments, along with a big pile of knowledge.
