[Gc] RE: VC++ build files

Boehm, Hans hans.boehm at hp.com
Mon Jun 30 17:31:22 PDT 2008

> -----Original Message-----
> From: DrPizza
> Sent: Monday, June 30, 2008 3:23 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] VC++ build files
> Hello.
> I have a question (down below) and some minor modifications
> and project files that might be nice to share.
> It may be that I'm a total nub, or it may be that Makefiles
> are horrid and nmake even worse, but I've never really cared
> for building at the command-line.  VC++ is a much more
> pleasing environment to work in when doing my Windows
> development.  Anyway, the makefile versions have been
> annoying me for some time because I'm never sure which CRT
> they're using; there also seems to be something strange with
> MS's makefile header thing that seems to make non-debug
> builds be debug builds when building x64 binaries or something.
The current Windows Makefiles are not in great shape.

The problem with project files is that they're a single platform, completely nonportable, solution.  They tend to be hard to edit for anyone not on a Windows platform.  And we've been short a volunteer to maintain them.  Certainly updated versions would be appreciated, but they tend to deteriorate to a basis for a do-it-yourself project in the absence of a maintainer.

> Anyway.
> I want to put together VC++ 2008 project files to build the
> Cartesian product of { win32, win64 } × { debug, release } ×
> { static, DLL }, all multithreaded (as VC++ nowadays only has
> a multithreaded runtime, it seems appropriate).
> I'm currently using the following #defines (in addition to
> VC++'s defaults, so _WIN32, _DEBUG/NDEBUG, and the various
> processor type #defines etc.):
> All builds:    GC_THREADS,
>                GC_WIN32_THREADS,
These first two are redundant, at least for recent versions.  One should be enough.

>                GC_BUILD,
>                ALL_INTERIOR_POINTERS,
>                __STDC__
Already defined by compiler?

> Debug builds:  GC_DEBUG
This really needs tobe defined in client code to get the debug functionality.  Otherwise I think it mostly affects testing.

> DLL builds:    GC_DLL
> Static builds: GC_NOT_DLL,
>                THREAD_LOCAL_ALLOC
That's an interesting and unfortunate tradeoff.  I would expect THREAD_LOCAL_ALLOC to be appreciably faster.  But it doesn't work with DllMain-based implicit thread registration.  If you know that all clients will be using the normal portable GC interface, I'd recommend turning on THREAD_LOCAL_ALLOC for DLL builds, though that may not have been well tested.

> My question is, are these reasonable?  The project files in
> CVS also define SAVE_CALL_COUNT=8.  If I define that then I
> get crashes inside GC_save_callers; the memcpy (BCOPY) is
> passed bad parameters and crashes.  Don't know why.
Me neither.  Note that some of the related code is in msvc_dbg.c.

> I also have a .lib for C++ programs to override global
> operator new/global operator delete (this can only be done
> with a .obj or a static .lib; it can't use a DLL, or so says MS).
> I'm building all the tests except the trace_test (which won't
> link; I think the immediate problem is that
> GC_generate_random_backtrace needs to be marked with GC_API,
> but that's not enough to make it work anyway).  Each test is
> constructed with each possible GC library (i.e. 8 versions of
> each are produced).  I have made some changes to the
> thread_leak_test so that it can use Win32 threads as well as
> pthreads.  I think the tests all run successfully.
> The project structure I'm using is quite different from that
> of the projects that are in CVS.  Instead of a project each
> for static/DLL I have one project with multiple
> configurations.  I find this makes organization a little easier.
Sounds good to me.

> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list