Walter:

I've tracked down a minor discrepency between DMC++ invoked from inside of the CodeBlocks IDDE and DMC++ invoked via smake in the cmd box. The object files generated via CodeBlocks end up with two extra bytes, which appears to make everything work. When compiled under smake/cmd, however, the two extra bytes don't show up (and this may be the cause of the optlink bug I posted earlier.) Same command line arguments to each invocation of the compiler.

Attached is a (slightly truncated) diff file that shows the problem. The two extra bytes ocur at offset 0x4ce -- the diffs following this are merely offset from each other by those two bytes. The "obj1" file is generated via CodeBlocks IDDE, the "obj2" file is generated via smake/cmd.

Hope this helps...


-scooter

"Scott Michel" <scottm@aero.org> wrote in message news:dmiljd$2bn7$1@digitaldaemon.com...
> Hope this helps...

Unfortunately, there's nothing I can do without a reproducible test case.

Walter Bright wrote:
> "Scott Michel" <scottm@aero.org> wrote in message
> news:dmiljd$2bn7$1@digitaldaemon.com...
> 
>>Hope this helps...
> 
> 
> Unfortunately, there's nothing I can do without a reproducible test case.

It's very reproducable on my laptop... :-)

All seriousness aside, I'm at a loss on how to reproduce the problem such that it makes sense to you to diagnose the compiler. The best I could do was to diff the output from dumpobj, in the vain hope that you might be able to map the object records back to their producer, specifically the PUB386 record that seems to be causing the problem.

If you're feeling up to it, the source I was compiling is the \dm\samples\win32\opengl\demos\stonehng code. The dumpobj output was produced from the atmosphe.cpp source (although, in some way, shape, and form the other object files are similarly afflicted.)

Alternatively, are there stale DLLs that might be causing the problem? Does smake do something strange to invoke dmc versus CodeBlocks, which doesn't do anything particularly special?

Frankly, it's kind of a show stopper for me and a frustrating one too.

"Scott Michel" <scottm@aero.org> wrote in message news:dmivtd$2jdj$1@digitaldaemon.com...
> All seriousness aside, I'm at a loss on how to reproduce the problem such that it makes sense to you to diagnose the compiler. The best I could do was to diff the output from dumpobj, in the vain hope that you might be able to map the object records back to their producer, specifically the PUB386 record that seems to be causing the problem.
>
> If you're feeling up to it, the source I was compiling is the \dm\samples\win32\opengl\demos\stonehng code. The dumpobj output was produced from the atmosphe.cpp source (although, in some way, shape, and form the other object files are similarly afflicted.)
>
> Alternatively, are there stale DLLs that might be causing the problem? Does smake do something strange to invoke dmc versus CodeBlocks, which doesn't do anything particularly special?

I have no idea what CodeBlocks is.

The thing to do, as always, is to take the source code and cut it down to the minimum that reproduces the problem.

"Walter Bright" <newshound@digitalmars.com> wrote in news:dmjd6j$2s8d$1@digitaldaemon.com:
> I have no idea what CodeBlocks is.

It's IDE written with wxWidgets. Looks like main www.codeblocks.org site has bandwith problem so look at least at http://codeblocks.tigris.org/

ABX