/INCREMENTAL linking in VS2010

Ranko Tomić

When I compile BRX add-on, I get this:

 drx_entrypoint.lib(drx_module.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
1>LINK : warning LNK4044: unrecognized option '/GL'; ignored
1>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification

Thus having no chance for code changes apply during debug. How to solve this?

Regards,
Ranko

Torsten Moses

Dear Ranko,

the drx_entrypoint.lib is compiled with /LTCG ... but does your project use /GL resp. /LTCG ?
Have you tried to change the code while debugging ?

If the problem persists for you, we will think about to remove /GL and /LTCG from BRX modules ...
but this will cause some performance degradation, for BRX core, unfortunately :-(

Many greetings !
Torsten

Ranko Tomić

Dear Torsten,

If I turn on /GL, then /INCREMENTAL is not working, so Edit&Continue is disabled and code changes can not be applied while debugging. It would be nice if you provide debug-only version of drx_entrypoint.lib compiled without optimizations. Or you have another way to enable edit&continue with this lib?

Best regards,
Ranko

Torsten Moses

Dear Ranko,

it is not only drx_entrypoint.lib then - also brx13.lib uses /GL ...
I will try here, to get Edit & Continue working for debug build, hope to keep /GL active;
otherwise, having /GL and /LTCG disabled for all BRX modules (libraries) would significantly
reduce BRX performance :-(

I will try, and keep you updated ...
many greetings, Torsten

Torsten Moses

Dear Ranko,

it was indeed only the drx_entrypoint.lib, where /GL + /LTCG options disabled the Edit+Continue
feature for client builds using bRX SDK - drx_entrypoint.lib is a static lib, that seems to be the cause.

For brx13.lib, /GL and /LTCG options are still active here (in my build), and Edit+Continue is still available
for client modules (I just tested with our BRX test module, which is a normal SDK-based module).

So seems, your wish can be satisfied :-)
I assume, next published BRX SDK will have the new libraries then.

Many thanks for your hints !
Wish you a nice day & many greetings, Torsten

Ranko Tomić

Dear Torsten,

Now I get this warning during linking (V13.1.18):

1>Link:
1>     Creating library Debug\QuickeningPro.lib and object Debug\QuickeningPro.exp
1>  Generating code
1>  Finished generating code
1>drx_entrypoint.lib(drx_module.obj) : warning LNK4099: PDB 'drx_entrypoint.pdb' was not found with 'drx_entrypoint.lib(drx_module.obj)' or at 'D:\CPP projekti 2010\QuickeningProV13\quickening\Debug\drx_entrypoint.pdb'; linking object as if no debug info
1>  quickening.vcxproj -> \CPP projekti 2010\QuickeningProV13\quickening\Debug\QucikeningProV13.arx

Any ideas why?

Regards,
Ranko

Torsten Moses

Dear Ranko,

this is perfectly normal ... the same message we also get when we build our TestArx unit testing module
(which is a normal ARX/BRX module), and we also get this warning when compiling for AutoCAD ARX.

The message simply says, that the linker "misses" the PDB file for dxr_entrypoint module ... in Debug build;
in Release build, that message will not appear at all.

So in summary, nothing to worry about :-)

Wish you a nice day & many greetings,
Torsten

Ranko Tomić

Thanks Torsten, it was really quick

Now, another thing - I have encountered problems with debug compile, e.g. whatever I tried, I got debug assertion in line 24 of afxini1.cpp (or something like that). Release version of DLL loaded well and worked well, so I tried numerous things to fix it (w/o success), and then found this code on some web page:

// 'DEBUG workaround' below prevents the MFC or ATL #include-s
// from pulling in "afx.h" that would force the debug CRT through
// #pragma-s.
#if defined(_DEBUG) && !defined(_FULLDEBUG_)
#define _DEBUG_WAS_DEFINED
#undef _DEBUG
#pragma message ("     Compiling MFC header files in release mode.")
#endif

After adding it to stdafx.h, my problems with asserts seems to be gone. So I put it here in case someone else encounters the same.

And another question: should I use AFX_MANAGE_STATE(AfxGetAppModuleState()); or CAcModuleResourceOverride for resource handling?

Best regards,
Ranko

Torsten Moses

Dear Ranko,

indeed, all the system + MFC headers need to be compiled in Release mode (as BricsCAD installation
is in Release mode), but I forgot to mention about :-(

Our BRX samples installed under ./API folder does also have a similar trick  - after system + MFC + BRX headers
are included, that Debug symbol can be defined again, so *your* code is compiled in Debug mode, so you can run
debug sessions.

AFX_MANAGE_STATE is not necessary any longer - if you use MFC, then your module should be compiled
as MFC extension module (define _AFXDLL and _AFXEXT symbols for your project)
-> AFX_MANAGE_STATE is intended for non-extension and regular DLLs ...

So CAcModuleResourceOverrideis much more appropriate (and even much more performant as well, state switching
is somewhat costly operation for the MFC system).

Wish you a nice day & many greetings,
Torsten

Ranko Tomić

Dear Torsten,

Is there a workaround to enable edit and continue compilation for arx modules?

Regards,
Ranko

Torsten Moses

Dear Ranko,

it should not be a problem at all ... our TestArx testing module and also the "Sample" BRX application
(under ./BricsCAD V13/API/brx) also has it enabled ...
simply switch Debug configuration to /ZI mode (Edit and Continue).

So you can compare the settings from "Sample" project with yours.

I hope that clearifies ?

Many greetings & a nice day
Torsten