harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] linking with runtime libraries on windows
Date Fri, 19 Oct 2007 07:19:03 GMT
Guys, I've filed HARMONY-4973 with workable patch.
Bad news is that there are spurious errors in gc_gen shutdown (see the
JIRA for details), most possibly corrupted heap :(. BTW,  I possibly
found mismatching "delete" vs "free" usage:
vm/gc_gen/src/thread/marker.cpp:143:  delete marker->trace_stack;
vm/gc_gen/src/thread/collector.cpp:223:  delete collector->trace_stack;

But those are not the rootcause. Any help or ideas will be appreciated...

2007/10/17, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> A kind of roadblock here is the initial issue of debug vs release
> runtime DLLs. It is desirable to have fully redistributable debug
> build, isn't it? So it would be nice to avoid MSVCR71D.DLL dependency.
> Actually the sole thing which requires debug runtime is the
> disable_assert_dialogs() feature, which may affect release build as
> well - e.g. if we compile release but w/o NDEBUG to leave asserts
> enabled. I'll try to dig if it can be workarounded.
>
> --
> Alexey
>
>
> 2007/10/17, Gregory Shimansky <gshimansky@apache.org>:
> > Alexey Varlamov wrote:
> > > Hi all,
> > >
> > > Looking on HARMONY-3964 "[drlvm][build] missing MSVCR71D.DLL
> > > dependency for debug builds", I'm surprised to realize that only GC
> > > dlls in VM ever depend on MSVCR*.DLL, no matter release or debug.
> > > All the rest of VM is linked against static LIBCMTD.LIB so every dll
> > > carries it's own copy of C runtime, with independent heaps and static
> > > data! Now it explains all that troubles with bad frees in
> > > HARMONY-3772, and why each dll has to disable assert dialog
> > > individually (HARMONY-4715). I've just tried fully dynamic build and
> > > indeed all these problems are gone.
> > >
> > > I guess why it was done so, and the only reason I could think of is
> > > historycal. Does anyone knows other explanation? Otherwise I believe
> > > the build must be fixed to link with MSVCRxx.DLL always. Especially as
> > > we already redistribute them with classlib.
> >
> > I agree very much that dynamic build would be much better. The only
> > reason why it wasn't done I think is that it just wasn't easy to do this
> > in the current ant based build system. If you can do it please go ahead
> > and commit!
> >
> > BTW don't forget about windows x86_64.
> >
> > --
> > Gregory
> >
> >
>

Mime
View raw message